Antoine Pitrou pit...@free.fr added the comment:
Patch committed in r84394 (py3k) and r84396 (3.1). Thank you Stefan!
--
resolution: - fixed
stage: needs patch - committed/rejected
status: open - closed
versions: -Python 2.7
___
Python tracker
Changes by Antoine Pitrou pit...@free.fr:
--
nosy: +haypo
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7415
___
___
Python-bugs-list mailing list
Stefan Behnel sco...@users.sourceforge.net added the comment:
Here's a patch against the latest py3k. The following will call the new code,
for example:
str(memoryview(b'abc'), 'ASCII')
whereas bytes and bytesarray continue to use their own special casing code
(which has also changed a bit
Antoine Pitrou pit...@free.fr added the comment:
I think the bytearray special-casing should be removed. Otherwise one can
reallocate the buffer in another thread while it is being used for decoding.
--
nosy: +pitrou
versions: -Python 2.7
___
Stefan Behnel sco...@users.sourceforge.net added the comment:
Doesn't the GIL protect the bytearray buffer? Or does decoding free the GIL?
--
versions: +Python 2.7
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7415
Stefan Behnel sco...@users.sourceforge.net added the comment:
Regardless of the answer, I think Antoine is right, special cases aren't
special enough to break the rules, and this is a special case that's more
safely handled as part of the normal buffer case.
Updated patch uploaded.
Antoine Pitrou pit...@free.fr added the comment:
Doesn't the GIL protect the bytearray buffer? Or does decoding free the GIL?
Well, decoding can call arbitrary Python code and therefore, yes,
release the GIL.
Ironically, PyUnicode_Decode() itself (called from
PyUnicode_FromEncodedObject())
Stefan Behnel sco...@users.sourceforge.net added the comment:
... and another complete patch that refactors the complete function to make it
clearer what happens. Includes a small code duplication for the bytes object
case, which I think it acceptable.
--
Added file:
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file:
http://bugs.python.org/file18588/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue7415
Stefan Behnel sco...@users.sourceforge.net added the comment:
Another updated patch with a readability fix (replacing the last one).
--
Added file:
http://bugs.python.org/file18589/unicodeobject-PyUnicode_FromEncodedObject-buffer-refactored.patch
Marc-Andre Lemburg m...@egenix.com added the comment:
Stefan Behnel wrote:
Stefan Behnel sco...@users.sourceforge.net added the comment:
Another updated patch with a readability fix (replacing the last one).
While you're at it, you might as well remove references to the
char buffer -
Stefan Behnel sco...@users.sourceforge.net added the comment:
When I read the comments and exception texts in the function, it didn't occur
to me that char buffer could have been used as a name for the old Py2 buffer
interface. From the context, it totally makes sense to me that the function
Mark Lawrence breamore...@yahoo.co.uk added the comment:
@Stefan can you provide a patch for this?
--
nosy: +BreamoreBoy
stage: - needs patch
versions: +Python 2.7 -Python 3.0
___
Python tracker rep...@bugs.python.org
New submission from Stefan Behnel sco...@users.sourceforge.net:
PyUnicode_FromEncodedObject() currently calls PyObject_AsCharBuffer() to
get the buffer pointer and length of a buffer supporting object. It
should be changed to support the buffer protocol correctly instead.
I filed this as a
14 matches
Mail list logo
