Does Python really follow its philosophy of "Readability counts"?
kyrie at uh.cu
Wed Jan 14 18:23:58 CET 2009
On Wednesday 14 January 2009 11:45:46 am Paul Rubin wrote:
> Luis Zarrabeitia <kyrie at uh.cu> writes:
> > Why don't you do it backwards?
> > You *can* implement a metaclass that will remove the dynasmism from its
> > instances. Do it - I can give you a starting point if you wish.
> That's kind of interesting, how does it work?
Proof of concept, that breaks on inheritance (can't call 'super'), but it took
me just a few minutes to cook. If you aren't that paranoid, you could get rid
of the 'currentframe' and 'code' hacks. This creates a class "MyClass" which
instances cannot be modified. I once gave my students the homework of
creating a metaclass that would type-check all the assignments to its
members - so that the types wouldn't change.
def __init__(self, *args, **kwds):
super(ImmutableType, self).__init__(*args, **kwds)
initmethod = self.__init__.im_func
def setattr(instance, attr, value):
callee = inspect.currentframe(1) #letting the initializer
if callee.f_code is initmethod.func_code: #initialize the object
super(self, instance).__setattr__(attr, value)
raise Exception("Object is immutable")
self.__setattr__ = setattr # Heh, I'm adding a dynamic attribute :D
__metaclass__ = ImmutableType
a = 5
def __init__(self, value):
print "assigning b"
self.b = value
m = MyClass("can't change")
print m.a, m.b # these work
m.b = 6 # and these dont.
m.c = 8
> > But most of us are very happy with the dynamic nature of python... I
> > chose python _because_ of it.
> I like it too, since it is indispensable in some situations. But,
> those situations are uncommon enough that I don't mind typing a few
> extra keystrokes to turn the dynamism on.
I find the opposite to be true.
I _usually_ want the dynamism. Even if I'm not using it - I rely on the
dynamism to be there for when I need it.
> > Btw, for performance, there is __slots__,
> That is a good point, we somehow lost sight of that in this thread.
> > with the side-effect that it forbids attribute creation 'on the
> > fly'.
> I have had the impression that this is a somewhat accidental side
> effect and shouldn't be relied on.
Yes, accidental side effect.
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), but it is way easier (and so far, maintanable) to just
add an appropriately named dynamic attribute to the object.
Of course there can be harm - but the fault lies on the user and not the tool.
I specially dislike that I can't add dynamic attributes to an object().
Luis Zarrabeitia (aka Kyrie)
Fac. de Matemática y Computación, UH.
More information about the Python-list