homepage

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).

Definitely don't bring buffer() back in 3.0! It needs to die.
If 2to3 can do this reasonably well, let's do that.

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.

The memoryview implementation is still unfinished (in py3k), so I
suggest we drop the warning or comment it out.

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.

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.

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.

> 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?

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.

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.

In r65584 I changed the warning to not mention memoryview(); it just
says that buffer() does not exist in 3.0.