Forwarding to the list with comments. On Fri, Jan 2, 2009 at 2:47 PM, spir <denis.s...@free.fr> wrote: > On Fri, 2 Jan 2009 11:57:32 -0500 > "Kent Johnson" <ken...@tds.net> wrote: > >> On Fri, Jan 2, 2009 at 11:10 AM, spir <denis.s...@free.fr> wrote: >> > Can someone explain the following? >> > >> > ============================ >> > class Type(object): >> > pass >> > o = Type() >> > o.a = 1 >> > print o, o.a >> > print dir(object) >> > ==> ['__class__', '__delattr__', '__doc__', '__getattribute__', >> > '__hash__', '__init__', >> > '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', >> > '__str__'] >> > ==> no problem >> > o = object() >> > o.a = 1 >> > ==> AttributeError: 'object' object has no attribute 'a' >> > ================================ >> > >> > Type does not create any additional attribute or member, or what? >> > Does this mean that the type 'object' has a hidden __slots__ attr? >> > Then why doesn't Type inherit it, like any attribute? >> >> I'm no expert on this so take this with salt... >> >> IIUC the attributes of built-in objects are hard-coded in tables. The >> hard-coded tables don't include __dict__ attributes so you can't add >> attributes to instances of built-in types. This is similar to what >> __slots__ does for user-defined classes though the implementation is >> different. >> >> The special behaviour of a class with a __slots__ attribute only >> affects the class that defines __slots__, not subclasses. See >> http://docs.python.org/reference/datamodel.html#id3: "The action of a >> __slots__ declaration is limited to the class where it is defined. As >> a result, subclasses will have a __dict__ unless they also define >> __slots__." >> >> Kent >> > Thank you Kent, Alan & Paul. > > Actually, this question arose when I tried to tweak around the topic > "distinction between list & > tuple". I read the pointed docs and some more information. Finally, I think I > caught the point > that (with my words): > << tuples are a light, simple, direct way of building a value "pack" >> > Which puts the notion of tuple in the same category as struct, record and > dict -- except that > a dict's items are named, which is a super important feature. > > Now, what is a pack? It's an easy structure aimed to allow putting things > together /because it > makes sense/. For instance, in the structure above, position and color do not > help at all coding > (they rather make the code more complex), but thay make sense conceptually > and thus help the > developper think -- this is how I see it. > > point > position > x > y > color > r > g > b > > The point is that python does not allow setting object attributes in its > definition -- except for > modules which are both code and scopes/namespaces -- and moreover it does not > allow creating an > object without first definig a class. What I mean is that one caanot simply > write from scratch > something like > > object centre # <==> tuple > 33 > 77 > or > object centre # <==> dict > x = 33 > y = 77 > > But python is extremely supple for attribute setting in the sense that one > can invent an attribute > for an object that the object's class has never heard of. So that I thought > at this feature as > another alternative to tuples or structs, or dicts, in python: > > centre = object() > centre.x, center.y = 33, 77 > > But as seen this does not work. This may be a good reason to define a > "record" or "card" (in the > sense of theat kind of things in a file -- "fiche" in french) sub-type of > object. Fortunately, due > to > python's > huper > flexibility, this is not much work: > > class Card(object): pass > and now: > centre = Card() > centre.x, center.y = 33, 77 > > We could go a bit farther: > > class Card(object): > def __init__(self,**fields): > for name,value in fields.items(): > setattr(self,name,value) > > centre = Card(x=33,y=33) > print "centre: %s,%s" %(centre.x,centre.y) > # ==> centre: 33,33
The Bunch class does this a little more elegantly: http://code.activestate.com/recipes/52308/ but I think this is a good use case for collections.namedtuple(); something like Card = namedtuple('Card', 'x y') > The point is to find an alternative to the largely misunderstood (first, by > myself, before the > debate reached the tutor list) tuple / list difference. With such a data > structure it is possible > to manipulate a pass "packs" in an explicit and obvious manner, for a rather > low price in typing. > For instance: > > def get_coords(...): > ... > return Card(x=..., y=...) > location = get_coords(...) > if location.x == 0 and location.y == 0: > ... > > > I think that once we have understood that tuple are here for that kind of > purpose, the confusion > disappears. Now, remains one major question: > Why do lists hold heterogeneous items? (Why did Guido do that choice, and > then assert that > lists are for homogeneous sequences). To actually *constrain* a collection to be homogeneous seems extremely un-pythonic. In actual fact all containers can hold whatever you want to put in them without restriction (except hashability requirements for sets and dict keys). Kent > denis > > ------ > la vida e estranya > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
