Long names are doom ?

[Thomas Wouters]

On Sun, May 27, 2001 at 08:50:03AM +0200, Alex Martelli wrote:

> Just about the only advantage would need keywords to
> be usable in ALL "non-ambiguous" contexts (having them
> just as attribute names would not suffice), including
> 'class=10' and 'def class(x):' etc -- that advantage would
> be the possibility to introduce new keywords (and thus
> potentially clearer syntax for new constructs) without the
> reserved-word issue of breaking previously working code.

There are basically two choices wrt. allowing reserved words as vrbl names:

1) allow them everywhere, in any situation. This is doable, even with the
LL(1) parser Python currently has, but doing it in the LL(1) parser would be
atrociously ugly, both in the grammar and in the compiler/scanner. However,
there would be problems with, e.g., print. What would

  print(spam)

mean ?

2) Allow them in certain locations only, like calling functions with keyword
arguments, attribute-referencing/assignment and 'def' statements inside
classes (but not outside.) The ability to do that is necessary for e.g.
Python .NET (or so Mark Hammond says ;) The specification apparently insists
that .NET objects (or whatever they're called) have no 'reserved words' for
attributes and the like. You can already fake this, however, by using
**kwdict and getattr()/setattr(), but it's far from pretty.

Because it's just *calling* functions with keyword arguments, not defining
them, you can never end up with an unqualified vrbl with a 'reserved word'
name, so the 'print(spam)' problem doesn't exist. 'pass = spam' would still
be illegal, but 'self.pass = spam' and 'self.print(ham, pass=eggs)' would
not. However, implementing this in the current parser isn't any prettier
than #1 :-P

Like Tim posted, Guido agreed with #2 already (pending implementation). I'm
not sure what his opinion of #1 is, but if the print() problem can be worked
around (by making it illegal ;) and no other problems arrise, I'm pretty
sure it's discussable. *I* like it, anyway :) Unfortunately, I don't have
the time, nor the experience with non-LL parsers, to build a new parser.
Using the old parser is possible, but would probably mean a preprocessor (or
an extra pass in the grammar-parser) and much ugly hacks.

> This is the advantage on which Rexx focused (and also
> part of the reason to 'strop' variable names in Perl -- by
> almost-never allowing barewords as user-definable
> identifiers, new keywords can also be added anytime).

Of course, Perl (initially) completely negated that benifit by allowing
barewords and treating them as string literals. Allowing barewords is still
the default, you have to pass in '-w' (always a good idea) to convince Perl
you *don't* want bareword string literals.

-- 
Thomas Wouters <thomas at xs4all.net>

Hi! I'm a .signature virus! copy me into your .signature file to help me spread!