Charles-François Natali writes:
> 2014-03-15 21:44 GMT+00:00 Nikolaus Rath :
>
>> Guido van Rossum writes:
>> > This downside of using subclassing as an API should be well known by now
>> > and widely warned against.
>>
>> It wasn't known to me until now. Are these downsides described in some
>>
2014-03-15 21:44 GMT+00:00 Nikolaus Rath :
> Guido van Rossum writes:
> > This downside of using subclassing as an API should be well known by now
> > and widely warned against.
>
> It wasn't known to me until now. Are these downsides described in some
> more detail somewhere?
>
The short versio
On 16 March 2014 09:00, Greg Ewing wrote:
> Nick Coghlan wrote:
>>
>> On 16 March 2014 01:40, Guido van Rossum wrote:
>>
>>> This downside of using subclassing as an API should be well known by now
>>> and
>>> widely warned against.
>>
>>
>> I've actually pondered the idea of suggesting we explic
On Sat, Mar 15, 2014 at 2:44 PM, Nikolaus Rath wrote:
> Guido van Rossum writes:
> > This downside of using subclassing as an API should be well known by now
> > and widely warned against.
>
> It wasn't known to me until now. Are these downsides described in some
> more detail somewhere?
>
> So
Nick Coghlan wrote:
On 16 March 2014 01:40, Guido van Rossum wrote:
This downside of using subclassing as an API should be well known by now and
widely warned against.
I've actually pondered the idea of suggesting we explicitly recommend
the "procedural facade around an object oriented imple
Guido van Rossum writes:
> This downside of using subclassing as an API should be well known by now
> and widely warned against.
It wasn't known to me until now. Are these downsides described in some
more detail somewhere?
So far I have always thought that, as long as I avoid using private
attr
Maybe this would be a good subject for a series of blog posts? There is
certainly plenty we have to say based on 20+ years of experience adding
stuff to the stdlib (and not adding it).
On Sat, Mar 15, 2014 at 8:55 AM, Nick Coghlan wrote:
> On 16 March 2014 01:40, Guido van Rossum wrote:
> > On
On 16 March 2014 01:40, Guido van Rossum wrote:
> On Sat, Mar 15, 2014 at 4:02 AM, Giampaolo Rodola'
> wrote:
>
> This downside of using subclassing as an API should be well known by now and
> widely warned against.
I've actually pondered the idea of suggesting we explicitly recommend
the "proce
On Sat, Mar 15, 2014 at 4:02 AM, Giampaolo Rodola' wrote:
>
> On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum wrote:
>
>> I don't think so. asyncio depends on selectors but not vice versa. The
>> selectors module was not part of PEP 3156. It is solid and I don't see any
>> reason why it should g
On 15 March 2014 21:02, Giampaolo Rodola' wrote:
>
> On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum wrote:
>>
>> I don't think so. asyncio depends on selectors but not vice versa. The
>> selectors module was not part of PEP 3156. It is solid and I don't see any
>> reason why it should get a re
2014-03-15 11:02 GMT+00:00 Giampaolo Rodola' :
>
> One part which can be improved is that right now the selectors module
doesn't take advance of e/poll()'s modify() method: instead it just
unregister() and register() the fd every time, which is of course
considerably slower (there's also a TODO in
On Sat, Mar 15, 2014 at 3:17 AM, Guido van Rossum wrote:
> I don't think so. asyncio depends on selectors but not vice versa. The
> selectors module was not part of PEP 3156. It is solid and I don't see any
> reason why it should get a reprieve from the usual strict backwards
> compatibility stan
>
>
> I'm especially curious about tracemalloc, since I know Victor found
> something he wanted to change (add?) to the API just recently.
>
>
I hope that the PEP process found all major design issues. I will try to
avoid as much as posssible to break the backward compatibility. As you
wrote, I may
I don't think so. asyncio depends on selectors but not vice versa. The
selectors module was not part of PEP 3156. It is solid and I don't see any
reason why it should get a reprieve from the usual strict backwards
compatibility standards.
--Guido
On Fri, Mar 14, 2014 at 6:49 PM, Eli Bendersky w
On Fri, Mar 14, 2014 at 4:56 PM, Giampaolo Rodola' wrote:
>
> On Fri, Mar 14, 2014 at 9:25 PM, R. David Murray wrote:
>
>> Not Provisional:
>>
>> selectors
>>
>
> Wouldn't it be wiser to consider this one provisional as well?
>
+1 because of the intimate ties to asyncio
Eli
>
>
>
> --
> Giam
On Mar 14, 2014, at 4:25 PM, R. David Murray wrote:
> I just want to summarize the status of the modules that
> have been added to the stdlib in 3.4 to make sure they
> are all labeled correctly:
>
> Provisional:
>
> asyncio
> pathlib
>
> Not Provisional:
>
> ensurepip
ensurepip is correct.
On Fri, Mar 14, 2014 at 9:25 PM, R. David Murray wrote:
> Not Provisional:
>
> selectors
>
Wouldn't it be wiser to consider this one provisional as well?
--
Giampaolo - http://grodola.blogspot.com
___
Python-Dev mailing list
Python-Dev@python.org
htt
On 03/14/2014 01:25 PM, R. David Murray wrote:
Not Provisional:
enum
This is correct.
--
~Ethan~
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/opt
On Fri, 14 Mar 2014 16:25:56 -0400
"R. David Murray" wrote:
> I just want to summarize the status of the modules that
> have been added to the stdlib in 3.4 to make sure they
> are all labeled correctly:
>
> Provisional:
>
> asyncio
> pathlib
These are right.
Regards
Antoine.
__
19 matches
Mail list logo
