Re: [Python-Dev] Return type of alternative constructors

2016-05-08 Thread Guido van Rossum 
IMO bool is a special case because it's meant to be a final class, and the
implementation of int (which is in C and so can violate most rules) doesn't
respect that.

But in general I think the only reasonable approach is that a construction
class method should return an instance of the subclass; these class methods
have a signature that's constrained by their signature in the base class.

OTOH operators like __add__ cannot be expected to return an instance of the
subclass, because these typically construct an instance using
__new__/__init__, whose signatures are *not* constrained by the base class.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker Etiquette

2016-05-08 Thread Steven D'Aprano 
On Sat, May 07, 2016 at 04:06:51PM -0700, Ethan Furman wrote:
> I just reviewed an issue on the tracker, and found that many, if not 
> all, of my comments made at the time I completely disagree with (both 
> now, and before -- I'm going to claim sleep deprivation).
> 
> Obviously I should post a new comment explaining my thoughts about the 
> issue, but what should I do with the old comments?  Is it acceptable to 
> delete them?

My preference would be not to delete them. Certainly don't delete them 
if others have explicitly replied to them. Even if you no longer agree 
with the conclusion, there may be something of value in the comments.

-- 
Steve
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Return type of alternative constructors

2016-05-08 Thread Nick Coghlan 
On 8 May 2016 at 08:39, Serhiy Storchaka  wrote:
> Should alternative constructor call __new__ and __init__ methods? Thay can
> change signature in derived class.

I think this is typically the way to go (although, depending on the
specific type, the unpickling related methods may be a more
appropriate way for the alternate constructor to populate the instance
state)

> Should it complain if __new__ or __init__ were overridden?

If there are alternate constructors that depend on either the
signature of __new__/__init__, unpickling support, or some other
mechanism for creating new instances, this should be mentioned in the
class documentation as a constraint on subclasses - if subclasses
don't want to meet the constraint, they'll need to override the
affected alternate constructors.

Cheers,
Nick.

P.S. The potential complexity of that is one of the reasons the design
philosophy of "prefer composition to inheritance" has emerged -
subclassing is a powerful tool, but it does mean you often end up
needing to care about more interactions between the subclass and the
base class than you really wanted to.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker Etiquette

2016-05-08 Thread Nick Coghlan 
On 8 May 2016 at 20:56, Steven D'Aprano  wrote:
> On Sat, May 07, 2016 at 04:06:51PM -0700, Ethan Furman wrote:
>> I just reviewed an issue on the tracker, and found that many, if not
>> all, of my comments made at the time I completely disagree with (both
>> now, and before -- I'm going to claim sleep deprivation).
>>
>> Obviously I should post a new comment explaining my thoughts about the
>> issue, but what should I do with the old comments?  Is it acceptable to
>> delete them?
>
> My preference would be not to delete them. Certainly don't delete them
> if others have explicitly replied to them. Even if you no longer agree
> with the conclusion, there may be something of value in the comments.

I generally only delete mine if I've posted to the wrong issue (which
happens sometimes if I have multiple issues open and lose track of
which tab is which).

For other discussions, I figure realising I'd made a mistake on my own
isn't that different from someone else replying to point out the error
- I'm sure there a few tracker comments floating around from
Nick-of-several-hours-later suggesting that
Nick-of-several-hours-earlier probably shouldn't be commenting on
tracker issues when he's in dire need of sleep ;)

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Tracker Etiquette

2016-05-08 Thread Ethan Furman 

On 05/07/2016 04:06 PM, Ethan Furman wrote:


I just reviewed an issue on the tracker, and found that many, if not
all, of my comments made at the time I completely disagree with (both
now, and before -- I'm going to claim sleep deprivation).

Obviously I should post a new comment explaining my thoughts about the
issue, but what should I do with the old comments?  Is it acceptable to
delete them?


Thank you all for your comments.  Old ones kept, new one posted.

--
~Ethan~



___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Ethan Furman 
Currently, the Enum creation process ignores __dunder__ attributes, and 
blocks all _sunder_ attributes.


Because of this, the enum34 backport used __order__ instead of _order_ 
to provide a mechanism for ordering the enum members (which I never 
really liked).


However, I've been working on my aenum [1] package, which uses several 
other _sunder_ attributes (for python2 compatibility) so I enabled 
_order_ instead and promote that spelling in the docs.


Unlike the other _sunder_ attributes, _order_ has no meaningful affect 
in Python 3 so I'd like to change the stdlib Enum to allow it (and 
either ignore completely, or check it is the same as the definition order).


My question is:  Should I put this change in 3.5.2?

- Yes means 3.5.2+ will work with _order_, 3.4, 3.5.0, and 3.5.1
  will not;

- No means 3.4 and all of 3.5 will not.

--
~Ethan~


[1] https://pypi.python.org/pypi/aenum
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] devinabox has moved to GitHub

