On 6/11/07, Nick Coghlan <[EMAIL PROTECTED]> wrote: > So instead of being able to write: > > class MyStruct(Struct): > first = 1 > second = 2 > third = 3 > [...] > > Forgive my confusion, but exactly *how* is that meant to be an improvement?
as your example shows, the most common use-case is an ordered dict, so as i was saying, just "upgrading" the type() constructor to accept four arguments solves almost all of the desired use cases. imho, "forward name binding" is an undesired side effect. what i'm trying to say is, this pep is an *overkill*. yes, it is "more powerful" than what i'm suggesting, but my point is we don't want to have all that "power". it's too complex and provides only a marginal benefit. you're just using classes as syntactic sugar for namespaces (because python lacks other syntactic namespaces), which is useful -- but conceptually wrong. python should have introduced a separate namespace construct, not to be confused with classes (something like the "make pep") the pep at hand is basically *overloading* classes into a generic namespace device -- to which i'm saying: (a) it's wrong and (b) it's not that frequently used to deserve complicating the interpreter for that. -tomer P.S. per your "class Something(Struct)" example above, you might want to check out how Construct solves that (see below). Construct's declarative approach is able to express more kinds of relations between data structures than simple structs, such as nested structs, arrays, swtiches, etc. http://construct.wikispaces.com http://sebulbasvn.googlecode.com/svn/trunk/construct/formats/filesystem/mbr.py http://sebulbasvn.googlecode.com/svn/trunk/construct/formats/executable/elf32.py _______________________________________________ Python-3000 mailing list Python-3000@python.org http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
