On Tue, 30 Nov 2004 22:30:21 +1000, Nick Coghlan <[EMAIL PROTECTED]> wrote: > The proposed use cases sound more appropriate for a "named tuple" than any > sort > of dictionary. (This may have been mentioned in previous discussions. I wasn't > keeping track of those, though)
I agree with it. I was involved in that discussion, and got the the point of listing a few desired features. As I am currently involved into other project, I left it as it was, but I'll resume working as soon as I can. I really think that both (generic objects and named tuples) are slighly different but still very similar approaches to the same problem, so some sort of "unification" of the efforts may be interesting. But there's something more important: while reading this document, and some of the replies, it became clear that the main point is to understand whether this proposed feature (in any possible implementation) is in fact useful enough to deserve a place in the standard library, and also if it represents a good coding style. With some risk of being way too simplistic, it's something like this: -- The people that is favorable to this implementation argue that one should not be required to create a new class just to return a bunch of results. -- The people that is against it point out that, as soon as you start returning multiple values, it's probable that you'll need to implement a class anyway, so it's better off to do it sooner and forget generics (or named tuples) entirely. I see some parallels between this discussion and another one about polymorphism. It's considered good Python practice to rely on interfaces, or protocols, when designing the call signature of a function or method. So if you receive an arbitrary object, you should not check if it's a descendand of some abstract parent type; that's just too rigid, and forces people to deal with complex multiple inheritance stuff, and that's really not needed in Python. There is a better way: just check if it exposes the desired interface, or protocol. The adaptation framework (as described by PEP 246, and extended by the PyProtocols package) is a nice implementation of this concept. A "generic" return object is just like this, but for a different scenario: an adaptable return value, that doesn't enforce a class signature when assigning the return value of a function or method. It's perfectly symmetrical to the usage of interfaces on call. I think that's a better, and much more powerful argument for the implementation of a generic class, and also, for some supporting machinery for it. Extending this reasoning, generic return objects (implemented either as dictionary based, or as named tuples) could be seen as "adaptable" return values. Upon return, one could get such a temporary structure and assign its members into another, more complex class, that would accept fields of the same name, but possibly include other fields and extra functionality. For example: a function that returns a complex time structure does not need to return a "time class". It may return a generic, or named tuple, which is in turn can be assigned to an object that exposes a 'compatible' assignment interface. This assignment can be done by a method of the generic clas itself, according either to the names of the member of the generics, or the order of the tuple, depending on the scenario. For now, that's all that I have to contribute into this discussion. There's also a lot of stuff in the c.l.py archives regarding named tuples and also generics that is surely worth checking. -- Carlos Ribeiro Consultoria em Projetos blog: http://rascunhosrotos.blogspot.com blog: http://pythonnotes.blogspot.com mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] -- http://mail.python.org/mailman/listinfo/python-list
