[Python-ideas] relaxing keyword usage restrictions

[Nick Coghlan]

On Wed, Sep 7, 2011 at 6:41 AM, Barry Warsaw <barry at python.org> wrote:
> On Sep 05, 2011, at 03:50 PM, Nick Coghlan wrote:
>
>>The main advantage of making things out-and-out keywords is that it
>>greatly simplifies the task of *parsing* the language.
>
> While I agree with this, and the other justifications Nick mentions, I *could*
> see a potential middle ground, by allowing keywords as attributes.  I think
> I'd still be -0 (at least) on it, but IIRC Jython did allow these at one point
> (e.g. `foo.class`), mostly through an accident of its implementation.

The main objection to that approach is that it breaks down when you go
to explicitly define class (or module) attributes that make use of the
feature:

    class Foo:
        for = "Demonstrating a flaw in the 'keywords as attributes' concept"

While there's a definite appeal to the idea of allowing
keywords-as-attributes, it comes at the cost of breaking the symmetry
between the identifiers that are permitted in module and class
definition code and the attributes that are accessible via those
namespaces.

You could answer "but the feature is for programmatically generated
attributes, such as CSV column names, not ones you type in a class
definition" and make a reasonable case for the feature on that basis,
but the conceptual symmetry is still broken.

Ultimately, it's the "keep the rules simple" argument that holds the
most weight with me on this topic, so the twin rules of "keywords can
only be used as keywords" and "attribute names must be legal
identifiers" end up being my preferred approach. The occasional
inconvenience of a deliberate misspelling or the addition of a
trailing underscore to convert a keyword into a legal identifier seems
like a worthwhile trade-off for the corresponding simplification of
the language syntax and semantics.

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia