On Tue, Feb 12, 2013 at 8:35 AM, Guido van Rossum wrote:
> On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan wrote:
>> 4.__class__ is already bound as soon as we have a class object to bind it
>> to, so we can't move it any earlier. However, it's already early enough to
>> let references to it from t
On 12/02/13 10:56, Jan Kaliszewski wrote:
Wouldn't __initclass__ be readable enough? IMHO it could spare users
trouble with remembering special case.
+1
I approve of the colour of this bikeshed. __init_class__ has too many
underscores.
--
Steven
_
11.02.2013 23:29, Nick Coghlan wrote:
3. I'm trying to avoid any custom magic specific to this method, but
making it implicitly a static or class method is fairly easy if we so
choose - the standard retrieval code during class creation can just
bypass the descriptor machinery, and wrap it in sta
On Mon, Feb 11, 2013 at 2:29 PM, Nick Coghlan wrote:
>
> On 12 Feb 2013 07:44, "Guido van Rossum" wrote:
> >
> > On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote:
> >>
> >> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum
> wrote:
> >> > Hi Nick,
> >> >
> >> > I think this will make a fine add
On 12 Feb 2013 07:44, "Guido van Rossum" wrote:
>
> On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote:
>>
>> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum
wrote:
>> > Hi Nick,
>> >
>> > I think this will make a fine addition to the language. I agree that
>> > it is superior to the alternatives
On Mon, Feb 11, 2013 at 12:57 PM, PJ Eby wrote:
> On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum
> wrote:
> > Hi Nick,
> >
> > I think this will make a fine addition to the language. I agree that
> > it is superior to the alternatives and fulfills a real (if rare) need.
> >
> > I only have a
On Mon, Feb 11, 2013 at 12:44 PM, Guido van Rossum wrote:
> Hi Nick,
>
> I think this will make a fine addition to the language. I agree that
> it is superior to the alternatives and fulfills a real (if rare) need.
>
> I only have a few nits/questions/suggestions.
>
> - With PJE, I think __init_cl
Hi Nick,
I think this will make a fine addition to the language. I agree that
it is superior to the alternatives and fulfills a real (if rare) need.
I only have a few nits/questions/suggestions.
- With PJE, I think __init_class__ should automatically be a class
method. The same way that __new__
Le Mon, 11 Feb 2013 10:15:36 -0500,
Barry Warsaw a écrit :
> On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote:
>
> >Sure, every little addition is "trivial". At the end you have a scary
> >monster made of many little trivial additions along the years, and
> >everyone has to take care not to bre
On Feb 11, 2013, at 08:33 PM, Nick Coghlan wrote:
>I like that. Perhaps the PEP should propose some additional guidance
>in PEP 8 regarding class based metaprogramming?
I wouldn't put it in PEP 8, since it'll glaze the eyes of all but 6 people on
the planet. Probably better as a HOWTO in the doc
On Feb 10, 2013, at 02:34 PM, Antoine Pitrou wrote:
>zope.interface has been ported to Python 3, so the annoyance can't be
>very blocking.
The syntax is different, but I actually prefer the Python 3-compatible syntax
better. It uses a class decorator instead of a magic class attribute, so it's
m
On Feb 10, 2013, at 03:28 PM, Antoine Pitrou wrote:
>Sure, every little addition is "trivial". At the end you have a scary
>monster made of many little trivial additions along the years, and
>everyone has to take care not to break it.
Why Antoine, that surely isn't the case with the import system
On Mon, Feb 11, 2013 at 7:41 AM, PJ Eby wrote:
> On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel wrote:
>> So, the way to explain it to users would be 1) don't use it, 2) if you
>> really need to do something to a class, use a decorator, 3) if you need to
>> decide dynamically what to do, define
On Sun, 10 Feb 2013 16:27:49 -0500
PJ Eby wrote:
> On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan wrote:
> >class Example:
> >@classmethod
> >def __init_class__(cls):
>
> Is the @classmethod required? What happens if it's not present?
>
> Second, will type have a default __i
On Sun, Feb 10, 2013 at 11:48 AM, Stefan Behnel wrote:
> So, the way to explain it to users would be 1) don't use it, 2) if you
> really need to do something to a class, use a decorator, 3) if you need to
> decide dynamically what to do, define __init_class__() and 4) don't forget
> to call super'
On Sun, Feb 10, 2013 at 7:32 AM, Nick Coghlan wrote:
>class Example:
>@classmethod
>def __init_class__(cls):
Is the @classmethod required? What happens if it's not present?
Second, will type have a default __init_class__? (IMO, it should,
otherwise it will be impossible to
On Sun, Feb 10, 2013 at 5:48 PM, Stefan Behnel wrote:
> However, it's hard to say if this "new way of doing it" doesn't come with
> its own can of worms. For example, would cooperative calls to
> "__init_class__" work if a superclass already defines it? Do implementors
> have to remember that? And
Antoine Pitrou, 10.02.2013 15:28:
> On Mon, 11 Feb 2013 00:09:55 +1000 Nick Coghlan wrote:
>> As far as the maintenance burden goes, the patch to enable PEP 422 for
>> types.new_class() is trivial:
>>
>> -return meta(name, bases, ns, **kwds)
>> +cls = meta(name, bases, ns, **kwds)
>> +t
On Mon, 11 Feb 2013 00:09:55 +1000
Nick Coghlan wrote:
>
> As far as the maintenance burden goes, the patch to enable PEP 422 for
> types.new_class() is trivial:
>
> -return meta(name, bases, ns, **kwds)
> +cls = meta(name, bases, ns, **kwds)
> +try:
> +initcl = cls.__init_cl
On Sun, Feb 10, 2013 at 11:34 PM, Antoine Pitrou wrote:
> Nobody can claim this is simple and easy to wrap your head around. It
> is a maintenance burden, and it discourages understanding of the
> underlying model by anyone but language experts.
You think anyone but language experts fully underst
On Sun, Feb 10, 2013 at 11:33 PM, Simon Cross
wrote:
> On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan wrote:
>> For those that don't recall the original discussion, the proposal is
>> to add a new __init_class__ hook, invoked after the class object is
>> created, but before the class decorators ar
On Sun, 10 Feb 2013 23:17:00 +1000
Nick Coghlan wrote:
> On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou wrote:
> > On Sun, 10 Feb 2013 22:32:50 +1000
> > Nick Coghlan wrote:
> >>
> >> Replaces many use cases for dynamic setting of ``__metaclass__``
> >>
On Sun, Feb 10, 2013 at 2:32 PM, Nick Coghlan wrote:
> For those that don't recall the original discussion, the proposal is
> to add a new __init_class__ hook, invoked after the class object is
> created, but before the class decorators are applied. This provides a
> simple approach to inherited p
On Sun, Feb 10, 2013 at 10:47 PM, Antoine Pitrou wrote:
> On Sun, 10 Feb 2013 22:32:50 +1000
> Nick Coghlan wrote:
>>
>> Replaces many use cases for dynamic setting of ``__metaclass__``
>> -
>>
>> For use cases that don't involve com
On Sun, 10 Feb 2013 22:32:50 +1000
Nick Coghlan wrote:
>
> Replaces many use cases for dynamic setting of ``__metaclass__``
> -
>
> For use cases that don't involve completely replacing the defined class,
> Python 2 code that dynami
I wrote PEP 422 (simple class initialization hook) last year after PJE
pointed out that Python 3 style metaclasses made some Python 2 code
impossible to migrate (since the class body could no longer request
modifications to be made to the class after initialization was
complete).
It then languishe
26 matches
Mail list logo
