Joe <[EMAIL PROTECTED]> wrote: > Is Python going to support s syntax the does not use it's infamous > whitespace rules?
No, never (even apart from the "its" vs "it's" issue here...;-). > I recall reading that Python might include such a > feature. And I recall reading that Elvis is still alive and was kidnapped by aliens, but I don't necessarily believe all that I read. > Or, maybe just a brace-to-indentation preprocessor would be > sufficient. Fine, then write one -- it's not too hard (about an average interview question for hiring a programmer, I'd say). As for how to integrate such a preprocessor with CPython, I would suggest you follow precedent by allowing an arbitrary "source-code-reading hook" to be optionally specified by setting sys.preprocessor (and/or via commandline flag, environment variable, etc -- but, the ability to install the hook from site-configure.py would probably be sufficient). You could maybe get 99% of the way there by using the existing "import hooks" mechanism (the same one that lets you import from zipfiles: it's designed to be easily extensible), but I don't think that would help with the "main script" (which doesn't get imported), interactive interpreter sessions, etc; also, I'm not sure it would easily allow seamless interoperation with other such hooks (e.g., to let you import from zipfiles sources that need to be preprocessed). The main reason I suggest a general-purpose mechanism for the hooking-up of the preprocessor is that such a mechanism might stand a chance to be accepted (via the usual PEP procedure), as long as other interesting use cases can be found; I suspect that if the only use case was "turn braces into indents/dedents", the PEP would stand no chance. For example, a small but vocal minority has long campaigned for non-ASCII characters to be allowed in identifiers; a preprocessor might be able to do this by translating them into ASCII on the fly (though that wouldn't necessarily work well with getattr and friends... but then, neither do 'private' identifiers starting with two underscores;-). > still don't understand how anybody can think significant-but-invisible > dedentation is a good thing. We're even, then, since I can't understand the reverse;-). > Note: No need to follow up with long opinions of why indentation is > good -- they have been posted hundreds of times. It just seems that Respecting your wish, I'm not discussing the issue at all (although, by trying to make some point AGAINST it, you really make it very hard: if you don't want such a discussion you shouldn't start one yourself and then try to impede your opponents from rebutting your points, that is really an extremely unfair attempt on your part). I'm pointing you to ways you might get your wish, if you're willing to do some work for the purpose. Coding the preprocessor is the easy part -- the work is mostly in doing the PEP, including a variety of strong use cases for a general purpose preprocessor. (Of course, forking Python to hardcode your preprocessor is easier, but forking always has other problems). Alex -- http://mail.python.org/mailman/listinfo/python-list
