Greg Ewing wrote:
> The main use case for all this seems to be that
> some metaclasses would like to know the order in
> which attributes were defined. So here's an
> alternative proposal: Leave the syntax the way it
> is, and *always* use a specialised dict that
> remembers the order of definition
On 16 Dec, 2006, at 22:39, Steven Bethard wrote:
The main issue for me is that I think that its important to
distinguish
between get/set operations that are done at class definition time,
and
get/set operations that are done later, after the class is created.
Why? Can you explain your
On 12/17/06, Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Say I have a metaclass X. Say that I've been using metaclass X since
> Python 2.2 days. One day I hear that shortly after Py3k, __metaclass__
> is going away and I need to start using some other syntax (say the
> metaclass= syntax for argum
(wasn't quite done with that last message, so I'll just update the parts
where I wasn't finished)
Josiah Carlson <[EMAIL PROTECTED]> wrote:
> Talin <[EMAIL PROTECTED]> wrote:
> > I don't see why any existing metaclasses would need to be re-written -
> > see below.
For people using the old synta
A point in favour of the current syntax and semantics
is that you can do things like
class C:
class __metaclass__(type):
...
or even, if you're feeling particularly devious,
class C:
def __metaclass__(name, bases, namespace):
...
An enhanced namespace dict would re
Talin <[EMAIL PROTECTED]> wrote:
>
>
> Josiah Carlson wrote:
> > Maybe I'm strange, but I don't like the precreation/double calling
> > semantic. It just seems...sloppy? It requires modification of all
> > current metaclasses to update to the new metaclass= syntax, just to
> > possibly support
