Issue 3506: Change buffer/memoryview DeprecationWarning (original) (raw)

Issue3506

Created on 2008-08-05 18:48 by brett.cannon, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (11)
msg70755 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-05 18:48
Right now in 2.6, using buffer() warns that it is going away and to use memoryview(). Unfortunately memoryview() won't be backported to 2.6 in time for release. That means the warning is covering something that is within 2to3's realm. So the warning should be changed to more align with any specific difference between buffer() and memoryview() (or bring buffer() back to 3.0).
msg70762 - (view)	Author: Guido van Rossum (gvanrossum) *	Date: 2008-08-05 19:41
Definitely don't bring buffer() back in 3.0! It needs to die. If 2to3 can do this reasonably well, let's do that.
msg70767 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-05 22:52
On Tue, Aug 5, 2008 at 12:41 PM, Guido van Rossum <report@bugs.python.org> wrote: > > Guido van Rossum <guido@python.org> added the comment: > > Definitely don't bring buffer() back in 3.0! It needs to die. > > If 2to3 can do this reasonably well, let's do that. > There is already a fixer to go from buffer() to memoryview(), but I don't know how compatible the APIs are. That might still require a warning.
msg70778 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2008-08-06 09:49
The memoryview implementation is still unfinished (in py3k), so I suggest we drop the warning or comment it out.
msg70794 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-06 19:05
How unfinished is it, Antoine? So much that it can't be used, or just to the extent it doesn't take the same arguments as buffer()? If it is the latter then the warning should be changed to warn about unsupported arguments.
msg70797 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2008-08-06 19:32
I'm no buffer API/memoryview expert, but at least slicing is not implemented, and there are almost no unit tests. It can probably be used, but given the absence of tests and of actual uses in the stdlib, I'm not sure we can say it is robust and therefore promote it as replacement. Hopefully Travis will be able to enlighten us when he is back.
msg70801 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-06 20:08
On Wed, Aug 6, 2008 at 12:32 PM, Antoine Pitrou <report@bugs.python.org> wrote: > > Antoine Pitrou <pitrou@free.fr> added the comment: > > I'm no buffer API/memoryview expert, but at least slicing is not > implemented, and there are almost no unit tests. It can probably be > used, but given the absence of tests and of actual uses in the stdlib, > I'm not sure we can say it is robust and therefore promote it as > replacement. > Well, if it can't replace buffer() then the warning needs to change to just flat-out state that buffer() is gone and not suggest any replacement. > Hopefully Travis will be able to enlighten us when he is back. > Hopefully.
msg70802 - (view)	Author: Guido van Rossum (gvanrossum) *	Date: 2008-08-06 20:12
> Well, if it can't replace buffer() then the warning needs to change to > just flat-out state that buffer() is gone and not suggest any > replacement. +1. buffer() stinks. memoryview() rules. They don't hvae the same use cases. Is there truly nobody else who understands PEP 3118 well enough?
msg70805 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-06 21:28
On Wed, Aug 6, 2008 at 1:12 PM, Guido van Rossum <report@bugs.python.org> wrote: > > Guido van Rossum <guido@python.org> added the comment: > >> Well, if it can't replace buffer() then the warning needs to change to >> just flat-out state that buffer() is gone and not suggest any >> replacement. > > +1. buffer() stinks. memoryview() rules. They don't hvae the same use > cases. > That settles that then. > Is there truly nobody else who understands PEP 3118 well enough? Not me.
msg70856 - (view)	Author: Antoine Pitrou (pitrou) *	Date: 2008-08-07 21:03
Le mercredi 06 août 2008 à 20:12 +0000, Guido van Rossum a écrit : > +1. buffer() stinks. memoryview() rules. They don't hvae the same use > cases. > > Is there truly nobody else who understands PEP 3118 well enough? PEP 3118 is not very detailed (for example the exact semantics of slicing are not specified: should it return a copy? I suppose not). Also, most advanced uses of the buffer API seem related to numpy and similar packages, which I've never used.
msg70881 - (view)	Author: Brett Cannon (brett.cannon) *	Date: 2008-08-08 04:17
In r65584 I changed the warning to not mention memoryview(); it just says that buffer() does not exist in 3.0.