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

Steven D'Aprano steve at REMOVE-THIS-cybersource.com.au
Thu Jan 15 00:07:41 CET 2009


On Wed, 14 Jan 2009 20:33:01 +0100, Bruno Desthuilliers wrote:

> Paul Rubin a écrit :
>> Bruno Desthuilliers <bruno.42.desthuilliers at websiteburo.invalid>
>> writes:
>>>> I haven't anywhere in this thread as far as I know suggested
>>>> eliminating dynamism from Python,
>>> Nope, but your suggestion would have the same practical result as far
>>> as I'm concerned.
>> 
>> Sorry, I don't comprehend that.
> 
> IIRC, your suggestion was that one should have to explicitely allow
> "dynamic binding" (ie: outside the initializer) of new attributes, and
> that the default vould be to disallow them.



Lots of heat and noise in this discussion, but I wonder, just how often 
do Python programmers use this dynamism *in practice*? I hardly ever do. 
I like that it is there, I like that Python is so easy to use without the 
overhead of Java, but I rarely need *all* the dynamism available.

[sweeping generalization] Most objects people use are built-ins, and you 
can't add attributes to them. I don't think I've ever done subclasses a 
built-in just to get dynamic attributes:

class DynamicInt(int):
    pass

x = DynamicInt(2)
x.attribute = "something"


As far as non built-in classes go:

>>> from decimal import Decimal
>>> d = Decimal('0.5')
>>> d.something = "something"
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
AttributeError: 'Decimal' object has no attribute 'something'

If I recall correctly, the first implementation of Decimal was written in 
Python. Did anyone object to Decimal being re-written in C because they 
missed the ability to add arbitrary attributes to Decimal instances? 

And if they did, I'm pretty sure the answer given would have been: deal 
with it. Subclass Decimal, or use delegation. Don't penalise 99% of uses 
of Decimal for that 1% of uses where you need dynamism.

I think that's a wise decision.



-- 
Steven



More information about the Python-list mailing list