This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: Change buffer/memoryview DeprecationWarning
Type: Stage:
Components: Interpreter Core Versions: Python 2.6
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: brett.cannon Nosy List: barry, brett.cannon, gvanrossum, pitrou
Priority: release blocker Keywords:

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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2022-04-11 14:56:37adminsetnosy: + barry
github: 47756
2008-08-08 04:17:44brett.cannonsetstatus: open -> closed
resolution: fixed
messages: + msg70881
2008-08-07 21:03:40pitrousetmessages: + msg70856
2008-08-06 21:29:11brett.cannonsetassignee: brett.cannon
2008-08-06 21:28:54brett.cannonsetmessages: + msg70805
2008-08-06 20:12:36gvanrossumsetmessages: + msg70802
2008-08-06 20:09:00brett.cannonsetmessages: + msg70801
2008-08-06 19:32:29pitrousetmessages: + msg70797
2008-08-06 19:05:52brett.cannonsetmessages: + msg70794
2008-08-06 09:49:13pitrousetnosy: + pitrou
messages: + msg70778
2008-08-05 22:52:42brett.cannonsetmessages: + msg70767
2008-08-05 19:41:17gvanrossumsetnosy: + gvanrossum
messages: + msg70762
2008-08-05 18:48:10brett.cannoncreate