Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

By digging into the internals of a subprocess produced by Popen(), you can write in a blocking manner to the stdin pipe, and read in a blocking manner from the stdout/stderr pipe(s). For scripting most command-line operations, the lack of timeouts and the ability to *stop* trying to read is as impo

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

On 3/27/2014 9:16 PM, Josiah Carlson wrote: You don't understand the point because you don't understand the feature request or PEP. That is probably my fault for not communicating the intent better in the past. The feature request and PEP were written to offer something like the below (or at leas

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 03:10 PM, Greg Ewing wrote: R. David Murray wrote: I've done the 'landmark' thing as well, in the string context; that can be very useful when doing incremental test driven development. (Granted, you could do that with __bytes__; Can't you do it more easily just by wrapping asci

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

R. David Murray wrote: I've done the 'landmark' thing as well, in the string context; that can be very useful when doing incremental test driven development. (Granted, you could do that with __bytes__; Can't you do it more easily just by wrapping ascii() around the argument? That seems suffici

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

You don't understand the point because you don't understand the feature request or PEP. That is probably my fault for not communicating the intent better in the past. The feature request and PEP were written to offer something like the below (or at least enough that the below could be built with mi

Re: [Python-Dev] collections.sortedtree

for our stackless socket framework we have the same issue. Windows provides an opaque timer system where a timer can be cancelled by handle. But on linux one has to craft one's own. One thing with this particular use case is that a heapq is overkill for network timer. . For network timers a g

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

2014-03-27 22:52 GMT+01:00 Josiah Carlson : > * Because it is example docs, maybe a multi-week bikeshedding discussion > about API doesn't need to happen (as long as "read line", "read X bytes", > "read what is available", and "write this data" - all with timeouts - are > shown, people can build ev

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

Hi, 2014-03-27 22:52 GMT+01:00 Josiah Carlson : > ... but I never made an effort to get it practically working > with asyncore - primarily because such would be functionally impossible on > Windows without a lot of work to pull in a chunk of what was pywin32 > libraries (at the time, Windows was a

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, 27 Mar 2014 11:57:35 -0700 Ethan Furman wrote: > On 03/27/2014 11:41 AM, Guido van Rossum wrote: > > Much better, but I'm still not happy with including %s at all. Otherwise > > it's accept-worthy. (How's that for pressure. :-) > > FWIW, I feel the same, but the need for compatible 2/3 c

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, 27 Mar 2014 18:47:59 + Brett Cannon wrote: > On Thu Mar 27 2014 at 2:42:40 PM, Guido van Rossum wrote: > > > Much better, but I'm still not happy with including %s at all. Otherwise > > it's accept-worthy. (How's that for pressure. :-) > > > > But if we only add %b and leave out %s

Re: [Python-Dev] Status of PEP 3145 - Asynchronous I/O for subprocess.popen

Hopping in to give my take on this, which I've expressed to Antoine off-list. When I first built the functionality about 8.5-9 years ago, I personally just wanted to be able to build something that could replace some of Expect: http://expect.sourceforge.net/ . The original and perhaps current API

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Request for Pronouncement

On 03/27/2014 01:44 PM, Guido van Rossum wrote: Accepted. Yay! If you're going to commit another change, may I suggest to add, to the section stating that %r is not supported, that %a is usually a suitable replacement for %r? Done. -- ~Ethan~ _

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 11:41 AM, Guido van Rossum wrote: Much better, but I'm still not happy with including %s at all. Otherwise it's accept-worthy. (How's that for pressure. :-) FWIW, I feel the same, but the need for compatible 2/3 code bases is real. Hey, how's this? We'll let %s in, but immediat

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Request for Pronouncement

Accepted. Congrats with marshalling yet another quite contentious discussion, and putting up with my last-minute block-headedness! If you're going to commit another change, may I suggest to add, to the section stating that %r is not supported, that %a is usually a suitable replacement for %r? On

[Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Request for Pronouncement

Requesting pronouncement on PEP 461. Full text below. === PEP: 461 Title: Adding % formatting to bytes and bytearray Version: $Revision$ Last-Modified: $Date$ Author: Ethan Furman Status: Draft Type: Standards Track Con

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

I love it! On Thu, Mar 27, 2014 at 12:11 PM, Ethan Furman wrote: > On 03/27/2014 11:59 AM, Guido van Rossum wrote: > >> >> PS. I am not trying to be difficult. I honestly don't understand the use >> case yet, and the PEP doesn't do much to >> support it. >> > > How's this? > ---

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 11:59 AM, Guido van Rossum wrote: PS. I am not trying to be difficult. I honestly don't understand the use case yet, and the PEP doesn't do much to support it. How's this? Compatibility with Python 2 ==

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 11:53 AM, Guido van Rossum wrote: So what's the use case for Python 2/3 compatible code? IMO the main use case for the PEP is simply to be able to construct bytes from a combination of a template and some input that may include further bytes and numbers. E.g. in asyncio when you

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, Mar 27, 2014 at 2:53 PM, Guido van Rossum wrote: > So what's the use case for Python 2/3 compatible code? IMO the main use case > for the PEP is simply to be able to construct bytes from a combination of a > template and some input that may include further bytes and numbers. E.g. in > asyn

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 3/27/2014 11:59 AM, Guido van Rossum wrote: On Thu, Mar 27, 2014 at 11:52 AM, Daniel Holth > wrote: I feel not including %s is nuts. Should I write .replace('%b', '%s')? I assume you meant .replace('%s', '%b') (unless you're converting Python 3 code to Python 2

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, Mar 27, 2014 at 11:34 AM, Ethan Furman wrote: > On 03/27/2014 11:24 AM, Guido van Rossum wrote: > >> On Thu, Mar 27, 2014 at 10:55 AM, Ethan Furman wrote: >> >>> >>> The biggest reason to use %s is to support a common code base for 2/3 >>> endeavors. >>> >> >> But it's mostly useless for

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, Mar 27, 2014 at 11:52 AM, Daniel Holth wrote: > I feel not including %s is nuts. Should I write .replace('%b', '%s')? > I assume you meant .replace('%s', '%b') (unless you're converting Python 3 code to Python 2, which would mean you really are nuts :-). But that's not going to help for

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 11:24 AM, Guido van Rossum wrote: On Thu, Mar 27, 2014 at 10:55 AM, Ethan Furman wrote: The biggest reason to use %s is to support a common code base for 2/3 endeavors. But it's mostly useless for that purpose. In Python 2, in practice %s doesn't mean "string". [...] In Pytho

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

So what's the use case for Python 2/3 compatible code? IMO the main use case for the PEP is simply to be able to construct bytes from a combination of a template and some input that may include further bytes and numbers. E.g. in asyncio when you write an HTTP client or server you have to construct

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

I feel not including %s is nuts. Should I write .replace('%b', '%s')? All I desperately need are APIs that provide enough unicode / str type safety that I get an exception when mixing them accidentally... in my own code, dynamic typing is usually a bug. As has been endlessly discussed, %s for bytes

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu Mar 27 2014 at 2:42:40 PM, Guido van Rossum wrote: > Much better, but I'm still not happy with including %s at all. Otherwise > it's accept-worthy. (How's that for pressure. :-) > But if we only add %b and leave out %s then how is this going to lead to Python 2/3 compatible code since %b

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

Much better, but I'm still not happy with including %s at all. Otherwise it's accept-worthy. (How's that for pressure. :-) On Thu, Mar 27, 2014 at 11:04 AM, Ethan Furman wrote: > On 03/27/2014 10:55 AM, Ethan Furman wrote: > >> On 03/27/2014 10:29 AM, Guido van Rossum wrote: >> >>> >>> I also d

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 10:55 AM, Ethan Furman wrote: On 03/27/2014 10:29 AM, Guido van Rossum wrote: I also don't understand why we can't use %b instead of %s. AFAIK %b currently doesn't mean anything and I somehow don't expect we're likely to add it for other reasons (unless there's a proposal I'm mi

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, Mar 27, 2014 at 10:55 AM, Ethan Furman wrote: > On 03/27/2014 10:29 AM, Guido van Rossum wrote: > >> >> I also don't understand why we can't use %b instead of %s. AFAIK %b >> currently doesn't mean anything and I somehow don't >> expect we're likely to add it for other reasons (unless the

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 10:29 AM, Guido van Rossum wrote: I also don't understand why we can't use %b instead of %s. AFAIK %b currently doesn't mean anything and I somehow don't expect we're likely to add it for other reasons (unless there's a proposal I'm missing?). Just like we use %a instead of %r to

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

Wow. I'm pretty consistent. I still like that. :-) On Thu, Mar 27, 2014 at 10:31 AM, MRAB wrote: > On 2014-03-27 15:58, Ethan Furman wrote: > >> On 03/27/2014 04:42 AM, Nick Coghlan wrote: >> >>> >>> I also seem to recall Guido saying he liked it [%a], which flipped the >>> discussion from "do

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 2014-03-27 15:58, Ethan Furman wrote: On 03/27/2014 04:42 AM, Nick Coghlan wrote: I also seem to recall Guido saying he liked it [%a], which flipped the discussion from "do we have a good rationale for including it?" to "do we have a good rationale for the BDFL to ignore his instincts?". How

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

I also don't understand why we can't use %b instead of %s. AFAIK %b currently doesn't mean anything and I somehow don't expect we're likely to add it for other reasons (unless there's a proposal I'm missing?). Just like we use %a instead of %r to remind people that it's not quite the same (since it

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

Actually, I had ignored this discussion for so long that I was surprised by the outcome. My main use case isn't printing a number that may already be a string (I understand why that isn't reasonable when the output is expected to be bytes); it's printing a usually numeric value that may sometimes b

Re: [Python-Dev] multiprocessing BaseManager's "serializer" argument

On Thu, Mar 27, 2014 at 8:42 PM, Brett Cannon wrote: > Creating the bug is the best bet as then the reason can be discussed > there. If there are no objections then you can create a patch to make sure > it's tested and documented. Created http://bugs.python.org/issue21078 -- Kind regards, Yu

Re: [Python-Dev] cpython: asyncio.tests: Autodiscover asyncio tests. Patch by Vajrasky Kok. Closes #20668

On Thu, 27 Mar 2014 17:22:01 +0100 (CET) yury.selivanov wrote: > http://hg.python.org/cpython/rev/bcc77493249c > changeset: 89995:bcc77493249c > user:Yury Selivanov > date:Thu Mar 27 12:21:20 2014 -0400 > summary: > asyncio.tests: Autodiscover asyncio tests. Patch by Vajrasky

[Python-Dev] multiprocessing BaseManager's "serializer" argument

Creating the bug is the best bet as then the reason can be discussed there. If there are no objections then you can create a patch to make sure it's tested and documented. On Thu Mar 27 2014 at 12:20:00 PM, Yuriy Taraday wrote: > Hello. > > Is there any reason BaseManager's "serializer" argument

Re: [Python-Dev] cpython: inspect.Signature: Add 'Signature.from_callable' classmethod. Closes #17373

On Thu, 27 Mar 2014 17:12:02 +0100 (CET) yury.selivanov wrote: > > +.. classmethod:: Signature.from_callable(obj) > + > + Return a :class:`Signature` (or its subclass) object for a given > callable > + ``obj``. This method simplifies subclassing of :class:`Signature`: > + > +

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 04:42 AM, Nick Coghlan wrote: I also seem to recall Guido saying he liked it [%a], which flipped the discussion from "do we have a good rationale for including it?" to "do we have a good rationale for the BDFL to ignore his instincts?". However, it would be up to Guido to confirm t

[Python-Dev] multiprocessing BaseManager's "serializer" argument

Hello. Is there any reason BaseManager's "serializer" argument has never been documented? We're going to use BaseManager for simple secure local RPC and for the "secure" part we can't use pickle. Can we hope that argument won't go away? Should I create a bug and provide some patch for the docs to

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 03/27/2014 04:24 AM, Antoine Pitrou wrote: On Tue, 25 Mar 2014 15:37:11 -0700 Ethan Furman wrote: ``%a`` will call ``ascii()`` on the interpolated value. This is intended as a debugging aid, rather than something that should be used in production. Non-ASCII values will be encoded to either

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

BTW, my intention was also to set a precedent for future additions to the list. "We did this before" is a great argument to help smooth the path, without bypassing deliberations altogether. On Mar 27, 2014 2:33 AM, "Nick Coghlan" wrote: > On 27 March 2014 18:02, Stephen J. Turnbull wrote: > > Al

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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 __

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Thu, 27 Mar 2014 12:24:49 +0100, Antoine Pitrou wrote: > On Tue, 25 Mar 2014 15:37:11 -0700 > Ethan Furman wrote: > > > > ``%a`` will call ``ascii()`` on the interpolated value. This is intended > > as a debugging aid, rather than something that should be used in production. > > Non-ASCII va

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 27 March 2014 21:24, Antoine Pitrou wrote: > On Tue, 25 Mar 2014 15:37:11 -0700 > Ethan Furman wrote: >> >> ``%a`` will call ``ascii()`` on the interpolated value. This is intended >> as a debugging aid, rather than something that should be used in production. >> Non-ASCII values will be enco

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On 27 March 2014 20:47, Victor Stinner wrote: > The PEP 461 looks good to me. It's a nice addition to Python 3.5 and > the PEP is well defined. +1 from me as well. One minor request is that I don't think the rationale for rejecting numbers from "%s" is incomplete - IIRC, the problem there is that

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

On Tue, 25 Mar 2014 15:37:11 -0700 Ethan Furman wrote: > > ``%a`` will call ``ascii()`` on the interpolated value. This is intended > as a debugging aid, rather than something that should be used in production. > Non-ASCII values will be encoded to either ``\xnn`` or ``\u`` > representation.

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3

The PEP 461 looks good to me. It's a nice addition to Python 3.5 and the PEP is well defined. I can help to implement it. Maybe, it would be nice to provide an implementation as a third-party party module on PyPI for Python 2.6-3.4. Note: I fixed a typo in your PEP (reST syntax). Victor 2014-03

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

On 27 March 2014 12:11, Eli Bendersky wrote: > On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson > wrote: >> I'm not sure if that's a good thing or not. > > YMMV but IMHO this is a good thing. PEPs provide a single point of reference > to a discussion that would otherwise be spread over multiple

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

On 27 March 2014 18:02, Stephen J. Turnbull wrote: > Alex Gaynor writes: > > > Here's my proposed list of such featuers: > > And suppose that list grows over time? After all, it once was []. > > If we go for a feature-by-feature list, that has two more-or-less > hidden costs. (1) Python-Dev has

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] On the necessity of PEPs [was "collections.sortedtree"]

Eli Bendersky writes: > On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson > wrote: >> I would have said that, too, several years ago, but I think we've >> been requiring (or using anyway) PEPs for a lot more things now. > YMMV but IMHO this is a good thing. FWIW I was just talking to Mat

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] PEP 466 (round 4): Python 2.7 network security enhancements

Alex Gaynor writes: > Here's my proposed list of such featuers: And suppose that list grows over time? After all, it once was []. If we go for a feature-by-feature list, that has two more-or-less hidden costs. (1) Python-Dev has to specify which ones, and either risks a new specification deba