vne
On Mon, Mar 31, 2014 at 2:01 PM, Daniel Stutzbach wrote:
> On Fri, Mar 28, 2014 at 6:45 PM, Dan Stromberg wrote:
>>
>> In my testing blist.sorteddict was dead last for random keys, and
>> wasn't last but was still significantly underperforming for sequential
>> keys (outperforming only binary
Guido van Rossum :
> Yeah, so the pyftp fix is to keep track of how many timers were
> cancelled, and if the number exceeds a threshold it just recreates the
> heap, something like
>
> heap = [x for x in heap if not x.cancelled]
> heapify(heap)
I measured my target use case with a simple emulatio
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/29/2014 03:46 AM, Stephen J. Turnbull wrote:
> I really don't think commercial profit as the motive for a request,
> or ability to pay, should be an important reason to *ignore* user
> wants.
We've already got corrosion on the terminals the lea
Tres Seaver writes:
> I'm mostly arguing the FLOSS project
You mean "a (mostly) volunteer-supported" FLOSS project, no?
> should feel free to ignore
Given the above qualification, you can put a period here, as far as
I'm concerned. My question is "what does *Python* *want* to ignore?",
not "
On Fri, Mar 28, 2014 at 5:48 PM, Daniel Stutzbach wrote:
> On Fri, Mar 28, 2014 at 2:54 PM, Marko Rauhamaa wrote:
>>
>> The blist implementation, which I have taken a quick glance at,
>>
>> buys cache locality at the price of block copying; I have no data to
>> decide if the tradeoff is a good on
On 29 March 2014 01:57, Stephen J. Turnbull wrote:
> Another way to put it is, we need a better way to fund support of
> "routine maintenance" (ie, the unfun parts) than negotiating it module
> by module.
Yes, yes we do, and there *are* people working on that (see
https://wiki.python.org/moin/Pyt
Marko Rauhamaa :
> For example, Jython would probably use SortedTree to implement it.
That word just keeps coming out of my keyboard. The Java class is of
course the TreeMap.
Marko
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.
Raymond Hettinger :
> * An AVL balanced tree isn't the only solution or necessarily the best
> solution to the problem. Tree nodes tend to take more space than
> denser structures and they have awful cache locality (these are the
> same reasons that deques use doubly-linked blocks rather than a pl
On Mar 26, 2014, at 1:31 PM, Marko Rauhamaa wrote:
> I have made a full implementation of a balanced tree and would like to
> know what the process is to have it considered for inclusion in Python
> 3.
>
> To summarize, the implementation closely parallels dict() features and
> resides in _coll
On 2014-03-28 16:39, Paul Moore wrote:
On 28 March 2014 16:22, Tres Seaver wrote:
On 03/28/2014 12:18 PM, Tres Seaver wrote:
I'm mostly arguing the FLOSS project should feel free to ignore
high-maintenance-cost commercial concerns until those concerns bring
either blook (funded developer time)
Tres Seaver writes:
> On 03/27/2014 04:11 AM, Stephen J. Turnbull wrote:
>
> > Maybe. That depends on if you care about the convenience of folks
> > who have to get new modules past Corporate Security, but it's easier
> > to get an upgrade of the whole shebang. I don't think it's ever
> >
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 12:18 PM, Tres Seaver wrote:
> I'm mostly arguing the FLOSS project should feel free to ignore
> high-maintenance-cost commercial concerns until those concerns bring
> either blook (funded developer time) or treasure (pooled to pay for
On Fri, Mar 28, 2014 at 09:20:35AM +, Kristján Valur Jónsson wrote:
> I'll be willing to experiment with extending the heapq. methods to take an
> optional "map" argument.
> 'map' would be a dict, mapping objects in the heap to indices. If provided,
> each of the heapq methouds would
> take
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/28/2014 11:57 AM, Stephen J. Turnbull wrote:
> So, let me get this straight: you think that one user should pay Red
> Hat to vet the package for RHEL, and another user should pay to get
> it into Ubuntu, and another user to get it into SuSE? A
On 28 March 2014 16:22, Tres Seaver wrote:
> On 03/28/2014 12:18 PM, Tres Seaver wrote:
>> I'm mostly arguing the FLOSS project should feel free to ignore
>> high-maintenance-cost commercial concerns until those concerns bring
>> either blook (funded developer time) or treasure (pooled to pay for
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/27/2014 04:11 AM, Stephen J. Turnbull wrote:
> Maybe. That depends on if you care about the convenience of folks
> who have to get new modules past Corporate Security, but it's easier
> to get an upgrade of the whole shebang. I don't think it'
> -Original Message-
> From: Python-Dev [mailto:python-dev-
> bounces+kristjan=ccpgames@python.org] On Behalf Of Antoine Pitrou
> Sent: 27. mars 2014 15:53
> To: python-dev@python.org
> Subject: Re: [Python-Dev] collections.sortedtree
>
> On Thu, 27 Mar 2014
Chris Angelico writes:
> Don't forget, of course, that there is a middle ground. Something
> that's really REALLY awesome on PyPI but isn't in the stdlib might be
> packaged by various Linux distros.
Oh, agreed, and any organization that cares that much will already
have the RHEL or Ubuntu LTS
On Fri, Mar 28, 2014 at 3:26 PM, Stephen J. Turnbull wrote:
> This is at least some convenience for *all*
> users, and a near necessity for some strictly controlled environments.
> In the latter, the "gatekeeper" is all too likely to say "PyPI? Bring
> us a CTO signoff that 'this module is essent
Maciej Fijalkowski writes:
> I just find "my company is stupid
I find labeling companies as "stupid", merely because they are
cautious about what external code they allow their developers to
depend on, unacceptable. And I'll go to the trouble of explaining
why.
> so let's work around it by pu
Maciej Fijalkowski writes:
> On Thu, Mar 27, 2014 at 10:11 AM, Stephen J. Turnbull
> wrote:
> > Maybe. That depends on if you care about the convenience of folks who
> > have to get new modules past Corporate Security, but it's easier to
> > get an upgrade of the whole shebang. I don't thi
Nick Coghlan writes:
> On 27 March 2014 18:11, Stephen J. Turnbull wrote:
> > I don't think it's ever really been resolved whether they're a
> > "typical case that won't go away" or a special group whose
> > special needs should be considered.
> That said, getting approval is definitely eas
n-Dev [mailto:python-dev-bounces+kristjan=ccpgames@python.org]
On Behalf Of Guido van Rossum
Sent: 26. mars 2014 21:42
To: Marko Rauhamaa
Cc: Python-Dev
Subject: Re: [Python-Dev] collections.sortedtree
I haven't felt it, heapq feels natural to me for this use case. :-)
I'm aware of the is
On Thu, 27 Mar 2014 08:50:01 -0700
Daniel Stutzbach wrote:
>
> Due to way the heapq is implemented, it can't provide an efficient API for
> removing an arbitrary item. Swapping with the last element allows you to
> efficiently remove the item at a particular index, but you first need to
> find t
Surely you can show empathy and still explain why it's not that easy.
On Mar 27, 2014 2:11 AM, "Maciej Fijalkowski" wrote:
> On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore wrote:
> > On 27 March 2014 08:16, Maciej Fijalkowski wrote:
> >> And random pieces of C included in the standard library can
Thomas Wouters :
> Not to mention discussion about whether it shouldn't just be an existing
> PyPI package, like http://pypi.python.org/pypi/blist, rather than a new
> implementation.
I'm fine with any implementation as long as it is in the standard
library.
Marko
__
On Wed, Mar 26, 2014 at 9:55 PM, Benjamin Peterson wrote:
> On Wed, Mar 26, 2014, at 13:31, Marko Rauhamaa wrote:
> >
> > I have made a full implementation of a balanced tree and would like to
> > know what the process is to have it considered for inclusion in Python
> > 3.
>
> It's not a bad idea
27.03.14 00:16, Guido van Rossum написав(ла):
Yeah, so the pyftp fix is to keep track of how many timers were
cancelled, and if the number exceeds a threshold it just recreates the
heap, something like
heap = [x for x in heap if not x.cancelled]
heapify(heap)
See also http://bugs.python.org/is
On Thu, 27 Mar 2014 09:25:05 +
Kristján Valur Jónsson wrote:
> True.
> I've long since added a heapdel() to our local fork.
> a heappop(idx=0) extension would do the same
> I can provide a patch if there is interest.
I think either of them would be cool. I don't know it would be approved
by R
On Thu, Mar 27, 2014 at 10:10 PM, Nick Coghlan wrote:
> Extending our trust to include a new component isn't to be done
> lightly, but it *does* genuinely save work in the long run for a whole
> lot of other people whenever we choose to do so, and that is the point
> Stephen was making.
Exactly s
On 27 March 2014 20:38, Chris Angelico wrote:
> On Thu, Mar 27, 2014 at 8:58 PM, Nick Coghlan wrote:
>>On 27 March 2014 19:10, Maciej Fijalkowski wrote:
>>> I just find "my company is stupid so let's work around it by putting
>>> stuff to python standard library" unacceptable argument for python
On Thu, Mar 27, 2014 at 8:58 PM, Nick Coghlan wrote:
>On 27 March 2014 19:10, Maciej Fijalkowski wrote:
>> I just find "my company is stupid so let's work around it by putting
>> stuff to python standard library" unacceptable argument for python-dev
>> and all the python community.
>
> Due dilige
On 27 March 2014 19:10, Maciej Fijalkowski wrote:
> On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore wrote:
>> On 27 March 2014 08:16, Maciej Fijalkowski wrote:
>>> And random pieces of C included in the standard library can be
>>> shuffled under the carpet under the disguise of upgrade or what are
On 27 March 2014 18:11, Stephen J. Turnbull wrote:
> Nick Coghlan writes:
>
> > On 27 Mar 2014 07:02, "Guido van Rossum" wrote:
> >> Actually, the first step is publish it on PyPI, the second is to
> >> get a fair number of happy users there. The bar for getting something
> >> included into
True.
I've long since added a heapdel() to our local fork.
a heappop(idx=0) extension would do the same
I can provide a patch if there is interest.
K
Ideally, I think you should be able to replace the cancelled item with
the last item in the heap and then fix the heap in logarithmic time,
but the
On Thu, Mar 27, 2014 at 11:07 AM, Paul Moore wrote:
> On 27 March 2014 08:16, Maciej Fijalkowski wrote:
>> And random pieces of C included in the standard library can be
>> shuffled under the carpet under the disguise of upgrade or what are
>> you suggesting?
>
> The sort of thing that happens is
On 27 March 2014 08:16, Maciej Fijalkowski wrote:
> And random pieces of C included in the standard library can be
> shuffled under the carpet under the disguise of upgrade or what are
> you suggesting?
The sort of thing that happens is that the relevant approvers will
accept python-dev as a "tru
On Thu, Mar 27, 2014 at 10:11 AM, Stephen J. Turnbull
wrote:
> Nick Coghlan writes:
>
> > On 27 Mar 2014 07:02, "Guido van Rossum" wrote:
> >> Actually, the first step is publish it on PyPI, the second is to
> >> get a fair number of happy users there. The bar for getting something
> >> incl
Nick Coghlan writes:
> On 27 Mar 2014 07:02, "Guido van Rossum" wrote:
>> Actually, the first step is publish it on PyPI, the second is to
>> get a fair number of happy users there. The bar for getting something
>> included into the stdlib is pretty high
> The "why not a third party module
Dan Stromberg :
> It'd likely make sense to have either a pure python implementation, or
> pure python and C-extended, so that Pypy and Jython can share the
> feature with CPython.
Jython can build directly on Java's native SortedMap implementation. The
API should not tie it to a tree. Optimizati
On Wed, Mar 26, 2014 at 3:52 PM, Marko Rauhamaa wrote:
> Dan Stromberg :
>
>> It'd likely make sense to have either a pure python implementation, or
>> pure python and C-extended, so that Pypy and Jython can share the
>> feature with CPython.
>
> Jython can build directly on Java's native SortedMa
On Wed, Mar 26, 2014 at 1:55 PM, Benjamin Peterson wrote:
> On Wed, Mar 26, 2014, at 13:31, Marko Rauhamaa wrote:
>>
>> I have made a full implementation of a balanced tree and would like to
>> know what the process is to have it considered for inclusion in Python
>> 3.
>
> It's not a bad idea. (I
On Wed, 26 Mar 2014 18:14:19 -0400
Ben Darnell wrote:
> > >
> > > If the canceled timer lingers in the heapq till its expiry (in 10
> > > minutes), the size is 100 * 10 * 60 = 60,000. The CPU has to wake up
> > > constantly to clear the expired timers.
> >
> > Ideally, I think you should be able t
Yeah, so the pyftp fix is to keep track of how many timers were cancelled,
and if the number exceeds a threshold it just recreates the heap, something
like
heap = [x for x in heap if not x.cancelled]
heapify(heap)
On Wed, Mar 26, 2014 at 3:02 PM, Antoine Pitrou wrote:
> On Wed, 26 Mar 2014 23:
On Wed, Mar 26, 2014 at 6:02 PM, Antoine Pitrou wrote:
> On Wed, 26 Mar 2014 23:57:27 +0200
> Marko Rauhamaa wrote:
> > Antoine Pitrou :
> >
> > > Marko Rauhamaa wrote:
> > >> In my experience, networking entities typically start a timer at each
> > >> interaction and cancel the pending one. So
On Wed, 26 Mar 2014 23:57:27 +0200
Marko Rauhamaa wrote:
> Antoine Pitrou :
>
> > Marko Rauhamaa wrote:
> >> In my experience, networking entities typically start a timer at each
> >> interaction and cancel the pending one. So you have numerous timers
> >> that virtually never expire. You might
Antoine Pitrou :
> Marko Rauhamaa wrote:
>> In my experience, networking entities typically start a timer at each
>> interaction and cancel the pending one. So you have numerous timers
>> that virtually never expire. You might have 100 interactions per
>> second, each canceling and restarting a 1
Terry Reedy :
> Perhaps the collections doc should mention that there are other
> specializes container types available on PyPI and either list some or
> point to a wiki page listing some. There must be at least 10 that
> could be included in such a list.
There *is* a relatively high threshold of
On Wed, 26 Mar 2014 23:41:42 +0200
Marko Rauhamaa wrote:
> Antoine Pitrou :
>
> > Wouldn't a heapq work as well for those two?
>
> In my experience, networking entities typically start a timer at each
> interaction and cancel the pending one. So you have numerous timers that
> virtually never ex
Antoine Pitrou :
> Wouldn't a heapq work as well for those two?
In my experience, networking entities typically start a timer at each
interaction and cancel the pending one. So you have numerous timers that
virtually never expire. You might have 100 interactions per second, each
canceling and res
On 27 Mar 2014 07:02, "Guido van Rossum" wrote:
>
> Actually, the first step is publish it on PyPI, the second is to get a
fair number of happy users there. The bar for getting something included
into the stdlib is pretty high -- you need to demonstrate that there is a
need *and* that having it as
I haven't felt it, heapq feels natural to me for this use case. :-)
I'm aware of the issue of frequent cancelled timers, but chose to wait and
see rather than preemptively fix it (only so many hours in a day). IIRC
pyftplib has a clever cleanup algorithm that we can easily add if that
usage patter
On 3/26/2014 4:59 PM, Guido van Rossum wrote:
Actually, the first step is publish it on PyPI, the second is to get a
fair number of happy users there. The bar for getting something included
into the stdlib is pretty high -- you need to demonstrate that there is
a need *and* that having it as a 3r
Guido van Rossum :
> Actually, the first step is publish it on PyPI, the second is to get a
> fair number of happy users there. The bar for getting something
> included into the stdlib is pretty high -- you need to demonstrate
> that there is a need *and* that having it as a 3rd party module is a
On Wed, 26 Mar 2014 22:31:56 +0200
Marko Rauhamaa wrote:
>
> The primary objective of having a balanced tree in the standard library
> is to support ordered access in an efficient manner. The typical
> applications would include timers (networking), aging (cache)
Wouldn't a heapq work as well fo
On Mar 26, 2014, at 01:55 PM, Benjamin Peterson wrote:
>It's not a bad idea. (I believe others have proposed an red-black tree.)
>Certainly, it requires a PEP and a few months of bikesheding, though.
Generally, PEPs aren't necessary for simple or relatively uncontroversial
additions to existing m
Actually, the first step is publish it on PyPI, the second is to get a fair
number of happy users there. The bar for getting something included into
the stdlib is pretty high -- you need to demonstrate that there is a need
*and* that having it as a 3rd party module is a problem. And that once it's
On Wed, Mar 26, 2014, at 13:31, Marko Rauhamaa wrote:
>
> I have made a full implementation of a balanced tree and would like to
> know what the process is to have it considered for inclusion in Python
> 3.
It's not a bad idea. (I believe others have proposed an red-black tree.)
Certainly, it req
On 03/26/2014 01:31 PM, Marko Rauhamaa wrote:
I have made a full implementation of a balanced tree and would like to
know what the process is to have it considered for inclusion in Python
3.
Open a ticket on the tracker [1], post your code to that ticket, sign the CLA [2], answer questions, et
I have made a full implementation of a balanced tree and would like to
know what the process is to have it considered for inclusion in Python
3.
To summarize, the implementation closely parallels dict() features and
resides in _collectionsmodule.c under the name collections.sortedtree.
It uses so
60 matches
Mail list logo
