RE: MemoryView missing from Python 2.4 and 2.6

["Wiederhake, Tim" <tim.wiederhake@intel.com>]

Hi Joel!

> It looks like the patch is also removing the feature from users of
> Python 2.7.x, though, is it not?

The patch (see https://sourceware.org/ml/gdb-patches/2017-03/msg00039.html)
does not remove any feature.  The patch changes the return type of one function
from "memoryview" to "buffer" for Python 2.7 and below.  Both types support the
"in" keyword, indexed access, length etc. and behave very similar.  Granted,
memoryview has some additional functions that lets the user inspect the stride
and size of the elements in the buffer, but this is a feature we do not use
here anyway.

I chose 2.7 as a parting point because that is how it is  handled in
infpy_read_memory in py-inferior.c.  Personally, I would leave it that way
because with "buffer" exposed with Python 2.7 as well as Python 2.6 and below,
I guess it gets more exposure and testing and won't suffer bit-rot as easily.

The patch is tested with Python 2.7 and Python 3.6.  I cannot test it with
Python 2.6 but that should not be necessary as these two versions already check
both different return types.

Tim

> -----Original Message-----
> From: Joel Brobecker [mailto:brobecker@adacore.com]
> Sent: Tuesday, March 7, 2017 1:21 AM
> To: Jose E. Marchesi <jose.marchesi@oracle.com>
> Cc: Wiederhake, Tim <tim.wiederhake@intel.com>; Yao Qi
> <qiyaoltc@gmail.com>; gdb-patches@sourceware.org
> Subject: Re: MemoryView missing from Python 2.4 and 2.6
> 
> Hello,
> 
> >     Jose, can you confirm that this patch un-breaks GDB linked with
> >     Python 2.6?
> >
> > Yep.  This fixes the build with Python 2.6.6.
> 
> It looks like the patch is also removing the feature from users of Python 2.7.x,
> though, is it not? Given that this is a new feature, this wouldn't be the end of
> the world, especially since we're so close to branching, so we wouldn't want
> that to be a reason to delay the fix too much longer. However, I think our
> configure script defines HAVE_LIBPYTHON2_7, so perhaps we could either
> use that, or explicitly exclude HAVE_LIBPYTHON2_6, HAVE_LIBPYTHON2_5
> and HAVE_LIBPYTHON2_4 instead of only including it for Python 3.x?
> 
> --
> Joel
Intel Deutschland GmbH
Registered Address: Am Campeon 10-12, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de
Managing Directors: Christin Eisenschmid, Christian Lamprechter
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928