2016-05-08 Thread Brett Cannon 
https://github.com/python/devinabox

The single issue for devinabox has moved to its own issue tracker, so
there's no need to worry about those issues cluttering b.p.o in the future.
I have made the Python core team I created on GitHub last week have write
privileges and Nick and I as admins on the repository. I have also turned
on the CLA bot for the repository (FYI
https://github.com/python/the-knights-who-say-ni has that bot's code).

I've asked Georg, Antoine, and Benjamin to tell me what I need to do to
shut off -- either by making it read-only or just deleting --
hg.python.org/devinabox.

Now that the migration has seriously begun, the next repos will be the peps
and devguide (slightly more complicated thanks to needing to update
commands for building their online versions). There's also the benchmarks
repo, but that might not get migrated if we start from scratch (see the
speed@ ML about that).

As for cpython, I've been asked to talk about it at the language summit
where I will start a conversation about what the minimal feature set will
need to be to migrate. Once we have  settled on what has to be in place to
migrate the cpython repo then we can start working on that TODO list.
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Guido van Rossum 
If enum were provisional it would be okay, but since it isn't, I think this
change can't go into 3.5.2. Think if this: could any code that works in
3.5.1 be broken by the change?

--Guido (mobile)
On May 8, 2016 1:11 PM, "Ethan Furman"  wrote:

> Currently, the Enum creation process ignores __dunder__ attributes, and
> blocks all _sunder_ attributes.
>
> Because of this, the enum34 backport used __order__ instead of _order_ to
> provide a mechanism for ordering the enum members (which I never really
> liked).
>
> However, I've been working on my aenum [1] package, which uses several
> other _sunder_ attributes (for python2 compatibility) so I enabled _order_
> instead and promote that spelling in the docs.
>
> Unlike the other _sunder_ attributes, _order_ has no meaningful affect in
> Python 3 so I'd like to change the stdlib Enum to allow it (and either
> ignore completely, or check it is the same as the definition order).
>
> My question is:  Should I put this change in 3.5.2?
>
> - Yes means 3.5.2+ will work with _order_, 3.4, 3.5.0, and 3.5.1
>   will not;
>
> - No means 3.4 and all of 3.5 will not.
>
> --
> ~Ethan~
>
>
> [1] https://pypi.python.org/pypi/aenum
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Ethan Furman 

On 05/08/2016 03:29 PM, Guido van Rossum wrote:


If enum were provisional it would be okay, but since it isn't, I think
this change can't go into 3.5.2. Think if this: could any code that
works in 3.5.1 be broken by the change?


No, but with the change code that works in 3.5.2 could break in 3.5.1 or 
3.5.0.


It's a 2/3 compatibility issue with enum34 and aenum which support 
_order_, and Python3.4+ which does not.  The work-around is to use 
__order__ instead (or use enum34 or aenum instead ;) .


Either way, it's only similarity to a bug is I should have named it 
_order_ in the beginning, and put the compatibility shim into the stdlib 
version at the same time.


--
~Ethan~
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Return type of alternative constructors

2016-05-08 Thread Guido van Rossum 
On Sun, May 8, 2016 at 4:49 AM, Nick Coghlan  wrote:

> On 8 May 2016 at 08:39, Serhiy Storchaka  wrote:
> > Should alternative constructor call __new__ and __init__ methods? Thay
> can
> > change signature in derived class.
>
> I think this is typically the way to go (although, depending on the
> specific type, the unpickling related methods may be a more
> appropriate way for the alternate constructor to populate the instance
> state)
>

