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 yo
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
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
> >> thi
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
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 ‘spec
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 shou
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
Python-Dev@python.org
https://mail.pytho
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?
>>
>
>
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
>
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
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 __dunde
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
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 a
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 th
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 s
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
appropr
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 n
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; th
18 matches
Mail list logo
