Fredrik Lundh wrote: > > > [paul] > > > Also, is it really necessary to allow raw non-ASCII characters in source > > > code though? We know that they aren't portable across editing > > > environments, so one person's happy face will be another person's left > > > double-dagger. > > > > [me] > > I suppose changing that would break code. maybe it's time > > to reopen the "pragma encoding" thread? > > > > (I'll dig up my old proposal, and post it under a new subject). > > as brief as I can make it: > 1. add support for "compiler directives". I suggest the following > syntax, loosely based on XML: > > #?python key=value [, key=value ...] > > (note that "#?python" will be treated as a token after this change. > if someone happens to use comments that start with #?python, > they'll get a "SyntaxError: bad #?python compiler directive"...) > > 2. for now, only accept compiler directives if they appear before > the first "real" statement. > > 3. keys are python identifiers (NAME tokens), values are simple > literals (STRING, NUMBER) > > 4. key/value pairs are collected in a dictionary. > > [...] I like the proposal, but how would you implement this ? Note that strings are decoded in compiler.c after having run the source through the tokenizer (which eliminates the comments). You'd have to carry the encoding information through to the compiler somehow. There's also a different problem to this: dynamic compilation. What encoding should eval() and exec use or expect ? -- Marc-Andre Lemburg ______________________________________________________________________ Business: http://www.lemburg.com/ Python Pages: http://www.lemburg.com/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