[Tutor] tuple & object's attributes (changed)

[Kent Johnson]

Forwarding to the list with comments.

On Fri, Jan 2, 2009 at 2:47 PM, spir <denis.spir at free.fr> wrote:
> On Fri, 2 Jan 2009 11:57:32 -0500
> "Kent Johnson" <kent37 at tds.net> wrote:
>
>> On Fri, Jan 2, 2009 at 11:10 AM, spir <denis.spir at 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
>