Python Oddity - print a reserved name

Alex Martelli aleaxit at yahoo.com
Wed Sep 15 10:57:06 EDT 2004


Steve Holden <sholden at holdenweb.com> wrote:
   ...
> > See that I can't set the something.print attribute directly, but can
> > set it indirectly. Is this behaviour 'necessary' or just an anomaly of
> > the way IDLE detects Syntax Errors ?
> > 
> It's necessary. You will find that keywords (those having a specific 
> meaning as a language token, such as "def" and "print") can't be used as
> attributes. The fact that you can set the attributes by manipulating the
> __dict__ directly isn't relevant - you will find you can only access 
> such attributes indirectly, since any attempt to do so directly will 
> result in a syntax error no matter how the Python interpreter is invoked.

I think that, while you're right for CPython, other Python
implementations are allowed to relax this restriction, and Jython does
so systematically.  Since Jython regularly accesses attributes on
Java-implemented classes, I guess that forcing Jython users to jump
through hoops to access, say, foo.yield, bar.print, or baz.def, might
reduce usability too badly.  Possibly make it completely unusable if you
had to implement an interface using such a name, too...

This kind of thing, however, is also true of CPython whenever it's
accessing "outside" objects through attributes; and for .NET
implementations I believe that CLR compliant languages are not allowed
to forbid certain method names along their interfaces to other
components.  I'm not sure how CORBA's standard Python bindings address
the same problem, how it's met in various interfaces to XML-RPC, COM,
SOAP, and other distributed-objects or foreign-objects APIs.

Given how pervasive this problem is, I do recall some ruminations about
allowing arbitrary identifiers in the specific case in which they fall
right after a dot in a compound name.  I don't recall that anything ever
came of these ruminations, though.


Alex



More information about the Python-list mailing list