[Python-ideas] relaxing keyword usage restrictions
pyideas at rebertia.com
Fri Sep 9 09:36:51 CEST 2011
On Thu, Sep 8, 2011 at 11:04 PM, H Krishnan <hetchkay at gmail.com> wrote:
> I have read through the comments and the (largely negative) votes for this
> The main argument against it seems to be readability. I feel the examples I
> chose were distracting. The intent of the examples was to show the semantics
> and not to suggest that anyone should write such code. One can write totally
> unreadable code even with the current syntax:
> if not was is can:
> return take
"You can write FORTRAN [(or rather, bad code)] in any language"
> One cannot however write readable code such as the following:
> if yield > principal:
> return = yield - principal
As an example of how problematic the proposal is, that last line
(modulo some var names, obviously) contains a valid yield-expression
(see PEP 342 - http://www.python.org/dev/peps/pep-0342/ ). Subtle bugs
and parser complexity ahoy!
> Syntax is something people will get used to. The following is perfectly
> valid 'scheme' code:
> (define define 3)
> (* define 5)
> In my 10+ years in scheme, I have never used 'define' as a symbol, nor have
> I seen anyone else do it, even though there is no language restriction.
> 'self' is not a keyword in python, but I have not so far seen anyone use
> 'self' other than as the first argument of a class method.
This would seem to argue against the proposed language feature. If
nobody does it even when they can do it, then why should we bother to
change our rules to allow it?
> The use-case I had in mind was related to a customization tool we are
> developing. We want to allow users to define expressions and assign them to
> names. We 'eval' the expressions subsequently. We have to currently prevent
> users from using any python keyword as a name, which I felt was an
> unnecessary restriction.
Define a name-mangling convention then, and escape the problematic (or
just all) names.
Or use a dictionary instead of a normal namespace to store and refer
to the expressions (as Bruce suggested excellently).
Or accept the fact that since the users are really writing in Python
(and not some custom scripting language), they should observe Python's
More information about the Python-ideas