Ka-Ping Yee wrote: > > On Wed, 12 Apr 2000, Fred L. Drake, Jr. wrote: > > > Or do we need to separate out two categories of pragmas -- > > > pre-parse and post-parse pragmas? > > > > Eeeks! We don't need too many special forms! That's ugly! > > Eek indeed. I'm tempted to suggest we drop the multiple-encoding > issue (i can hear the screams now). But you're right, i've never > heard of another language that can handle configurable encodings > right in the source code. Is it really necessary to tackle that here? Yes. > Gak, what do Japanese programmers do? Has anyone seen any of that > kind of source code? It's not intended for use by Asian programmers, it must be seen as a way to equally support all those different languages and scripts for which Python provides codecs. Note that Fred's argument is not far fetched: if you look closely at the way the compiler works it seems that adding a new keyword would indeed be the simplest solution. If done right, we could add some nifty lookup optimizations to the byte code compiler, e.g. a module might declare all globals as being constant or have all could allow the compiler to assume that all global lookups return constants allowing it to cache them or even rewrite the byte code at run-time... But the concepts are still not 100% right -- if we want to add scope to pragmas, we ought to follow the usual Python lookup scheme: locals, globals, built-ins. This would introduce the need to pass locals and globals to all APIs compiling Python source code. -- 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