Re: [Python-Dev] C code: %s vs %U

26.03.14 03:43, Ethan Furman написав(ла): %s is a string. %U is unicode? If so, then %s should only be used when it is certain the string in question has no unicode in it? %s is UTF-8 encoded string. ___ Python-Dev mailing list Python-Dev@python.o

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

2014-03-25 23:37 GMT+01:00 Ethan Furman : > ``%a`` will call ``ascii()`` on the interpolated value. I'm not sure that I understood correctly: is the "%a" format supported? The result of ascii() is a Unicode string. Does it mean that ("%a" % obj) should give the same result than ascii(obj).encode('

Re: [Python-Dev] C code: %s vs %U

On Tue, 25 Mar 2014 18:43:30 -0700 Ethan Furman wrote: > %s is a string. > > %U is unicode? What is the context? ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.

Re: [Python-Dev] C code: %s vs %U

On Wed, 26 Mar 2014 11:48:44 +0100 Antoine Pitrou wrote: > On Tue, 25 Mar 2014 18:43:30 -0700 > Ethan Furman wrote: > > %s is a string. > > > > %U is unicode? > > What is the context? Ok, I suppose it's PyUnicode_Format? :-) (I was initially thinking PyArg_ParseTuple, but it doesn't use "%")

Re: [Python-Dev] C code: %s vs %U

2014-03-26 12:02 GMT+01:00 Antoine Pitrou : > Ok, I suppose it's PyUnicode_Format? :-) I don't think that PyUnicode_Format supports %U. For PyUnicode_FromFormatV(), %U expects a Python Unicode object, whereas "%s" expects a ASCII (or latin1?) encoded byte string "const char*". For PyArg_ParseTup

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

Hi, For your information, asyncio.subprocess.Process is limited. It's not possible yet to connect pipes between two processes. Something like "cat | wc -l" where the cat stdin comes from Python. It's possible to enhance the API to implement that, but the timeframe was too short to implement it be

[Python-Dev] PEP 466 (round 5): selected network security enhancements for Python 2.7

Guido and Antoine persuaded me that selective backports would be a better idea for the network security enhancements than the wholesale module backports previously suggested, while Alex and Donald provided the necessary additional details, so here's a revised version of the PEP. Despite making it m

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

Typo I think: As in the Python 3 series, the backported ssl.create_default_context() API is granted a backwards compatibility exemption that permits the protocol, options, cipher and other settings of the created SSL context to be made made what? On Mar 26, 2014, at 8:00 AM, Nick Coghlan wrote:

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

On 26 March 2014 22:05, Donald Stufft wrote: > Typo I think: > > As in the Python 3 series, the backported ssl.create_default_context() API > is granted a backwards compatibility exemption that permits the protocol, > options, cipher and other settings of the created SSL context to be made > > mad

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

On Mar 26, 2014, at 8:00 AM, Nick Coghlan wrote: > Guido and Antoine persuaded me that selective backports would be a > better idea for the network security enhancements than the wholesale > module backports previously suggested, while Alex and Donald provided > the necessary additional details,

Re: [Python-Dev] C code: %s vs %U

[Assuming you are talking about PyUnicode_FromFormatV] > %s is a string. No. %s is a char*; C does not have a "string" type. The string behind the pointer should be UTF-8 encoded; other encodings are tolerated through the "replace" error handler. > %U is unicode? No. This is a PyObject* whose Py

Re: [Python-Dev] C code: %s vs %U

On 03/26/2014 03:48 AM, Antoine Pitrou wrote: On Tue, 25 Mar 2014 18:43:30 -0700 Ethan Furman wrote: %s is a string. %U is unicode? What is the context? A patch I'm adapting has these lines: static PyObject* module_getattr(PyObject *m, PyObject *name) { char *mod_name_str;

Re: [Python-Dev] [RELEASED] Python 3.4.0

Good job men :D 2014-03-17 14:18 GMT-03:00 Alioune Dia : > yeah , asyncio is a great module, congrat for all jobs you are doing > --Ad | Dakar > > > 2014-03-17 18:11 GMT+01:00 Giampaolo Rodola' : > >> The what's new looks truly amazing, with pathlib and asyncio being my >> favourite additions. >

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

On 26 Mar 2014 23:12, "Cory Benfield" wrote: > > Nick, > > On 26 March 2014 12:00, Nick Coghlan wrote: > > As one example, the Python 2 ``ssl`` module does not support the Server > > Name Identification standard. > > Tiny note: SNI is 'Server Name Indication', not 'Identification'. =) Hah, you k

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

On Mar 26, 2014, at 10:00 PM, Nick Coghlan wrote: >Guido and Antoine persuaded me that selective backports would be a >better idea for the network security enhancements than the wholesale >module backports previously suggested, while Alex and Donald provided >the necessary additional details, so h

[Python-Dev] PEP 466 (round 5): selected network security enhancements for Python 2.7

On Wed Mar 26 2014 at 8:02:08 AM, Nick Coghlan wrote: > Guido and Antoine persuaded me that selective backports would be a > better idea for the network security enhancements than the wholesale > module backports previously suggested, while Alex and Donald provided > the necessary additional deta

