[Python-3000] rethinking pep 3115

[tomer filiba]

On 6/11/07, Nick Coghlan <ncoghlan at gmail.com> 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