Honestly, either of these sounds like fragile, even though I really want
the alternative constructor to return an instance of the subclass (else why
invoke it through the subclass).


> > Should it complain if __new__ or __init__ were overridden?
>
> If there are alternate constructors that depend on either the
> signature of __new__/__init__, unpickling support, or some other
> mechanism for creating new instances, this should be mentioned in the
> class documentation as a constraint on subclasses - if subclasses
> don't want to meet the constraint, they'll need to override the
> affected alternate constructors.
>

Putting this constraint in the docs sounds fragile too. :-(


> Cheers,
> Nick.
>
> P.S. The potential complexity of that is one of the reasons the design
> philosophy of "prefer composition to inheritance" has emerged -
> subclassing is a powerful tool, but it does mean you often end up
> needing to care about more interactions between the subclass and the
> base class than you really wanted to.
>

Indeed!

We could also consider this a general weakness of the "alternative
constructors are class methods" pattern. If instead these alternative
constructors were folded into the main constructor (e.g. via special
keyword args) it would be altogether clearer what a subclass should do.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Guido van Rossum 
On Sun, May 8, 2016 at 3:43 PM, Ethan Furman  wrote:

> On 05/08/2016 03:29 PM, Guido van Rossum wrote:
>
> If enum were provisional it would be okay, but since it isn't, I think
>> this change can't go into 3.5.2. Think if this: could any code that
>> works in 3.5.1 be broken by the change?
>>
>
> No, but with the change code that works in 3.5.2 could break in 3.5.1 or
> 3.5.0.
>

That's bad too (and it's one reason why we're generally strict about the
"no new features in bugfix releases" rule.


> It's a 2/3 compatibility issue with enum34 and aenum which support
> _order_, and Python3.4+ which does not.  The work-around is to use
> __order__ instead (or use enum34 or aenum instead ;) .
>
> Either way, it's only similarity to a bug is I should have named it
> _order_ in the beginning, and put the compatibility shim into the stdlib
> version at the same time.
>

I think it's a case of water under the bridge and learning to live with
your mistakes.

-- 
--Guido van Rossum (python.org/~guido)
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Ethan Furman 

On 05/08/2016 03:52 PM, Guido van Rossum wrote:


I think it's a case of water under the bridge and learning to live with
your mistakes.


Better than dying from them.

:)

--
~Ethan~


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Return type of alternative constructors

2016-05-08 Thread Greg Ewing 

Guido van Rossum wrote:
We could also consider this a general weakness of the "alternative 
constructors are class methods" pattern. If instead these alternative 
constructors were folded into the main constructor (e.g. via special 
keyword args) it would be altogether clearer what a subclass should do.


A useful guideline might be that class methods can be provided
as sugar for alternative constructors, but they should all
funnel through the main constructor.

There's a convention like this in the Objective-C world where
one of an object's "init" methods is supposed to be documented
as the "designated initialiser", so that there is just one
thing that subclasses need to override.

--
Greg


___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Wrong OSX platform in sysconfig.py causing installation problems

2016-05-08 Thread Joseph Lee Nunn III 
Thank you for looking into this for me, but since I fixed my problem by simply 
deleting the old SDKs I’ve moved on.

However let me clarify exactly what was going on one more time, just in case 
you guys decide to pursue further.

I had the old 10.6 SDK in /Developer/SDKs, it could have been ‘special’ in that 
I did alot of weird things for a former project and I just don’t recall.

For the sake of explanation though lets say it wasn’t, what then?

I installed OSX Python 3.5.1, created a virtual environment using the pyvenv 
command from that newly installed Python 3.5.1, and sourced its bin/activate.
Then when running pip install ZODB, the compiler would be passed the -isysroot 
flag for the 10.6 SDK, which would change its include paths and it would find 
no includes or libs (if you sym link the includes into the include directory of 
the virtual env you will get farther and see that the linker does not find libs 
either).  By suppling adding -v to CFLAGS you can have the compiler output the 
include paths and compiler call when running pip install.  That is how I 
noticed the alternate system root supplied by the isysroot flag.  Grepping 
around found me the _sysconfigdata.py file where that stuff was specified, it 
took a bit to realize that file came with the distribution and wasn’t generated 
on my system.

