Stefan Krah added the comment:
Sorry, #23349.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
___
Python-bugs-list mailing list
Stefan Krah added the comment:
Fixed for 2.7 in #22668.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
___
Python-bugs-list mailing
Stefan Krah added the comment:
2.7 is the only remaining candidate for the fix. I'm not going to
work on it: somehow seems too risky for 2.7 at this stage.
--
assignee: skrah -
resolution: - fixed
stage: needs patch - resolved
status: open - pending
versions: -Python 3.2
Changes by Antoine Pitrou pit...@free.fr:
--
status: pending - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
___
Python-bugs-list
Martin v. Löwis added the comment:
The last bugfix release of 3.2 will happen shortly after the release of 3.3,
so in a not-too-far future (compared to the age of this issue, which just had
its first birthday yesterday).
So if this issue should really block 3.2 (which I still think it should
Nick Coghlan added the comment:
Despite my earlier comments, I'm now inclined to agree with Martin here -
upgrading to 3.3 fixes so many other problems with memoryview, that's a more
compelling solution.
And, of course, using NumPy instead always remains an option for more robust
buffer API
Nick Coghlan added the comment:
(Not saying this shouldn't be fixed, just saying it's not a disaster if it
isn't)
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
Stefan Krah added the comment:
I agree that for 3.2 this isn't so important given that non-contiguous
arrays have multiple issues there.
Christian, does a fix for 3.2 benefit FreeImage? Don't you run into
other problems with memoryview?
If it helps, I can try to write a patch for 3.2.
Changes by Alexander Belopolsky alexander.belopol...@gmail.com:
--
nosy: +belopolsky
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
___
___
Martin v. Löwis added the comment:
Removing 3.1, since its addition was apparently done by mistake.
Again, I wonder why this is marked release-critical. It's not a regression from
previous versions, is it? Please use release-critical only if not making a
release at a certain point in the
Nick Coghlan added the comment:
Since the next release of 3.2 is the *last* release of 3.2, yet it will remain
supported by distros well beyond that, yes, I think this should block the final
3.2 release.
--
___
Python tracker rep...@bugs.python.org
Martin v. Löwis added the comment:
Since the next release of 3.2 is the *last* release of 3.2, yet it
will remain supported by distros well beyond that, yes, I think this
should block the final 3.2 release.
But the same will be true for any other bug that 3.2 has. If they
don't get fixed
Stefan Krah added the comment:
Removing 3.1, since its addition was apparently done by mistake.
I'm unable to set 2.7 and 3.2 in my browser without also setting
3.1 (using the Shift key to mark multiple fields).
--
___
Python tracker
Christian Heimes added the comment:
Right now major parts of the buffer API are broken for non-trivial buffer
definitions. IMHO a backport of the fix doesn't count as a new feature although
it needs some new internal functions.
I don't quite understand why Nick thinks that ABI compatibility
Nick Coghlan added the comment:
I was musing about backporting *all* the memoryview fixes, including the buffer
lifecycle ones. Antoine and Stefan rightly pointed out that was a bad idea, and
not necessary to address this problem.
So +1 for backporting just this specific fix, with the
Stefan Krah added the comment:
Right now major parts of the buffer API are broken for non-trivial
buffer definitions. IMHO a backport of the fix doesn't count as a new
feature although it needs some new internal functions.
This particular bug fix for PyBuffer_ToContiguous() (which would
Changes by Nick Coghlan ncogh...@gmail.com:
--
title: memorview.to_bytes() and PyBuffer_ToContiguous() incorrect for
non-contiguous arrays - memoryview.to_bytes() and PyBuffer_ToContiguous()
incorrect for non-contiguous arrays
___
Python tracker
Christian Heimes added the comment:
Thanks Stefan and Nick!
I tried to find the off-by-one bug myself but gave up quickly. Stefan's rewrite
is a better approach.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
Stefan Krah added the comment:
Nick, are you talking about a complete backport or just about pulling
in all functions needed by PyBuffer_ToContiguous()?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue12834
Nick Coghlan added the comment:
I suspect the need to preserve the C ABI would make a complete backport a
challenge. I'm still tempted though, mainly to give third parties a robust core
implementation of the buffer API to test against.
This is especially so with Python 2.7 still having a
Antoine Pitrou added the comment:
This is especially so with Python 2.7 still having a couple of years
of full maintenance left - that's a long time to leave it with a known
broken memoryview implementation. I'm less worried about 3.2, since
the upgrade path to 3.3 is easier in that case,
21 matches
Mail list logo
