Giovanni Bajo schrieb:
>>> To me, the killer feature would be that in C++ you can implement a smart
>>> pointer which takes care of incref/decref automatically for 99% of the
>>> code.
>>> This would be a terrific tool for the extension/core writers.
>> Of course, this would also break in presen
Guido van Rossum wrote:
> I've been thinking about this too, and I think it's reasonable to let
> the metaclass provide the dict to be used as locals. This is easier
> when the metaclass is given in the class header, e.g. by way of a base
> class, or through the default metaclass. Although the defa
Talin <[EMAIL PROTECTED]> wrote:
[snip]
> The main controversies are:
Controversy is perhaps overstating it. There was disagreement. But it
wasn't 300 posts and no names were called (that I can remember).
> 1) How generalized the syntax should be.
>
> Several people, upon seeing your suggesti
At 11:30 AM 12/16/2006 -0800, Talin wrote:
>The general idea is to have the metaclass create a mapping object which
>is used as the 'locals' dictionary for the suite following the class
>statement. There would be some special-named function of the metaclass,
>such as '__metadict__', which would con
Josiah Carlson wrote:
> Talin <[EMAIL PROTECTED]> wrote:
>> There's also Josiah Carlson's proposal which separates the 'metaclass'
>> function into two parts, the 'dict creation part' and the 'class
>> finishing part'. (I.e. type= and dict=.) I would rather see them
>> unified, as it makes the
Josiah Carlson wrote:
>> 2) What should the interface on the metaclass look like.
>>
>> The general idea is to have the metaclass create a mapping object which
>> is used as the 'locals' dictionary for the suite following the class
>> statement. There would be some special-named function of the
Phillip J. Eby wrote:
> At 11:30 AM 12/16/2006 -0800, Talin wrote:
>> The general idea is to have the metaclass create a mapping object which
>> is used as the 'locals' dictionary for the suite following the class
>> statement. There would be some special-named function of the metaclass,
>> such as
Phillip J. Eby wrote:
> There's mine, where you simply create mcls(name, bases, {}) and then map
> locals operations to get/set/delattr operations on the class. This
> would presumably be done using a simple mapping proxy, but it would be a
> built-in type rather than the user having to implement
Talin <[EMAIL PROTECTED]> wrote:
>
> Josiah Carlson wrote:
> > Talin <[EMAIL PROTECTED]> wrote:
> >> There's also Josiah Carlson's proposal which separates the 'metaclass'
> >> function into two parts, the 'dict creation part' and the 'class
> >> finishing part'. (I.e. type= and dict=.) I woul
At 02:39 PM 12/16/2006 -0700, 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
At 12:38 PM 12/16/2006 -0800, Talin wrote:
>Phillip J. Eby wrote:
>>At 11:30 AM 12/16/2006 -0800, Talin wrote:
>>>The general idea is to have the metaclass create a mapping object which
>>>is used as the 'locals' dictionary for the suite following the class
>>>statement. There would be some special
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 use case? Everything I'd
Talin wrote:
> My personal feeling on this issue is that just because the "keyword=X"
> syntax opens up other possibilities, doesn't mean we have to use them.
Even if the syntax was never used for anything else,
I still don't like it. Metaclasses are an elegant
concept that deserves an equally el
Josiah Carlson wrote:
> That could be trivially extended to support a tuple syntax for handling
> meta dictionary support...
>
> class Foo(A, B) is type, dict:
> ...
-1. You're mangling my lovely syntax -- it no
longer makes any sense!
--
Greg
___
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 a single operation, which, according to the discu
At 12:53 PM 12/17/2006 +1300, 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
16 matches
Mail list logo
