Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Re: Python dynamic attribute creation

Reply
Thread Tools

Re: Python dynamic attribute creation

 
 
Andre Alexander Bell
Guest
Posts: n/a
 
      06-29-2010
On 06/25/2010 03:15 PM, WANG Cong wrote:
> 1) Modifying a class attribute is metaprogramming, and this is modifying
> a class, i.e. adding a new attribute to it, thus this should belong
> to metaprogramming. (I know, strictly speaking, maybe my definition of
> "metaprogramming" here is incorrect, I _do_ welcome someone could
> correct me if I am really wrong, but that is not the main point here,
> please don't go off-topic.)


We should define meta programming a little more. First attempt:

Programming is the art of writing down instructions such that when
executed accordingly will do what has been pre-specified.

Meta programming is the art of writing down instructions such that when
executed accordingly will program instructions that when executed
accordingly will do what has been pre-specified.

>From this definition I would argue that a dynamic attribute assignement

is _not_ meta programming. It is just modifying an object.

> 2) Metaprogramming should be distinguished with non-meta programming,
> like templates in C++, it is obvious to see if you are using template
> metaprogramming in C++.


In my opinion meta programming is programming. It's just changing the
view a little bit such that the program itself is nothing but data.

> 3) Thus, allowing dynamic attribute creation by assignment _by default_
> is not a good design for me. It is not obvious at all to see if I am
> doing metaprogramming at a first glance.


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.

> 4) Also, this will _somewhat_ violate the OOP princples, in OOP,
> this is and should be implemented by inherence.


This is another point. Whether or not a language allows dynamic or
static meta programming is completely orthogonal to whether or not it is
a pure OO language.

Python is not pure OO as others already did explain. You may still use
it in pure OO style.

If you would like to write your program in a complete OO style than
adding an attribute (may as well be a method) from external

class Sample(object):
pass

s = Sample()
s.a = 1

has to be completely omitted. The same goes for adding attributes within
some method of that particular class.

class Sample(object):
def addsomething(self):
self.a = 1

s = Sample()
s.addsomething()

This would have to be omitted as well.

In a complete OO style _no_ further attributes or methods are allowed to
be added beyond the declaration of the class. Where is this declaration
in Python? You might argue it is the __init__ method and that only there
attributes should be added. This is. however, only a convention in Python.

Variable instantiation is dynamic in Python. That is the variable is
declared upon assignment.

If you fire up an interactive session and write

a = 1

then this declares the variable a and assigns a value to that variable.

> 5) This could hide errors silently, for example, when I do:
>
>>>> test.typooooo = "blah"


Yes. Such a typo would not be detected.

> 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.

The first thing that would have to change is that in a class declaration
we would have to specify at least the names of the attributes and
methods. E.g.

class Sample(object):
var a
def __init__(self):
self.a = 1

s = Sample()
s.b = 1
-> Exception

This however would furthermore change the way you would have to write a
function and a method due to possible internal variables

def somefunc():
var a
var b
a = 1
b = 2
return a+b

As soon as you would need a variable you would always first have to
declare that variable and then assign a value.

Even on the interactive shell you would have to do so:

>>> var a
>>> a = 1
>>> b = 2

-> Exception

Why would this declaration be necessary on the shell and in the
function/method? Declaring a variable means adding that variable to the
namespace, i.e. the underlying dictionary. There is one in each object,
the locals() of a function or even the __dict__ of a module.

The downside of this is that Python has no such thing as a variable
without a value. Still you would need such a thing for this approach

>>> var a
>>> a

-> should raise an variable 'unset' exception

The underlying dictionary would need the ability to store keys (variable
names) without values.

This approach increases the code length considerably, just to catch the
typos.

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.

Regards

Andre
 
Reply With Quote
 
 
 
 
Stephen Hansen
Guest
Posts: n/a
 
      06-29-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?
 
Reply With Quote
 
 
 
 
Ethan Furman
Guest
Posts: n/a
 
      06-29-2010
WANG Cong wrote:
> On 06/29/10 17:48, Andre Alexander Bell <(E-Mail Removed)> 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~
 
Reply With Quote
 
Andre Alexander Bell
Guest
Posts: n/a
 
      06-30-2010
On 06/29/2010 06:46 PM, WANG Cong wrote:
> On 06/29/10 17:48, Andre Alexander Bell <(E-Mail Removed)> 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

 
Reply With Quote
 
