Allow anything in identifiers?

Thomas Wouters thomas at xs4all.net
Thu Mar 1 09:22:13 EST 2001


On Thu, Mar 01, 2001 at 01:04:30PM +0100, Sverker Nilsson wrote:
> David Porter wrote:

> > > alu.id'+' = lambda x, y...

> > It would break any code using the name 'id', likely a lot of code.

> How? Not id <string>, should likely be on the same line, may allow
> space in between. That gives a syntax error currently, except when id
> is some of a few special ones like r, u, etc. 

If you want for id"string" as a string literal, the example above will not
work. String literals create strings, not identifiers. Creating a special
kidn of string that really creates an identifier would be... Weird.

>   operator.__lt__ (though I am just guessing about
>   [that] one and I  am sure it's wrong - that's a point of the
>   argument :-)

The latter doesn't exist. But neither does operator.__cmp__, so it's not
that big a suprise.

> * Same holds for the corresponding class methods __add__ etc.

Actually, you guessed exactly right with __lt__. That's the name for the
less-than operator 'magic method'. But even with special syntax to declare
operator'+', you can't throw away all magic names. What to do with __cmp__,
__init__, __del__, __setitem/attr__ ?

> * Command interpreters could dispatch to functions that had obvious
>   names corresponding to the actual commands.

> * Variables corresponding to files with fixed name, could have
>   the obvious name.

>>> class X:
...     pass
... 
>>> x = X()
>>> setattr(x, '%$@(*#@$+', 2)
>>> getattr(x, '%$@(*#@$+')   
2

I don't see a lot of people using that hack. I also don't see how using that
kind of variable name can be any clearer. I especially dont believe in
'fixed named files': you should name your variables according to what
function they perform, not what they contain -- what they contain is already
obvious ;) I might call a template file
'/usr/local/lib/<application group>/<application>.tmpl', but the variable
would simply be called 'tmpl' or 'TEMPLATE' or some such.

> One drawback I can think of myself right now is a kind of uglyness
> by using quotes but at least they make the construct stand out so it
> should not be so confusing to ordinary id's.

The main drawback I see is your 'strong point': I don't believe allowing
more characters in identifiers is going to make programs easier to read or
follow, or going to make constructs more selfexplanatory. I just see added
complexity with no obvious benifit.

-- 
Thomas Wouters <thomas at xs4all.net>

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




More information about the Python-list mailing list