Forwarding to the list with my reply... On Fri, Jan 23, 2009 at 1:35 PM, spir <denis.s...@free.fr> wrote: > Le Fri, 23 Jan 2009 06:45:04 -0500, > Kent Johnson <ken...@tds.net> a écrit : > >> On Fri, Jan 23, 2009 at 6:04 AM, spir <denis.s...@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 > _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