When not in a virtual environment, ZODB would install just fine into the system 
python (2.7).  

Not sure why that is, or what would make the virtual environment different, but 
there you go.

Joseph Nunn
[email protected]
[email protected]


> On May 07 , 2016, at 11:52 PM, Chris Barker  wrote:
> 
> On Sat, May 7, 2016 at 10:59 PM, Chris Barker  > wrote:
> 
>  Trying to decide if I want to go through the hassle of installing an old 
> XCode to see if i can replicate the bug the OP is reporting
> 
> OK, I found this gitHub repo with all the old SDKs:
> 
> https://github.com/phracker/MacOSX-SDKs 
> 
> 
> I put a copy of the 10.6 SDk in it's old location:
> 
> /Developer/SDKs/MacOSX10.6.sdk/
> 
> /before I did that, I did a pip install of zodb in a virtualenv, and all 
> seemed to go fine. THe extensions rae linked against :
> 
> $ otool -L cPersistence.cpython-35m-darwin.so 
>  
> cPersistence.cpython-35m-darwin.so 
> :
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 1197.1.1)
> 
> where that comes from -- who knows?? 
> 
> then I tried again, after putting the sdk in place:
> 
> [note: serious pain the $%^# to get pip to stop using it's cache! ]
> 
> and everything seemed to build fine, and at least one simple test of zodb 
> works fine. And this is how the extensions are linked:
> 
> $  otool -L cPersistence.cpython-35m-darwin.so 
> 
> cPersistence.cpython-35m-darwin.so 
> :
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 
> 125.2.11)
> 
> which is the same as above, but the "current version" is much older -- so 
> does that mean it used the 10.6 SDK
> 
> Anyway, I can't reproduce the OP's bug.
> 
> -CHB
> 
> 
> 
> -- 
> 
> Christopher Barker, Ph.D.
> Oceanographer
> 
> Emergency Response Division
> NOAA/NOS/OR&R(206) 526-6959   voice
> 7600 Sand Point Way NE   (206) 526-6329   fax
> Seattle, WA  98115   (206) 526-6317   main reception
> 
> [email protected] 
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Nick Coghlan 
On 9 May 2016 at 08:43, Ethan Furman  wrote:
> On 05/08/2016 03:29 PM, Guido van Rossum wrote:
>
>> If enum were provisional it would be okay, but since it isn't, I think
>> this change can't go into 3.5.2. Think if this: could any code that
>> works in 3.5.1 be broken by the change?
>
>
> No, but with the change code that works in 3.5.2 could break in 3.5.1 or
> 3.5.0.
>
> It's a 2/3 compatibility issue with enum34 and aenum which support _order_,
> and Python3.4+ which does not.  The work-around is to use __order__ instead
> (or use enum34 or aenum instead ;) .

Needing to use a PyPI alternative to a stdlib module for increased
cross-version consistency is a pretty common experience these days, so
I think that's OK - end users can choose for themselves between the
stability of the stdlib version and the reduced update latency of the
PyPI version.

Cheers,
Nick.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Guido van Rossum 
I wonder if we should add something for this?

--Guido (mobile)
On May 8, 2016 7:18 PM, "Nick Coghlan"  wrote:

> On 9 May 2016 at 08:43, Ethan Furman  wrote:
> > On 05/08/2016 03:29 PM, Guido van Rossum wrote:
> >
> >> If enum were provisional it would be okay, but since it isn't, I think
> >> this change can't go into 3.5.2. Think if this: could any code that
> >> works in 3.5.1 be broken by the change?
> >
> >
> > No, but with the change code that works in 3.5.2 could break in 3.5.1 or
> > 3.5.0.
> >
> > It's a 2/3 compatibility issue with enum34 and aenum which support
> _order_,
> > and Python3.4+ which does not.  The work-around is to use __order__
> instead
> > (or use enum34 or aenum instead ;) .
>
> Needing to use a PyPI alternative to a stdlib module for increased
> cross-version consistency is a pretty common experience these days, so
> I think that's OK - end users can choose for themselves between the
> stability of the stdlib version and the reduced update latency of the
> PyPI version.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   [email protected]   |   Brisbane, Australia
> ___
> Python-Dev mailing list
> [email protected]
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe:
> https://mail.python.org/mailman/options/python-dev/guido%40python.org
>
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Minor change to Enum -- should it go into 3.5.2?

