Does Python really follow its philosophy of "Readability counts"?

[Paul Rubin]

Luis Zarrabeitia <kyrie at uh.cu> writes:
> > Luis Zarrabeitia <kyrie at uh.cu> writes:
> > > You *can* implement a metaclass that will remove the dynasmism from its
> > > instances....
> import inspect
> class ImmutableType(type): ...

Thanks for posting this, I haven't replied because I bookmarked the
post for later study, but that was several days ago, so I just wanted
to say that I'm still looking at it.  It's an area of Python that I've
somewhat purposely stayed away from.

> But I see no _necessary_ harm on tacking extra attributes to an
> existing object - specially if you are going to use them pretty
> close to the creation.

> I use them, a lot, specially when writing decorators... Many times I
> just want to 'mark' the decorated functions so I can inspect those
> marks later.  I'd rather have a semi-private namespace for each pair
> ([group of]calling function[s], object),

Right, thus the usefulness of a static tool that can find all those
places where extra attributes are created.  Basically I can see three
approaches to this question:

1) Program in a style where you create and modify attributes all over
the place willy-nilly, with no controls whatsoever, either automatic
or stylistic.  From experience (it is a common style in Javascript) I
can say this is a big mess and I think no experienced Python
programmers recommend it.

2) Have mandatory encapsulation like Java's, no way to escape.  Bruno
and yourself vehemently object to this, Russ P seems to want it, my
view is that it's not in the Python spirit, so I can accept the
argument that those who really want this are better off choosing
another language.

3) Program in a style where creating new attributes outside the
initializer is normally avoided by convention, but it is possible and
sometimes desirable to break the convention.  This seems reasonable
and Pythonic to me.  But, any place I break the convention, I should
be able to say "I broke the convention here for such and such a
reason".  And (this seems to be a bone of contention) IMO, it would be
good to be able to audit a large codebase with a tool like Pylint, to
automatically find all the places where such breakages occur.  Right
now there seems to be no way to do that reliably, short of using
something like your special metaclass instead of the standard one for
just about everything.

Your example about decorators (used on classes that don't expect to be
wrapped by them) is a good one but narrow enough that there could be a
special arrangement for it in a hypothetical auditing tool.