>
>
> 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
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
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
[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
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
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 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
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
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
[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
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
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
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
13 matches
Mail list logo