Stephen Hansen
Guest
Posts: n/a
 
      07-01-2010
On 7/1/10 7:31 AM, WANG Cong wrote:
> On 06/30/10 01:20, Stephen Hansen<me+list/(E-Mail Removed)> wrote:
>
>>> 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".
>>

>
> I don't quite understand the spirit behind. IMHO, being purity should
> not harm the practicality, they are harmonious.


The two are diametrically opposed in fact, quite often. Sometimes that's
not the case, but that is the exception and not the rule.

>> 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.
>>

> But how could the syntax could be a burden?


Syntax is always a burden, by definition. Everything added to the
language is a burden. Each has a cost. Some, that cost is light, and the
benefits great-- but in others

> It is easy to understand.


For you.

It makes it harder for someone to learn the language. _Every_ bit of
syntax does. Its one more thing that you have to learn before you read
down a piece of code and easily grok exactly what its doing.

>> Is Python perhaps less perfect, pure, with that addition to the
>> language denied?
>>
>> Who cares? Perfection is what the Borg* worship, I like understandable.

>
> Well, using setattr() rather than trivial assignments is also
> understandable, in fact, for me the former is even more understandable,
> it shows more clearly when I am adding a new attribute, I am programming
> classes, not non-classes.


For you. You find setattr() more understandable. Others do not. You make
a distinction between "programming classes" and what you previously
called "metaprogramming", others do not.

The importance of "programming classes" is something that exists in your
mind only -- well, yours and anyone who chooses to think so as well,
which is certainly quite a few people.

But I'll thank you to not impose your sense of importance of these
things on me. There is nothing at all notable about the difference of
"programming classes" verses "programming non-classes" to me. You're
free to make the distinction in your own code; not everyone defines
"programming classes" as anything special.

As for setattr... sorry, but your assertion is simply untrue: there is
nothing about it which says you are adding a new attribute. You can use
it to set any attribute you want, even one that already exists and was
defined previously.

One uses assignment syntax when the name of the attribute they are
setting is known at the time when one writes the code.

One uses the setattr function when the name of the attribute is not
known until runtime.

The difference has *nothing at all* to do with "programming classes" or
"dynamic" vs "static".

The existence of one does *nothing at all* to invalidate the utiltiy of
the other.

You use one construct in the usual-case of setting the value of an
attribute which is known at coding-time (irregardless of if that
attribute existed before: /neither/ of these constructs make /any/
distinction between adding a new attribute and replacing an old one that
already existed), and one when the name of that attribute is dependent
on some runtime state.

--

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

 
Reply With Quote
 
Rami Chowdhury
Guest
Posts: n/a
 
      07-01-2010
On 2010-07-01 23:42, WANG Cong wrote:
> On 07/01/10 22:53, Stephen Hansen <me+list/(E-Mail Removed)> wrote:
>
> >
> > One uses assignment syntax when the name of the attribute they are
> > setting is known at the time when one writes the code.
> >
> > One uses the setattr function when the name of the attribute is not
> > known until runtime.
> >
> > The difference has *nothing at all* to do with "programming classes"
> > or "dynamic" vs "static".
> >

>
> This is exactly what I am thinking.
>
> What we differ is that if using both assignment syntax and setattr()
> builtin function is a good design. You think the current design which
> lets them co-exist is more understandable, while I think this is less
> perfect and then not that more understandable.


