Re: [Python-Dev] cStringIO vs io.BytesIO

2014-07-16 Thread Antoine Pitrou
Hi, Le 16/07/2014 19:07, dw+python-...@hmmz.org a écrit : Attached is a (rough) patch implementing this, feel free to try it with hg tip. Thanks for your work. Please post any patch to http://bugs.python.org Regards Antoine. ___ Python-Dev mai

Re: [Python-Dev] cStringIO vs io.BytesIO

2014-07-16 Thread Nick Coghlan
On 16 Jul 2014 20:00, wrote: > On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote: > > I believe this problem affects tornado ( https://github.com/tornadoweb/tornado/ > > Do you know if there a workaround? Maybe there is some stdlib part that I'm > > missing, or a module on PyPI? It i

Re: [Python-Dev] cStringIO vs io.BytesIO

2014-07-16 Thread dw+python-dev
It's worth note that a natural extension of this is to do something very similar on the write side: instead of generating a temporary private heap allocation, generate (and freely resize) a private PyBytes object until it is exposed to the user, at which point, _getvalue() returns it, and converts

Re: [Python-Dev] cStringIO vs io.BytesIO

2014-07-16 Thread dw+python-dev
On Thu, Jul 17, 2014 at 03:44:23AM +0600, Mikhail Korobov wrote: > So making code 3.x compatible by ditching cStringIO can cause a serious > performance/memory  regressions. One can change the code to build the data > using BytesIO (without creating bytes objects in the first place), but that is >

[Python-Dev] cStringIO vs io.BytesIO

2014-07-16 Thread Mikhail Korobov
Hi, cStringIO was removed from Python 3. It seems the suggested replacement is io.BytesIO. But there is a problem: cStringIO.StringIO(b'data') didn't copy the data while io.BytesIO(b'data') makes a copy (even if the data is not modified later). This means io.BytesIO is not suited well to cases wh

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 10:10:07 -0700, Devin Jeanpierre wrote: > On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray > wrote: > > IMO, preventing someone from shooting themselves in the foot by modifying > > something they shouldn't modify according to the API is not a Python > > use case ("consentin

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread Devin Jeanpierre
On Wed, Jul 16, 2014 at 6:37 AM, R. David Murray wrote: > IMO, preventing someone from shooting themselves in the foot by modifying > something they shouldn't modify according to the API is not a Python > use case ("consenting adults"). Then why have immutable objects at all? Why do you have to p

[Python-Dev] == on object tests identity in 3.x - uploaded patch v9

2014-07-16 Thread Andreas Maier
Am 16.07.2014 13:40, schrieb Andreas Maier: Am 13.07.2014 22:05, schrieb Akira Li: Nick Coghlan writes: ... There was related issue "Tuple comparisons with NaNs are broken" http://bugs.python.org/issue21873 but it was closed as "not a bug" despite the corresponding behavior is *not documented*

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread dw+python-dev
On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote: > It would be nice to be able to return a frozendict instead of having the > overhead of building a new dict on each call. There already is an in-between available both to Python and C: PyDictProxy_New() / types.MappingProxyType. It

[Python-Dev] == on object tests identity in 3.x - list delegation to members?

2014-07-16 Thread Andreas Maier
Am 13.07.2014 18:23, schrieb Steven D'Aprano: On Sun, Jul 13, 2014 at 05:13:20PM +0200, Andreas Maier wrote: Second, if not by delegation to equality of its elements, how would the equality of sequences defined otherwise? Wow. I'm impressed by the amount of detailed effort you've put into inv

[Python-Dev] == on object tests identity in 3.x - list delegation to members?

2014-07-16 Thread Andreas Maier
Am 13.07.2014 22:05, schrieb Akira Li: Nick Coghlan writes: ... definition of floats and the definition of container invariants like "assert x in [x]") The current approach means that the lack of reflexivity of NaN's stays confined to floats and similar types - it doesn't leak out and infect t

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread Eric Snow
On Wed, Jul 16, 2014 at 7:47 AM, R. David Murray wrote: > After I hit send on my previous message, I thought more about your > example. One of the issues here is that modifying the dict breaks an > invariant of the API. I have a similar situation in the email module, > and I used the same soluti

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 14:04:29 -, dw+python-...@hmmz.org wrote: > On Wed, Jul 16, 2014 at 09:47:59AM -0400, R. David Murray wrote: > > > It would be nice to be able to return a frozendict instead of having the > > overhead of building a new dict on each call. > > There already is an in-between

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 03:27:23 +0100, MRAB wrote: > >>> # Try modifying the pattern object. > ... p.groupindex['JUNK'] = 'foobar' > >>> > >>> # What are the named groups now? > ... p.groupindex > {'first': 1, 'second': 2, 'JUNK': 'foobar'} > >>> > >>> # And the match object? > ... m.groupdict()

Re: [Python-Dev] Another case for frozendict

2014-07-16 Thread R. David Murray
On Wed, 16 Jul 2014 03:27:23 +0100, MRAB wrote: > Here's another use-case. > > Using the 're' module: > > >>> import re > >>> # Make a regex. > ... p = re.compile(r'(?P\w+)\s+(?P\w+)') > >>> > >>> # What are the named groups? > ... p.groupindex > {'first': 1, 'second': 2} > >>> > >>> # Per