"Martin v. Loewis" wrote: >=20 > barry@zope.com (Barry A. Warsaw) writes: >=20 > > I'm hoping that Stephen will soon be able to join the python-dev > > discussions more directly, and I'm cc'ing him on this message. I > > admit to wearing the typical American sunglasses on this issue, MM2.1 > > not withstanding. I think Stephen's view point and experience with > > this issue is worth bringing up here. >=20 > We have sorted out some of this on python-list already. Stephen > mistook the proposal as talking about the encoding which is used in > the Python source code. With the occasional exception of a Latin-1 "=F6= " > in a comment line, I think the Python source is currently pure ASCII - > I would have no problems with changing these few occurrences to UTF-8, > as Stephen suggests. >=20 > I'm not sure whether he still has his original position "do not allow > multiple source encodings to enter the language", which, to me, > translates into "source encodings are always UTF-8". If that is the > route to take, PEP 263 should be REJECTED, in favour of only > tightening the Python language definition to only allow UTF-8 source > code. -1 We had the UTF-8 discussion back when we started discussing the Unicode intergration. Let's not start it again. Note that PEP only *allows* using various locale dependent=20 encodings for Python source. Don't take this as: hey, everybody=20 will start using their own home-grown ROT-13 variant now and=20 start having code obfuscation fests :-) Reasonable programmer will stay reasonable programmers even if you give them a nice tool like Emacs which allows them to do just about anything you could possibly imagine to=20 source code. Adding the option of having different source code encodings won't change that. I don't think there's much to worry about and that most of this is just FUD. > This, of course, will find disapproval from people who currently use > different source encodings. "Not everybody has a UTF-8 editor" is a > frequent complaint from that camp, and I think it is a valid one > (although I personally do have a UTF-8-capable editor, and although > IDLE could be taught into doing UTF-8 only easily). To allow notepad > support, we'd still need to accept the UTF-8 signature at the > beginning of a file. Which the PEP allows. =20 > > Nevertheless, it is supported in XEmacs, and is working in 21.4.6. > > Except ... only in the first line. Yep, there's explicit code to > > restrict recognition to the first line. No second or third line, no > > trailing local variables section. I don't have a problem with > > extending to the first few lines, but the trailing local variables > > section I oppose. >=20 > For Python, it probably would have to go to the second line, with the > rationale given in the Emacs manual: the first line is often used for > #!. Right. =20 > > You guys absolutely definitely positively only ever need _first and > > second line_ forever and ever promise cross your heart, right? >=20 > Yes. The current proposal does not spell this out, but I think this > restriction is reasonable. I think the comment about the RE and where it is applied is very clear on this. --=20 Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
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