Is this not the practicality / purity discussion from another subthread?
You think it's "less perfect" (by which I think you actually mean "less pure"
- but please correct me if I'm wrong). But you admit that it's more under-
standable (i.e. it's more practical). Practicality beats purity, so the
"less pure" solution wins.

>
> "Understandable" is hard to define, it differs so much from person to
> person. "Perfect" is a strong sense for which I enjoy programming and
> learn programming languages.
>
> Thanks much for your detailed answers, I like discussing this with you!
>
>
> --
> Live like a child, think like the god.
>
> --
> http://mail.python.org/mailman/listinfo/python-list

----
Rami Chowdhury
"It always takes longer than you expect, even when you take Hofstadter's
Law into account." -- Hofstadter's Law
+1-408-597-7068 / +44-7875-841-046 / +88-01819-245544
 
Reply With Quote
 
Gregory Ewing
Guest
Posts: n/a
 
      07-02-2010
WANG Cong wrote:

> Yeah, my point is why setattr() for dynamic attributes while assignments
> for static attributes?


I think there may be a misunderstanding here. You seem to
be thinking of "dynamic attribute" vs. "static attribute"
as the distinction between creating a new attribute and
modifying an existing one.

But that's not what it means in this context -- "dynamic"
just means that the attribute name is being computed rather
than written into the program. In either case, the attribute
may or may not be pre-existing.

> Why not unify them?


If you mean using exactly the same syntax for both, that would
require making the static case more verbose, e.g. instead of

foo.blarg

you would have to write something like

foo.("blarg")

just to allow for the possibility of writing

foo.(some_arbitrary_expression)

If you keep the existing static-attribute syntax, then you
haven't really unified anything, you've just added a new
syntax for dynamic attributes. And because dynamic attribute
access is extremely rare, it's not considered worth having
a special syntax for it. It's been suggested before, and
rejected on those grounds.

--
Greg
 
Reply With Quote
 
Bruno Desthuilliers
Guest
Posts: n/a
 
      07-02-2010
WANG Cong a écrit :
> On 06/30/10 01:25, Ethan Furman <(E-Mail Removed)> wrote:
>
>>> 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.
>>

>
> Yeah, my point is why setattr() for dynamic attributes while assignments
> for static attributes? Why not unify them?


What is a "dynamic" and what is a "static" attribute ????

> Agreed, but at least, the reason why I am being against so many people
> here is also trying to make Python be more perfect with my
> understanding.


Please start with learning Python's execution model (what exactly
happens at runtime, what most statement are syntactic sugar for etc) and
Python's object model (how are Python objects, classes, methods etc
implemented, attributes lookup rules, metaclasses, descriptors etc).

Then PERHAPS you MIGHT have a chance to help making Python "more perfect".
 
Reply With Quote
 
John Nagle
Guest
Posts: n/a
 
      07-09-2010
On 7/2/2010 1:54 AM, Gregory Ewing wrote:
> WANG Cong wrote:
>
>> Yeah, my point is why setattr() for dynamic attributes while assignments
>> for static attributes?

>
> If you mean using exactly the same syntax for both, that would
> require making the static case more verbose, e.g. instead of
>
> foo.blarg
>
> you would have to write something like
>
> foo.("blarg")
>
> just to allow for the possibility of writing
>
> foo.(some_arbitrary_expression)


Instead of dynamically adding attributes, there's another option:
deriving a class from "dict":

class HTMLtag(dict) :
def __init__(self, tagtype) :
self.tagtype = tagtype

def __str__(self) : # generate source HTML tag
return("<" + self.tagtype + " "
+ " ".join(map(lambda item: '%s="%s"' % item,
self.items()))
+ ">"


tag1 = HTMLtag(a)
tag1['href'] = "http://www.example.com"
tag1['class'] = "adurl"

s = str(tag1) # converts to string


This has some advantages. The elements of the dictionary aren't
in the same namespace as the attributes of object, so there's
no problem with name clashes. Nor is there a problem with
reserved words. BeautifulSoup stores HTML tag attributes as
object attributes, and they have to special case things like
"class".

You can iterate over all the elements of the dictionary (as the
"__str__" function does above) without interference from
attributes which aren't data items.

There's no problem with values that aren't valid attribute
strings. (Python 2.x won't accept Unicode attributes, for example.)

There's no risk of security injection problems because external
data overrode a member name or some crucial data attribute.

If you find yourself having to write code to avoid any of those
problems, like prefixing dynamic attribute names with some symbol to
avoid name clashes (or realize, after reading this, that your code
has a vulnerability because it's not doing that), it may be better
to inherit from "dict" rather than setting attributes explicitly.

John Nagle
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Python dynamic attribute creation Carl Banks Python 26 07-02-2010 09:59 AM
Re: Python dynamic attribute creation Steven D'Aprano Python 15 07-01-2010 03:01 PM
Re: Python dynamic attribute creation Neil Hodgson Python 12 07-01-2010 02:51 PM
Re: Python dynamic attribute creation Bruno Desthuilliers Python 2 06-27-2010 10:35 AM
Implied instance attribute creation when referencing a class attribute Russell Warren Python 5 01-17-2006 05:07 AM



Advertisments