Re: [Python-Dev] PEP 466: Proposed policy change for handling network security enhancements

On Wed Mar 26 2014 at 2:15:39 AM, Georg Brandl wrote: > Am 26.03.2014 00:06, schrieb Nick Coghlan: > > > > On 26 Mar 2014 08:32, "Georg Brandl" > > wrote: > >> > >> Am 25.03.2014 23:15, schrieb Nick Coghlan: > >> > > >> > On 26 Mar 2014 01:19, "Brett Cannon" >

Re: [Python-Dev] C code: %s vs %U

On 03/26/2014 06:22 AM, � wrote: [Assuming you are talking about PyUnicode_FromFormatV] %s is a string. No. %s is a char*; C does not have a "string" type. The string behind the pointer should be UTF-8 encoded; other encodings are tolerated through the "replace" error handler. %U is unicode?

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

Nick, On 26 March 2014 12:00, Nick Coghlan wrote: > As one example, the Python 2 ``ssl`` module does not support the Server > Name Identification standard. Tiny note: SNI is 'Server Name Indication', not 'Identification'. =) Otherwise, I'm +1 on this as well. ___

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

On 03/26/2014 03:10 AM, Victor Stinner wrote: 2014-03-25 23:37 GMT+01:00 Ethan Furman: ``%a`` will call ``ascii()`` on the interpolated value. I'm not sure that I understood correctly: is the "%a" format supported? The result of ascii() is a Unicode string. Does it mean that ("%a" % obj) shou

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

On Tue, Mar 25, 2014 at 11:37 PM, Ethan Furman wrote: > In particular, ``%s`` will not accept numbers (use a numeric format code > for > that), nor ``str`` (encode it to ``bytes``). > I don't understand this restriction, and there isn't a rationale for it in the PEP (other than "you can already

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

This mostly looks good to me, however I'm not sure I understand the point of this sentence: "Rather, it is intended to send a clear signal to potential corporate contributors that the core development team are willing to accept offers of corporate assistance in putting this policy into effect [...]

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

On 03/26/2014 05:00 AM, Nick Coghlan wrote: The Mac OS X binary installers historically followed the same policy as other POSIX installations and dynamically linked to the Apple provided OpenSSL libraries. However, Apple has now ceased updating these cross-platform libraries, instead requiring t

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

On 03/26/2014 08:14 AM, Thomas Wouters wrote: On Tue, Mar 25, 2014 at 11:37 PM, Ethan Furman wrote: In particular, ``%s`` will not accept numbers (use a numeric format code for that), nor ``str`` (encode it to ``bytes``). I don't understand this restriction, and there isn't a rationale

[Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

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

On 27 Mar 2014 01:28, "Alex Gaynor" wrote: > > This mostly looks good to me, however I'm not sure I understand the point of > this sentence: "Rather, it is intended to send a clear signal to potential > corporate contributors that the core development team are willing to accept > offers of corpora

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

On Wed, Mar 26, 2014, at 14:25, Barry Warsaw wrote: > 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 necessar

Re: [Python-Dev] collections.sortedtree

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

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

On Mar 26, 2014, at 02: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. OrderedDict >had a PEP for example. > >I'm not sure if that's a good thing or not. Hmm, me neither! I guess

Re: [Python-Dev] collections.sortedtree

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

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

On Mar 26, 2014, at 5:30 PM, Barry Warsaw wrote: > On Mar 26, 2014, at 02: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. OrderedDict >> had a PEP for example. >> >> I'm n

Re: [Python-Dev] collections.sortedtree

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

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

2014-03-26 15:35 GMT+01:00 Ethan Furman : > --- > Examples:: > > >>> b'%a' % 3.14 > b'3.14' > > >>> b'%a' % b'abc' > b'abc' This one is wrong: >>> repr(b'abc').encode('ascii', 'backslashreplace') b"b'abc'"

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

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

On Wed, 26 Mar 2014 17:37:40 -0400 Donald Stufft wrote: > > On Mar 26, 2014, at 5:30 PM, Barry Warsaw wrote: > > > On Mar 26, 2014, at 02: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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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:

Re: [Python-Dev] collections.sortedtree

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

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

On 03/26/2014 02:46 PM, Antoine Pitrou wrote: On Wed, 26 Mar 2014 17:37:40 -0400 Donald Stufft wrote: On Mar 26, 2014, at 5:30 PM, Barry Warsaw wrote: I guess if someone *wants* to go through the PEP gauntlet, I won't stop them. It builds character. Is that what it’s called? “character” >:]

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

Re: [Python-Dev] collections.sortedtree

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

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

On 03/26/2014 02:41 PM, Victor Stinner wrote: 2014-03-26 15:35 GMT+01:00 Ethan Furman : --- Examples:: >>> b'%a' % 3.14 b'3.14' >>> b'%a' % b'abc' b'abc' This one is wrong: repr(b'abc').encode('

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

On Wed, Mar 26, 2014 at 2:27 PM, Benjamin Peterson wrote: > > > On Wed, Mar 26, 2014, at 14:25, Barry Warsaw wrote: > > 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 f

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

On 03/26/2014 07:11 PM, 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 centi-