Does Python really follow its philosophy of "Readability counts"?
Paul Rubin
http
Sun Jan 11 18:02:54 EST 2009
Carl Banks <pavlovevidence at gmail.com> writes:
> and where it was manipulated for that matter.
>
> This criticism is completely unfair. Instance variables have to be
> manipulated somewhere, and unless your object is immutable, that is
> going to happen outside of __init__. That's true in Java, C++, and
> pretty much any other language.
The criticism is very valid. Some languages do support immutable
variables (e.g. "final" declarations in Java, "const" in C++, or
universal immutability in pure functional languages) and they do so
precisely for the purpose of taming the chaos of uncontrolled
mutation. It would be great if Python also supported immutability.
> I'm not going to argue that this doesn't hurt readability, because it
> does (though not nearly as much as you claim). But there are other
> considerations, and in this case the flexibility of defining
> attributes outside __init__ is worth the potential decrease in
> readability.
There are cases where this is useful but they're not terribly common.
I think it would be an improvement if creating new object attributes
was by default not allowed outside the __init__ method. In the cases
where you really do want to create new attributes elsewhere, you'd
have to explicitly enable this at instance creation time, for example
by inheriting from a special superclass:
class Foo (DynamicAttributes, object): pass
> 4. It allows a simplification of the object system. Right now, all
> attribute access is handled identically: at any point in time any
> attribute may be set. If you wanted to limit attribute creation to
> __init__, then it would mean objects have to have two phases (one,
> during __init__, where you can create attributes; the other, where you
> can only modify them). This would add significant complexity, and
> "Simple is better than complex.
On the other hand, correct is better than buggy.
More information about the Python-list
mailing list