Allow anything in identifiers?
thomas at xs4all.net
Thu Mar 1 15:22:13 CET 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:
>>> x = X()
>>> setattr(x, '%$@(*#@$+', 2)
>>> getattr(x, '%$@(*#@$+')
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