2016-05-08 Thread Ethan Furman 

On 05/08/2016 07:15 PM, Nick Coghlan wrote:

On 9 May 2016 at 08:43, Ethan Furman wrote:



It's a 2/3 compatibility issue with enum34 and aenum which support _order_,
and Python3.4+ which does not.  The work-around is to use __order__ instead
(or use enum34 or aenum instead ;) .


Needing to use a PyPI alternative to a stdlib module for increased
cross-version consistency is a pretty common experience these days, so
I think that's OK - end users can choose for themselves between the
stability of the stdlib version and the reduced update latency of the
PyPI version.


Are you saying I shouldn't bother updating the 3.6 Enum to ignore _order_?

--
~Ethan~

___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Return type of alternative constructors

2016-05-08 Thread Nick Coghlan 
On 9 May 2016 at 08:50, Guido van Rossum  wrote:
> On Sun, May 8, 2016 at 4:49 AM, Nick Coghlan  wrote:
>> P.S. The potential complexity of that is one of the reasons the design
>> philosophy of "prefer composition to inheritance" has emerged -
>> subclassing is a powerful tool, but it does mean you often end up
>> needing to care about more interactions between the subclass and the
>> base class than you really wanted to.
>
> Indeed!
>
> We could also consider this a general weakness of the "alternative
> constructors are class methods" pattern. If instead these alternative
> constructors were folded into the main constructor (e.g. via special keyword
> args) it would be altogether clearer what a subclass should do.

Unfortunately, even that approach gets tricky when the inheritance
relationship crosses the boundary between components with independent
release cycles.

In my experience, this timeline is the main one that causes the pain:

* Base class is released in Component A (e.g. CPython)
* Subclass is released in Component B (e.g. PyPI module)
* Component A releases a new base class construction feature

Question: does the new construction feature work with the existing
subclass in Component B if you combine it with the new version of
Component A?

When alternate constructors can be implemented as class methods that
work by creating a default instance and using existing public API
methods to mutate it, then the answer to that question is "yes", since
the default constructor hasn't changed, and the new convenience
constructor isn't relying on any other new features.

The answer is also "yes" for existing subclasses that only add new
behaviour without adding any new state, and hence just use the base
class __new__ and __init__ without overriding either of them.

It's when the existing subclasses overrides __new__ or __init__ and
one or both of the following is true that things can get tricky:

- you're working with an immutable type
- the API implementing the post-creation mutation is a new one

In both of those cases, the new construction feature of the base class
probably won't work right without updates to the affected subclass to
support the new capability (whether that's supporting a new parameter
in __new__ and __init__, or adding their own implementation of the new
alternate constructor).

I'm genuinely unsure that's a solvable problem in the general case -
it seems to be an inherent consequence of the coupling between
subclasses and base classes during instance construction, akin to the
challenges with subclass compatibility of the unpickling APIs when a
base class adds new state.

However, from a pragmatic perspective, the following approach seems to
work reasonably well:

* assume subclasses don't change the signature of __new__ or __init__
* note the assumptions about the default constructor signature in the
alternate constructor docs to let implementors of subclasses that
change the signature know they'll need to explicitly test
compatibility and perhaps provide their own implementation of the
alternate constructor

You *do* still end up with some cases where a subclass needs to be
upgraded before a new base class feature works properly for that
particular subclass, but subclasses that *don't* change the
constructor signature "just work".

Cheers,
Nick.

P.S. It occurs to me that a sufficiently sophisticated typechecker
might be able to look at all of the calls to "cls(*args, **kwds)" in
class methods and "type(self)(*args, **kwds)" in instance methods, and
use those to define a set of type constraints for the expected
constructor signatures in subclassses, even if the current code base
never actually invokes those code paths.

-- 
Nick Coghlan   |   [email protected]   |   Brisbane, Australia
___
Python-Dev mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com