On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
> Note that the Python interpreter will check to insure that the
> __metacreate__ attribute exists before calling it. This preserves
> backwards compatibility with existing metaclasses.
You might want to be even more explicit and say
If t
On 3/14/07, Jack Diederich <[EMAIL PROTECTED]> wrote:
> I've snipped all the bits I understand and/or agree with.
I'm only quoting what I think needs clarification and/or hasn't
already been addressed. Note you're responding to an old thread; Talin
posted a new version of the PEP and I checked it
Jack Diederich <[EMAIL PROTECTED]> wrote:
[snip]
> I don't understand the keyword args other than 'metaclass.'
> If class D inherits from class C does it also get passed the 'Implements'
> keyword? If it does the same effect could be acheived by making a metaclass
> maker function and just using
On Mon, Mar 12, 2007 at 05:30:48PM -0700, Guido van Rossum wrote:
> Executive summary: I'm defending the PEP and the metaclass syntax it
> proposes, and in fact I want the "clas arguments" to have the same
> syntax as a call, including *args and **kwds. I'm only suggesting to
> find a new name inst
On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Guido van Rossum wrote:
>
> > For uniformity and generality I propose to keep it. So the absolute
> > minimal signature for __prepare__ is actually:
> >
> > def __prepare__(name, bases, *, metaclass=None): ...
> >
> > this way the prepare functio
Ack, I meant to hit cancel and not Send. Please ignore that.
Talin wrote:
> Guido van Rossum wrote:
>>> I'm a bit worried that class headers are going to become
>>> rather cluttered if we start putting all sorts of stuff
>>> in there.
>>>
>>> E.g. are you intending to put __slots__ there? It makes
Guido van Rossum wrote:
>> I'm a bit worried that class headers are going to become
>> rather cluttered if we start putting all sorts of stuff
>> in there.
>>
>> E.g. are you intending to put __slots__ there? It makes
>> sense, but it could lead to some rather long and
>> unwieldy class headers.
>
Guido van Rossum wrote:
> For uniformity and generality I propose to keep it. So the absolute
> minimal signature for __prepare__ is actually:
>
> def __prepare__(name, bases, *, metaclass=None): ...
>
> this way the prepare function can
> distinguish between an explicit and an implied metaclass
"Thomas Wouters" <[EMAIL PROTECTED]> wrote:
> On 3/13/07, BJorn Lindqvist <[EMAIL PROTECTED]> wrote:
> >
> > On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > > > I find this rather cool looking:
> > > > >
> > > > > class C(implements=(I1, I2)): ...
> > >
> > > Me too. :-)
>
>
> Wh
On 3/13/07, BJörn Lindqvist <[EMAIL PROTECTED]> wrote:
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I find this rather cool looking:
> > >
> > > class C(implements=(I1, I2)): ...
>
> Me too. :-)
Who is the receiver of the implements keyword argument in your
example? Should
I think we've definitely entered the bikeshed color discussion now.
I'm holding out for Talin's revised version of the PEP.
On 3/13/07, Nick Coghlan <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > But in slightly longer examples, I think that the looks are
> > significantly improved...
> >
Josiah Carlson wrote:
> But in slightly longer examples, I think that the looks are
> significantly improved...
>
> class Foo(base1, base2, *otherbases, metaclass=mymeta,
> private=True, **kwargs):
> ...
>
> vs.
>
> @@(metaclass=mymeta, private=True, **kwargs)
> class
At 02:26 PM 3/13/2007 -0700, Josiah Carlson wrote:
>But in slightly longer examples, I think that the looks are
>significantly improved...
>
> class Foo(base1, base2, *otherbases, metaclass=mymeta,
> private=True, **kwargs):
> ...
>
>vs.
>
> @@(metaclass=mymeta, private=True
"Guido van Rossum" <[EMAIL PROTECTED]> wrote:
> On 3/13/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
> > I'm a bit worried that class headers are going to become
> > rather cluttered if we start putting all sorts of stuff
> > in there.
> >
> > E.g. are you intending to put __slots__ there? It makes
>
BJörn Lindqvist schrieb:
> On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
>> > > I find this rather cool looking:
>> > >
>> > > class C(implements=(I1, I2)): ...
>>
>> Me too. :-)
>
> But... What does it do? PEP says:
>
> In the new model, the syntax for specifying a metaclass is via a
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> > > I find this rather cool looking:
> > >
> > > class C(implements=(I1, I2)): ...
>
> Me too. :-)
But... What does it do? PEP says:
In the new model, the syntax for specifying a metaclass is via a
keyword argument in the list of base cl
On 3/13/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[Quoting Greg E. quoting Guido]
> > I find this rather cool looking:
> >
> > class C(implements=(I1, I2)): ...
Me too. :-)
Boy, you really like it, don't you. Me, too, though. Will that be the syntax
for ABCs then, rather than that si
Another bulk reply...
On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> Maybe I'm misunderstanding but isn't this a reason that you'd *want*
> the ``**kwargs`` signature? With the plain ``kwargs`` signature from
> the PEP you'd have to do something like::
>
> def __prepare__(name, args,
At 10:33 PM 3/13/2007 +1000, Nick Coghlan wrote:
>Greg Ewing wrote:
> > If they're passed to both, then the signatures become
> >
> >metaclass.__prepare__(name, bases, **kwargs)
> >metaclass(name, bases, body, **kwargs)
> >
> > BTW, I don't think I like the name "__prepare__" much
> > more
At 09:45 PM 3/12/2007 -0600, Steven Bethard wrote:
>On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> > At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
> > >On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > > the signature of the method called will be::
> > > > __prepare__(na
Greg Ewing wrote:
> Nick Coghlan wrote:
>> Along similar lines, I'd be marginally happier with:
>>
>>class Bob(meta=Planet): pass
>
> Is there some way we could remove the word "meta"
> from the syntax altogether? I don't mind using
> it in conversation, but it seems a tad too geeky
> to have
Greg Ewing wrote:
> If they're passed to both, then the signatures become
>
>metaclass.__prepare__(name, bases, **kwargs)
>metaclass(name, bases, body, **kwargs)
>
> BTW, I don't think I like the name "__prepare__" much
> more than "__metacreate__". It seems just as wooly.
> What's being
Nick Coghlan wrote:
> Along similar lines, I'd be marginally happier with:
>
>class Bob(meta=Planet): pass
Is there some way we could remove the word "meta"
from the syntax altogether? I don't mind using
it in conversation, but it seems a tad too geeky
to have as an actual part of the languag
Nick Coghlan wrote:
> - is it intended to typically be a static method or a class method of
> the metaclass? (as it will be called before __new__, an instance method
> of the metaclass wouldn't make sense)
Looks like it will have to be either a staticmethod or
classmethod, or else you'll have
Guido van Rossum wrote:
>
> On 3/10/07, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > class Foo:
> > class __metaclass__:
>
> Personally, I find code that does this completely unreadable
The reason I'd be a little disappointed to lose this is that
it provides a concise way of defining genuin
Steven Bethard wrote:
> Initially, I was concerned that this would break the symmetry with the
> __metaclass__ signature::
>
> def __metaclass__(name, bases, bodydict):
> def __prepare__(name, bases, kwargs):
Can someone clarify something here: Are the keywords going
to be passed to the p
Guido van Rossum wrote:
> On 3/9/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
>>
>> I'd rather __metacreate__ be called something like __createdict__,
>> __creationdict__, __metadict__, __getmetadict__, etc. where it's
>> clearer that the purpose is to create a dict object.
>>
>
> Agreed; there
On 3/12/07, Phillip J. Eby <[EMAIL PROTECTED]> wrote:
> At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
> >On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > > the signature of the method called will be::
> > > __prepare__(name, args, kwargs)
> > > not
> > > __prepare__(name, *arg
At 09:32 PM 3/12/2007 -0600, Steven Bethard wrote:
>On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> > the signature of the method called will be::
> > __prepare__(name, args, kwargs)
> > not
> > __prepare__(name, *args, **kwargs)
> > right?
>
>On 3/12/07, Guido van Rossum <[EMAIL PR
On 3/12/07, Steven Bethard <[EMAIL PROTECTED]> wrote:
> the signature of the method called will be::
> __prepare__(name, args, kwargs)
> not
> __prepare__(name, *args, **kwargs)
> right?
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> I'm not sure anyone has thought much about it
Unsure why you present this as a question; I'm not sure anyone has
thought much about it yet. I wonder if the call shouldn't be made like
this:
__prepare__(name, bases, **kwargs)
so that if you only expect certain specific keyword args you can
define it like this:
def __prepare__(name, base, met
"Guido van Rossum" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
FWIW, I agree that class definition meta-information should go in the
header rather that the body. To me, metaclass=mymeta at the top is much
prettier than __metaclass__ = mymeta in the body. It will also make it
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Do the keywords have to follow the metaclass keyword, or is order
> > irrelevant? While order makes sense, it would be a new precedent for
> > keyword arguments to have an important ord
On 3/12/07, Collin Winter <[EMAIL PROTECTED]> wrote:
> On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
> [snip stuff I agree with]
> > On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > > Do the keywords have to follow the metaclass keyword, or is order
> > > irrelevant? While order ma
At 05:30 PM 3/12/2007 -0700, Guido van Rossum wrote:
>I don't know about sealed, but using class attributes topassing
>parameter (other than the namespace itself) to the metaclass seems a
>pretty lousy mechanism, and keyword arguments in the classdef are a
>much cleaner solution for this need. For
On 3/12/07, Guido van Rossum <[EMAIL PROTECTED]> wrote:
[snip stuff I agree with]
> On 3/9/07, Brett Cannon <[EMAIL PROTECTED]> wrote:
> > Do the keywords have to follow the metaclass keyword, or is order
> > irrelevant? While order makes sense, it would be a new precedent for
> > keyword argument
On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
> I had a conversation with Guido last night at the Python user's group
> meeting, and we hashed out some of the details of how metaclasses should
> work. I've gone ahead and written up a PEP, which I present for your review.
Executive summary: I'm defen
Greg Ewing schrieb:
> Some more metaclass syntax ideas:
>
>class Foo[Meta](bases):
> ...
>
>Meta class Foo(bases):
> ...
>
> although I don't like the way the latter moves the
> 'class' keyword away from the beginning.
You could even unify metaclass and class decorator, if you
Talin wrote:
> The main reason for doing it the way that I did, is to allow for
> the future possibility of the *default* metaclass interpreting some of
> those keywords.
Hmmm. I can see how you would need some way of passing
keywords in order to do that. But in the absence of any
real use cases
Josiah Carlson wrote:
> class foo(...):
> a = ...
> __metaclass__ = callable(a, ...)
Personally I wouldn't mind if it were made a requirement
that __metaclass__, if it is present, must be the first
name bound in the class body (and can't be inside an
if statement, etc.)
Does
Greg Ewing <[EMAIL PROTECTED]> wrote:
> Josiah Carlson wrote:
> > I did have a post that was going to show that they were related, but
> > then I remembered that because of __metaclass__ assignment semantics, it
> > needs to necessarily have access to the class body dictionary at the
> > point of
Josiah Carlson wrote:
> I did have a post that was going to show that they were related, but
> then I remembered that because of __metaclass__ assignment semantics, it
> needs to necessarily have access to the class body dictionary at the
> point of assignment, so the compiler, etc., cannot be tau
Josiah Carlson wrote:
> As such, the compiler, etc., needs to be taught to pull out the
> __metaclass__ definition before executing the class body, but that's
> better than mucking with the syntax of class foo(...).
I'd be happy with that.
Also, for the name of the method for creating the
dict,
Talin wrote:
> I'll give you an example: Suppose the author of Pyrex realizes that
Of course, only an idiot would be unaware that "the author of Pyrex" is
in fact the person who he is replying to. Which means I must have meant
to do that. Uh-huh. Right. :)
-- Talin
Greg Ewing wrote:
> Another thought: It's not strictly necessary to
> allow for arguments to the metaclass, since the same
> effect can be achieved with a factory function, like
> we do for decorators.
True. The main reason for doing it the way that I did, is to allow for
the future possibility o
Some more metaclass syntax ideas:
class Foo[Meta](bases):
...
Meta class Foo(bases):
...
although I don't like the way the latter moves the
'class' keyword away from the beginning.
Another thought: It's not strictly necessary to
allow for arguments to the metaclass, since the sa
Talin wrote:
> The relation
> between a class and a metaclass isn't well-expressed with 'as', 'is', or
> 'equals'.
Okay, then make it
class Foo(base1, base2) isa MyMeta:
...
--
Greg
___
Python-3000 mailing list
Python-3000@python.org
http://
"Phillip J. Eby" <[EMAIL PROTECTED]> wrote:
> At 12:40 PM 3/10/2007 -0800, Josiah Carlson wrote:
>
> >Talin <[EMAIL PROTECTED]> wrote:
> > > I strongly feel that this makes *using* metaclasses way too complex. A
> > > person wanting to create a C struct or a database record should simply
> > > ha
At 12:40 PM 3/10/2007 -0800, Josiah Carlson wrote:
>Talin <[EMAIL PROTECTED]> wrote:
> > I strongly feel that this makes *using* metaclasses way too complex. A
> > person wanting to create a C struct or a database record should simply
> > have to say "metaclass=cstruct" - they shouldn't have to de
Talin <[EMAIL PROTECTED]> wrote:
> I strongly feel that this makes *using* metaclasses way too complex. A
> person wanting to create a C struct or a database record should simply
> have to say "metaclass=cstruct" - they shouldn't have to declare a bunch
> of individual pieces, all of which have
At 08:45 PM 3/10/2007 +1300, Greg Ewing wrote:
>Jack Diederich wrote:
>
> > I am a very big fan of ordered dicts in classes. One possibility is that
> > suites in classes always store their order in a special dict that keeps a
> > side list of key order. A final invisible class decorator around
>
Josiah Carlson wrote:
> There are two semantics that I would be happy with. Either force
> metaclasses to have a .metadict() or equivalent method (or a callable
> attribute in the case of arbitrary callables), or even allow
> __metaclass__ to be a tuple:
>
> class foo(...):
> __metacl
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Talin wrote:
>
> >class Foo(base1, base2, metaclass=mymeta):
> > ...
>
> -1 on this syntax, I think it's ugly.
>
> Alternative proposals:
>
>class Foo(base1, base2) as MyMeta:
> ...
While I don't particularly like the foo(b
Jack Diederich schrieb:
> I am a very big fan of ordered dicts in classes. One possibility is that
> suites in classes always store their order in a special dict that keeps a
> side list of key order. A final invisible class decorator around
> every class would then toss out the order and leave
Greg Ewing wrote:
> Talin wrote:
>
>>class Foo(base1, base2, metaclass=mymeta):
>> ...
>
> -1 on this syntax, I think it's ugly.
All I can say is, beauty is in the eye, etc...in any case, I'm not the
one to decide what's pretty and what's not.
> Alternative proposals:
>
>
Josiah Carlson wrote:
> Also, depending on the use, one may want to know the order in a 'move to
> end' fashion (if a is assigned to multiple times, it ends up in the
> ordering as if only the last assignment was done).
This is why I feel it is insufficient to keep just a record of what key
names
Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> Jack Diederich wrote:
>
> > I am a very big fan of ordered dicts in classes. One possibility is that
> > suites in classes always store their order in a special dict that keeps a
> > side list of key order. A final invisible class decorator around
> >
Jack Diederich wrote:
> I am a very big fan of ordered dicts in classes. One possibility is that
> suites in classes always store their order in a special dict that keeps a
> side list of key order. A final invisible class decorator around
> every class would then toss out the order and leave o
Talin wrote:
>class Foo(base1, base2, metaclass=mymeta):
> ...
-1 on this syntax, I think it's ugly.
Alternative proposals:
class Foo(base1, base2) as MyMeta:
...
or
class Foo(base1, base2) = MyMeta:
...
>class Foo(base1, base2, metaclass=mymeta, priv
On Fri, Mar 09, 2007 at 12:44:36PM -0800, Talin wrote:
> I had a conversation with Guido last night at the Python user's group
> meeting, and we hashed out some of the details of how metaclasses should
> work. I've gone ahead and written up a PEP, which I present for your review.
> --
On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
> I had a conversation with Guido last night at the Python user's group
> meeting, and we hashed out some of the details of how metaclasses should
> work. I've gone ahead and written up a PEP, which I present for your review.
> ---
On 3/9/07, Talin <[EMAIL PROTECTED]> wrote:
> PEP: xxx
> Title: Metaclasses in Python 3000
Thanks for writing this.
> This attribute is a method named __metacreate__, which is invoked
> before the evaluation of the class body, and which has the
> following form:
>
> classdict
I had a conversation with Guido last night at the Python user's group
meeting, and we hashed out some of the details of how metaclasses should
work. I've gone ahead and written up a PEP, which I present for your review.
PEP: xxx
Title: Metaclasses in P
63 matches
Mail list logo
