Python dynamic attribute creation

Stephen Hansen me+list/python at ixokai.io
Tue Jun 29 13:20:15 EDT 2010


On 6/29/10 9:46 AM, WANG Cong wrote:
>>> 1) Disallow dynamic attribute creations by assignments _by default_,
>>> thus I expect an error when I do:
>>
>> So far I only did tell you _how_ it is in Python. If I understand your
>> question about the design of the language correctly than you would like
>> Python to detect the typo. Let's for the moment assume that the
>> declaration would be decoupled from assigning a value.
>>
> Nope, I would like Python not to allow adding a new attribute via an
> assignment by default, detecting the typo is a side-effect.

Python does not do restrictions by default, period. If you wish to not 
add new attributes to objects, it is up to you to police yourself. This 
is Python. This is how Python rolls.


> But if so why setattr() still exists? What is it for if we can do the
> same thing via assignments? Also, in order to be perfect, Python should
> accept to add dynamic attributes dynamically, something like PEP
> 363. That doesn't happen.

What does perfection have to do with anything? Python does not strive 
for perfection. More then that, it rejects the entire idea of perfection 
when it gets in the way of simply solving problems in an easy, clean, 
readable, and reliable way. "Practicality beats purity".

PEP 363 proposes adding new syntax: for new syntax to be accepted into 
the language one must meet a *very* high bar. One must show a clear, 
compelling reason why this new mental burden is worth increasing the 
complexity of the language.

Syntax won't get added to make the language more "perfect" to some 
ideals (especially not ideals to some paradigm like OOP, as opposed to 
its own internal ideals of readability, ease and practicality).

Syntax is a burden. Every change in syntax, every addition in syntax, 
requires everyone's to mental investment to increase: it costs more 
mental energy to use the language, to fully understand it, then it did 
before.

There has to be some real use-case, some *real* code out in the *real* 
world which is doing something, and its hard-- and you have to do this 
hard thing often enough that you are burdened by it-- and only then is 
it reasonable to ask for syntax to be added to Python to make it easier.

Alternatively, if there's something that's not even possible for you to 
to today, but you have a *real* problem you'd like to solve, a *real* 
need to do something new: then you can ask for something to be added to 
the language.

Barring that, its not worth the cost of making the language bigger. PEP 
363 didn't meet that burden: sure, there's times when you need to do 
that-- I've done it several times-- but the solutions that exist to 
solve that problem (setattr) are "good-enough" that it isn't really much 
of a burden to do. Moreover, during the discussion of PEP 363, someone 
proposed (Raymond Hettinger, I think) an excellent recipe which not only 
made the 'good enough' quite a bit easier, but which a lot of people 
thought was even cleaner then syntax.

So, PEP363 went the way of the dodo.

Is Python perhaps less perfect, pure, with that addition to the language 
denied?

Who cares? Perfection is what the Borg* worship, I like understandable. :)

-- 

    ... Stephen Hansen
    ... Also: Ixokai
    ... Mail: me+list/python (AT) ixokai (DOT) io
    ... Blog: http://meh.ixokai.io/

P.S. *Not calling anyone a borg! Seven of Nine said they worshipped 
perfection, remember?



More information about the Python-list mailing list