Python dynamic attribute creation
in [Python]
|
From: Ethan Furman on 29 Jun 2010 13:25 WANG Cong wrote: > On 06/29/10 17:48, Andre Alexander Bell <post(a)andre-bell.de> wrote: > >> As said previously I don't think one should differentiate between meta >> programming and programming within the language, since the former is >> nothing different than the latter. >> > > If you check other programming language rather than Python, it is > different. Even in Ruby which is also a dynamic language. If Python were going to be the same as other languages, what would be the point of having Python? >> 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. I, for one, am very happy that Python allows it -- if I wanted to jump through hoops for simple things I'd use some other language. > 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. Setattr and friends exist to work with dynamic attributes. "The Perfect Language" does not exist, and never will. I'm not even sure it could exist for a single person, let alone a group of people with disparate needs, patterns of thought, etc. ~Ethan~
From: Stephen Hansen on 29 Jun 2010 13:10 On 6/29/10 9:48 AM, WANG Cong wrote: > On 06/27/10 12:01, Carl Banks<pavlovevidence(a)gmail.com> wrote: > >> On Jun 25, 8:24 pm, WANG Cong<xiyou.wangc...(a)gmail.com> wrote: >>> Understand, but please consider my proposal again, if we switched to: >>> >>> setattr(foo, 'new_attr', "blah") >>> >>> by default, isn't Python still dynamic as it is? (Please teach me if I >>> am wrong here.) >>> >>> This why I said the questionable thing is not so much related with dynamic >>> programming or not. >> >> Because it makes dynamicism harder to do. >> >> Like I said, Python's goal isn't simply to make dynamicism possible, >> it's to make it easy. >> >> "foo.new_attr = 'blah'" is easier than using setattr. >> > > I do agree it's easier, but why do we need this to be easy? This is > really my question. The question is fundamentally invalid, really. "Why do we need this--" What does need have to do with it? We use the standard assignment and deletion semantics because there's no reason not to; the syntax is readable, understandable, straight-forward, and useful. "Why not make it harder--" you've basically asked repeatedly. Why would we make it harder? There's no reason to. There's no reason to change to "setattr by default", for although it would make Python dynamic, it would be harder to be dynamic. When given a choice between "easier" and "harder" the answer is simply, always, easier. It is not for us to defend *why* -- easier wins, period. If you think that harder would be better, it is for you to defend why it *needs* to be harder. Not vice versa. "It is easier" is, by itself, the end of the justification. There need be no other, unless there is some compelling reason why making a certain thing easier is *bad* -- this is a real consideration that is made on occasion, but the burden of proof is on you. > Also, since it is easier, why not drop the harder one, setattr()? Why would we? There are some corner cases where setattr is easier then other options (such as thing.__dict__[key]). There is no exclusive-OR here. There's no reason to drop "the harder one". -- ... Stephen Hansen ... Also: Ixokai ... Mail: me+list/python (AT) ixokai (DOT) io ... Blog: http://meh.ixokai.io/
From: Stephen Hansen on 29 Jun 2010 13:20 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?
From: Carl Banks on 29 Jun 2010 18:16 On Jun 29, 9:48 am, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: > On 06/27/10 12:01, Carl Banks <pavlovevide...(a)gmail.com> wrote: > > > > > > > On Jun 25, 8:24 pm, WANG Cong <xiyou.wangc...(a)gmail.com> wrote: > >> Understand, but please consider my proposal again, if we switched to: > > >> setattr(foo, 'new_attr', "blah") > > >> by default, isn't Python still dynamic as it is? (Please teach me if I > >> am wrong here.) > > >> This why I said the questionable thing is not so much related with dynamic > >> programming or not. > > > Because it makes dynamicism harder to do. > > > Like I said, Python's goal isn't simply to make dynamicism possible, > > it's to make it easy. > > > "foo.new_attr = 'blah'" is easier than using setattr. > > I do agree it's easier, but why do we need this to be easy? This is > really my question. Because the guy who wrote Python (our BDFL, Guido van Rossum) knows and understands your objection, but disagrees with you nonetheless. I've already told you why, and that's just going to have to be your answer. There's really nothing more to it than that. Carl Banks
From: Andre Alexander Bell on 30 Jun 2010 05:01
On 06/29/2010 06:46 PM, WANG Cong wrote: > On 06/29/10 17:48, Andre Alexander Bell <post(a)andre-bell.de> wrote: >>>>> var a >>>>> a >> -> should raise an variable 'unset' exception >> >> Keep in mind that the module you are writing in is just an object as is >> any function or method. So using local variables therein you are doing >> exactly what you want to abandon from the OOP part. >> > > Hmm, this looks really appealing. I actually very much prefer Python's implementation with direct assignment, just because it's short and comprehensible. Regards Andre |