Home Original page

Why not 3.__class__ ?

Marcin 'Qrczak' Kowalczyk qrczak at knm.org.pl
Wed Sep 26 08:45:12 EDT 2001 
Tue, 25 Sep 2001 15:46:19 -0500, Skip Montanaro <skip at pobox.com> pisze:

> Still, placing an arbitrary restriction on the attribute names of integers

It's not a restriction on attribute names. It's only a restriction
of getattr syntax. You can still write (3).e7 or 3 .e7 if you really
mean that. Currently all attribute names are "restricted", including
those actually present and others.

Similarly there is a "restriction" that you "can't" pass a literal
tuple as an argument to function. Well, just put it in parentheses.
Or that you can't write a backslash in a string - well, just quote
it with another backslash.

There are already cases where a bit of syntax has a meaning which
prevents interpretation as a composition of independent meanings
of components.

It would be bad if you frequently bumped into such case wanting
to obtain the composite meaning, and thus had to use workarounds
to disambiguate. This is not such a case - you won't want to get
attribute e7 from literal 3.

I agree that it is taking away some syntax because of an ambiguity,
i.e. something is not parsed in a particular way only because there
is another parse. You rarely need to get any attribute of an int
literal at all, so it's not very important for me whether 3.__add__
will be valid or not. I'm only saying that it would work in practice,
at least for programmers (possibly there are technical problems with
lookahead because of the way the lexer is implemented - I don't know).

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK
More information about the Python-list mailing list