Fredrik Lundh writes: > -- item (3) is for backwards compatibility only. might be okay to > change this in Py3K, but not before that. > > -- leave the implementation of (1) to 1.7. for now, assume that > scripts have the default encoding, which means that (2) cannot > happen. We shouldn't need to change it then; Unicode editing capabilities will be pervasive by then, right? Oh, heck, it might even be legacy support by then! ;) Seriously, I'd hesitate to change any interpretation of default encoding until Unicode support is pervasive and fully automatic in tools like Notepad, vi/vim, XEmacs, and BBedit/Alpha (or whatever people use on MacOS these days). If I can't use teco on it, we're being too pro-active! ;) > -- we still need an encoding marker for ascii supersets (how about > <?python encoding="utf-8" version="1.6"?> ;-). however, it's up to > the tokenizer to detect that one, not the parser. the parser only > sees unicode strings. Agreed here. But shouldn't that be: <?python version="1.6" encoding="utf-8"?> This is war, I tell you, war! ;) Now, just need to hack the exec(2) call on all the Unices so that <?python version="..." ...?> is properly recognized and used to run the scripts properly, obviating the need for those nasty shbang lines! ;) -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives
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