Martin v. L=F6wis wrote: > "M.-A. Lemburg" <mal@lemburg.com> writes: >=20 >=20 >>>I am not aware of such a plan, and it is >>>not part of the approved PEP 263. I would strongly object to such a >>>change. >> >>Why is that ? The proposed APIs will work just like their >>counterparts for the internal Unicode/string conversion which >>have proven to quiet down discussions about choosing ASCII >>as default encoding. >=20 > But do they have done good? I don't consider quieting down of > discussions a good thing per se. Providing more options often helps in finding compromises. Not that I like any of these APIs or that I have ever used them, but if they make people happy, I don't mind exposing them. >>"Practicality beats purity." >=20 > That is, unfortunately, convincing. I'll certainly bow to BDFL > pronouncement, but I don't have to like this feature. No question about that :-) > So I withdraw my observation that this would be out of scope for the > next beta. I'll hope that nobody volunteers to implement it, anyway > :-) Any potential implementer, please find a way to integrate this > with IDLE: In absence of a declared source encoding, IDLE should then > probably assume that source files are in the system source encoding. I think that we can safely leave providing patches for this to the people who will make use of the feature :-) --=20 Marc-Andre Lemburg eGenix.com Professional Python Software directly from the Source (#1, Jun 22 2003) >>> Python/Zope Products & Consulting ... http://www.egenix.com/ >>> mxODBC, mxDateTime, mxTextTools ... http://python.egenix.com/ ________________________________________________________________________ EuroPython 2003, Charleroi, Belgium: 2 days left
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4