[Tutor] class arguments?

[Kent Johnson]

Forwarding to the list with my reply...

On Fri, Jan 23, 2009 at 1:35 PM, spir <denis.spir at free.fr> wrote:
> Le Fri, 23 Jan 2009 06:45:04 -0500,
> Kent Johnson <kent37 at tds.net> a écrit :
>
>> On Fri, Jan 23, 2009 at 6:04 AM, spir <denis.spir at free.fr> wrote:
>>
>> > Thank you Alan and sorry for not having been clear enough. The point actually was class (definition) attributes. I thought at e.g. Guido's views that lists were for homogeneous sequences as opposed to tuples rather like records. And a way to ensure sich a homogeneity, in the sense of items beeing of the same type or super type.
>> > The straightforward path to ensure that, as I see it, is to add proper argument to a class definition.
>>
>> A simple way to do this is with a class factory function, for example:
>>
>> def makeMonoList(typ, number):
>>   class MonoListSubtype(MonoList):
>>     item_type = type
>>     item_number = number
>>   return MonoListSubtype
>
> That's it! Stupid me!! [Just realize I have a kind of mental blocage that prevents me *imagining* a class beeing defined inside a func. As for me a class is a higher level kind of thing. Actually I also have problems with defs insides defs. Maybe there should be more introduction to that in python literature. Probably it may help and simplify a whole lot of models.]
> Thank you again.
>> then e.g.
>> IntegerList = makeMonoList(int, 5)
>> myIntegerList = IntegerList()
>>
>> This is similar in spirit to collections.namedtuple() in Python 2.6
>> though the implementation is different; namedtuple() actually creates
>> and evaluates the text of the new class definition:
>> http://docs.python.org/library/collections.html#namedtuple-factory-function-for-tuples-with-named-fields
>> http://svn.python.org/view/python/trunk/Lib/collections.py?rev=68853&view=auto
>
> I have watched that some time ago -- as you pointed to it already. I take the opportunity to ask why this contruct is so complicated. There is an alternative in the cookbook (also pointed by Kent, if I remmember well) that is only a few lines long. Something like:
>
> class Record(dict):
>        def __init__(self,**kwargs):
>                dict.__init__(self,kwargs)
>                # and/or
>                self.__dict__ = kwargs
>
> [There are several versons around, +/- based on the same principle]

namedtuple() creates a new class that has exactly the desired
attributes, so it is a bit more specific and typesafe - you have to
have the correct number of points. The generated class subclasses
tuple so it can be used as a dict key (if the items themselves can
be). Class instances are lightweight because they don't have a
__dict__ member.

> Actually, the thing I like at least in the namedtuple recipe is that it writes the class def as a string to be executed:

Yeah, I know...with all the time we spend on the list telling people
not to use eval()...

<snip code>>
> I know there are several advantages:
> * a docstring
> * For large collections of records of the same (sub)type, as the list of field is held  by the class (instances record the actual data only), which spares memory. But doesn't this lead to lower performance, as attribute access by name requires adressing a class level attribute?

The attributes are properties, so attribute access is like a method
call, I suppose this is slower than direct field access but it is a
common Python technique.

> * attributes can be accessed by index, too
>
> Also, as this factory create kinds of records, meaning data constructs with an identical structure, that would perfectly hold table records, why isn't it simply called "record".
> To sum up in a word: why so much *complication*?

I guess you would have to search comp.lang.python or python-dev to
find the reasons, I don't think there is a PEP for this (at least not
referenced in the What's New).

Kent
>
> Denis
> ------
> la vida e estranya
>