-----Original Message----- From: Greg Ewing [mailto:greg.ewing@canterbury.ac.nz] Sent: Friday, May 11, 2007 6:50 PM
Aaron Brady wrote:
But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module?
I can understand there being reluctance to expose what are currently internal details of this module, thereby effectively freezing them.
-- Greg
I didn't realize they were changing so dynamically. But then, plenty of the modules have parallel Python and C implementations. I suspect the true reason lies more with Sakkis' post [5/10 23:26 us central]. A mimetic structure such as Python will sit somewhere between restriction and liberty. Best to be deliberate in choosing a place on the continuum. But where, exactly? Discouraging customized syntax is one thing. Prohibiting it altogether is another extreme. The current positioning lies with the latter. Put `parser' in to encourage the adventurous explorer, -while- keeping native dynamic constructs disabled in order to keep up unity. I do not hold that we lift all restrictions. Rather, merely -reduce- the number of hoops you must jump through to get at Python internals. If you think that everybody will jump-to and create their own Python the very first day you let a second ray of light shine in, you've underestimated Python. For one thing, we -want- to stick together, and will on our own. Present the option, and you'll only get better suggestions, thenceforth. The current state is too restrictive.