Jim Kleckner <jek-cygwin@...> writes:
> ... > Sounds like you are looking for getattr(object, name)
> Yep, that was it. Now where would be the best place
> in the Jython doc to signal the next travelers?
I'm coming from Python, so the natural place for me is
> Coming to Python because of Jython, there are things
> like this that I don't see. The Jython API and overview
> docs are the lead in. As a newbie, it appears to me
> that Python is in a transition from non-object-oriented
> (e.g. getattr(o, "a")) to object-oriented (e.g. o._getattr__("a")).
I don't see built-in functions like getattr() as
"non-object-oriented". Not every method you ever want to call can be
an instance method.
Java gives you static methods, which behave similar to Python
On the other hand, not having functions in Java causes warts like
"String.length()" vs. "byte.length" vs. "List.size()" instead of a
> Witness the switch from open() to file() in 2.2.
> It appears only part of the way through this transition.
The switch from open() to file() is just renaming the factory function
("open" and "file" are the same object). Before 2.2, open() created a
file object, now you have a more consistent name to create a file object
The bigger change is healing the split between types and classes,
which allows extending types implemented in C in Python.
> If this is so, then why wouldn't o.__getattr__ behave
> the same way as gettattr(o,...) ?
The naming convention of __getattr__ tells you that this is a
special method used by the system.
In application code you have rarely the need to *call* a special
method, you only provide implementations for these methods to hook
into the system behavior.
In case of __getattr__ you can provide an implementation of
__getattr__ if you want to customize access to attributes of your
class, but you can't reverse this to assume that __getattr__ will
give you access to attributes of all classes. (see
for more details about __getattr__)
steffen.ries@... <> Gravity is a myth -- the Earth sucks!