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
[Aahz ]
> [I'm nomail -- Cc me if you care whether I see followups]
>
> https://github.com/BonzaiThePenguin/WikiSort/tree/master
>
>WikiSort is a stable bottom-up in-place merge sort based on the work
>described in "Ratio based stable in-place merging", by Pok-Son Kim and
>Arne Kutzner
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
[I'm nomail -- Cc me if you care whether I see followups]
https://github.com/BonzaiThePenguin/WikiSort/tree/master
WikiSort is a stable bottom-up in-place merge sort based on the work
described in "Ratio based stable in-place merging", by Pok-Son Kim and
Arne Kutzner [PDF]. Kim's and Kut
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
13 matches
Mail list logo
