On 2/10/2013 4:29 PM, serhiy.storchaka wrote:
> http://hg.python.org/cpython/rev/4ef048f4834e
> changeset: 82147:4ef048f4834e
> branch: 3.3
> parent: 82145:b322655a4a88
> user:Serhiy Storchaka
> date:Sun Feb 10 23:28:02 2013 +0200
> summary:
> Reject float as uid or g
On 02/10/2013 01:46 PM, PJ Eby wrote:
How about you return FunctionType as your __class__ attribute? ;-)
Your type() will still be different, but isinstance() also considers
the __class__ if it's different from the type(). (At least it does in
2.x, I've not tried it in any 3.x versions yet...)
On Fri, Feb 8, 2013 at 5:44 PM, Stefan Behnel wrote:
> Argh - sorry, got it all wrong. "__instancecheck__()" works exactly the
> other way round. In the type check above, it's the FunctionType type that
> gets asked for an instance check, which doesn't help at all in this case
> because it simply
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
Hi All,
I'm finally getting around to porting some of the packages I maintain
over to Python 3.
One rough edge I've hit: I see the atexit module has moved to be C-based
and, as far as I can tell, no longer allows you to introspect what
atexit functions have been registered.
If I'm writing
16 matches
Mail list logo
