On 5/10/07, Aaron Brady <castironpi@comcast.net> wrote:
-----Original Message----- From: george.sakkis@gmail.com [mailto:george.sakkis@gmail.com] On Behalf Of George Sakkis Sent: Thursday, May 10, 2007 10:36 PM To: Aaron Brady Subject: Re: [Python-ideas] parser in stdlib
On 5/10/07, Aaron Brady <castironpi@comcast.net> wrote:
Huge bag of worms, I see now. I was tinkering for hobby Python use. I hadn't proposed a syntax change, not there yet. I was wanting to intercept parser somewhere after it's started parsing source, but before it gets to the rules. The particular change I'm tinkering with was replacing an equal sign with a natural word.
1, 2 to a, c -and- to a, c 1, 2
map to:
a, c = 1, 2
A perfect example of why programmable syntax is out of question for Python.
George
Hence the quote. First thing I said was, "...it might not be advisable either, subject to abuse, per GvR...."
But that doesn't preclude exposing `parser'. It is the extent of my question, no more. Can we expose the module?
Do I take the powers that be to have said, "No, that would open too many doors and give the programmers too much freedom?" If so, that's straight-forward and honest, and presents the next problem for solutions. Can we expose that and still keep programs up to standard?
There is no universally accepted answer to this question. Each language positions itself (deliberately or by accident) somewhere in the spectrum between total bondage and total freedom. Static typing proponents find that dynamic typing is already "too much freedom", let alone programmable syntax. Those that don't believe there is such a thing as "too much freedom" tend to climb their way up in the language ecosystem, until they discover Lisp and reach nirvana. Python keeps a happy medium by accepting that programmers are neither clueless drones that need a static compiler to babysit them all the time, nor omnipotent gods; they are just humans. George -- "If I have been able to see further, it was only because I stood on the shoulders of million monkeys."