Luis Zarrabeitia <ky...@uh.cu> writes: > > Luis Zarrabeitia <ky...@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. -- http://mail.python.org/mailman/listinfo/python-list
