Proposal: Drop GDB support for Python versions < 2.6

Proposal: Drop GDB support for Python versions < 2.6

[Kevin Buettner]

I want to drop support in GDB for Python versions 2.5 and lower.

I've proposed two patches which use facilities that are only present
in Python 2.6 and later.  To be clear, these mechanisms are also
present in Python 2.7 and 3.X.  Python documentation encourages use of
these newer facilities over the older ones.

My patches can be found here:

https://sourceware.org/ml/gdb-patches/2019-02/msg00311.html

https://sourceware.org/ml/gdb-patches/2019-02/msg00314.html

The latter patch provides a detailed rationale for dropping support
for older versions of Python.  Here is a brief summary:

Python 2.6 was first released in Oct, 2008.  Five years later, in Oct,
2013, a final security release was made along with the announcement
that support for Python 2.6 has ended.  That being the case, it seems
reasonable for GDB to end support for all Python versions prior to
Python 2.6.

Going even further, since 2.6 is no longer supported by the Python
community, I'd also be okay with saying that GDB only supports Python
2.7 and Python 3.X.

Comments?

Re: Proposal: Drop GDB support for Python versions < 2.6

[Paul Smith]

On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
> Going even further, since 2.6 is no longer supported by the Python
> community, I'd also be okay with saying that GDB only supports Python
> 2.7 and Python 3.X.

Don't know if anyone cares, but as a heavy user of Python support in
GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
A-OK with me.

Re: Proposal: Drop GDB support for Python versions < 2.6

[Jan Vrany]

On Wed, 2019-02-20 at 16:29 -0500, Paul Smith wrote:
> On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
> > Going even further, since 2.6 is no longer supported by the Python
> > community, I'd also be okay with saying that GDB only supports Python
> > 2.7 and Python 3.X.
> 
> Don't know if anyone cares, but as a heavy user of Python support in
> GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> A-OK with me.

As for myself, as another user of python support, fine with me.

Actually, I'd even be fine with more radical move, dropping support 
for 2.x altogether. Python 2.7 support will end in less a year 
from now anyway. 

Just my two cents. 

Jan

Re: Proposal: Drop GDB support for Python versions < 2.6

[Joel Sherrill]

On Wed, Feb 20, 2019, 3:45 PM Jan Vrany <jan.vrany@fit.cvut.cz wrote:

> On Wed, 2019-02-20 at 16:29 -0500, Paul Smith wrote:
> > On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
> > > Going even further, since 2.6 is no longer supported by the Python
> > > community, I'd also be okay with saying that GDB only supports Python
> > > 2.7 and Python 3.X.
> >
> > Don't know if anyone cares, but as a heavy user of Python support in
> > GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> > A-OK with me.
>
> As for myself, as another user of python support, fine with me.
>
> Actually, I'd even be fine with more radical move, dropping support
> for 2.x altogether. Python 2.7 support will end in less a year
> from now anyway.
>

Python 2.7 is shipping with at least one long-term support distribution.
While it is unlikely that anyone will notice on the native side, I know we
(RTEMS) build recent, hopefully the latest, gdb version cross.

--joel


> Just my two cents.
>
> Jan
>
>

Re: Proposal: Drop GDB support for Python versions < 2.6

[Paul Smith]

On Wed, 2019-02-20 at 21:44 +0000, Jan Vrany wrote:
> Actually, I'd even be fine with more radical move, dropping support 
> for 2.x altogether. Python 2.7 support will end in less a year 
> from now anyway.

I expected someone to say this :).

I'm well aware of the EOL pan for Python 2.7, obviously.  However, I
cannot begin to guess when we'll stop using it internally due to the
massive (and 100% unproductive) overhead involved with transitioning to
Python 3.  We only use Python (and GDB!) internally, and we build it
ourselves we don't use a version that comes with our distribution, so
it doesn't really matter to us how well supported it is externally.

So, I would be unhappy if support for Python 2.7 were dropped. 
However, when it becomes a big burden for GDB devs to support it I
guess we'll have to do something else (build Python 3 just for GDB?)

Again, just speaking as a user, not a GDB developer.

Re: Proposal: Drop GDB support for Python versions < 2.6

[Kevin Buettner]

On Wed, 20 Feb 2019 21:44:39 +0000
Jan Vrany <jan.vrany@fit.cvut.cz> wrote:

> Actually, I'd even be fine with more radical move, dropping support 
> for 2.x altogether. Python 2.7 support will end in less a year 
> from now anyway. 

I'm not ready to drop support for all of 2.X.

Though if we did, we'd be able to remove many of the ifdefs from the
C/C++ files in gdb/python.

Kevin

Re: Proposal: Drop GDB support for Python versions < 2.6

[André Pönitz]

On Wed, Feb 20, 2019 at 03:11:45PM -0700, Kevin Buettner wrote:
> On Wed, 20 Feb 2019 21:44:39 +0000
> Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
> 
> > Actually, I'd even be fine with more radical move, dropping support 
> > for 2.x altogether. Python 2.7 support will end in less a year 
> > from now anyway. 
> 
> I'm not ready to drop support for all of 2.X.

Out of curiosity: Why?

I.e. are there realistic scenarios where people actively use GDB's Python
interface (in this context here I am tempted to call it a fairly "recent"
addition to GDB, the first commit seems to be dated Aug 6, 2008), but are
not able to use it with Python 3.x (3.0 released on Dec 3, also 2008)?

Andre'

Re: Proposal: Drop GDB support for Python versions < 2.6

[Kevin Buettner]

On Thu, 21 Feb 2019 00:28:48 +0100
André Pönitz <apoenitz@t-online.de> wrote:

> On Wed, Feb 20, 2019 at 03:11:45PM -0700, Kevin Buettner wrote:
> > On Wed, 20 Feb 2019 21:44:39 +0000
> > Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
> >   
> > > Actually, I'd even be fine with more radical move, dropping support 
> > > for 2.x altogether. Python 2.7 support will end in less a year 
> > > from now anyway.   
> > 
> > I'm not ready to drop support for all of 2.X.  
> 
> Out of curiosity: Why?
> 
> I.e. are there realistic scenarios where people actively use GDB's Python
> interface (in this context here I am tempted to call it a fairly "recent"
> addition to GDB, the first commit seems to be dated Aug 6, 2008), but are
> not able to use it with Python 3.x (3.0 released on Dec 3, also 2008)?

I think so.  See Eli's reply in this thread.

When I build GDB on Fedora, I get a gdb enabled for python 2.7 unless
I take measures (via --with-python=/usr/bin/python3) to use python 3.X
instead.

I just checked three recent linux distro releases: Mint 19.1, Debian 9.8, and
Fedora 29.  For each of them, running "python --version" shows that they're
all Python 2.7.X.  Python 3 is often available, but you have to use the
python3 command to use it.

Checking my CentOS 7.6 box, I find that Python 2.7.5 is installed, but
Python 3 is not.  However, I see that I could install some version of
Python 3 if I needed it.  (I'm not using this machine for development.)

I think we can drop Python 2.7 (and lower) sometime after the major
Linux distributions start defaulting to python 3.X for the "python"
command.

Kevin

Re: Proposal: Drop GDB support for Python versions < 2.6

[Eli Zaretskii]

> Date: Wed, 20 Feb 2019 23:39:15 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> Cc: André Pönitz <apoenitz@t-online.de>
> 
> I think we can drop Python 2.7 (and lower) sometime after the major
> Linux distributions start defaulting to python 3.X for the "python"
> command.

I'd appreciate if we did that, thanks.

To clarify, dropping 2.x would not be a catastrophe for me.  Just a
nuisance.  But a significant one.  But nuisance.

Re: Proposal: Drop GDB support for Python versions < 2.6

[André Pönitz]

On Wed, Feb 20, 2019 at 11:39:15PM -0700, Kevin Buettner wrote:
> On Thu, 21 Feb 2019 00:28:48 +0100
> André Pönitz <apoenitz@t-online.de> wrote:
> 
> > On Wed, Feb 20, 2019 at 03:11:45PM -0700, Kevin Buettner wrote:
> > > On Wed, 20 Feb 2019 21:44:39 +0000
> > > Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
> > >   
> > > > Actually, I'd even be fine with more radical move, dropping support 
> > > > for 2.x altogether. Python 2.7 support will end in less a year 
> > > > from now anyway.   
> > > 
> > > I'm not ready to drop support for all of 2.X.  
> > 
> > Out of curiosity: Why?
> > 
> > I.e. are there realistic scenarios where people actively use GDB's Python
> > interface (in this context here I am tempted to call it a fairly "recent"
> > addition to GDB, the first commit seems to be dated Aug 6, 2008), but are
> > not able to use it with Python 3.x (3.0 released on Dec 3, also 2008)?
> 
> I think so.  See Eli's reply in this thread.

I saw it after I wrote my mail. 
 
> When I build GDB on Fedora, I get a gdb enabled for python 2.7 unless
> I take measures (via --with-python=/usr/bin/python3) to use python 3.X
> instead.
> 
> I just checked three recent linux distro releases: Mint 19.1, Debian 9.8, and
> Fedora 29.  For each of them, running "python --version" shows that they're
> all Python 2.7.X.  Python 3 is often available, but you have to use the
> python3 command to use it.
> 
> Checking my CentOS 7.6 box, I find that Python 2.7.5 is installed, but
> Python 3 is not.  However, I see that I could install some version of
> Python 3 if I needed it.  (I'm not using this machine for development.)
> 
> I think we can drop Python 2.7 (and lower) sometime after the major
> Linux distributions start defaulting to python 3.X for the "python"
> command.

I am not sure that the name of the python command is a good indicator
for the timimg of the dropping support for Python 2.x:

First, the version of Python used for 'python' is technical, and in a few
cases also practically to the version of Python GDB uses. E.g. on some Ubuntu
machine here I see something like:

    ~ > gdb -batch -ex 'import sys' -ex 'py print(sys.version)'
    3.6.7 (default, Oct 22 2018, 11:32:17)

    ~ > python --version
    2.7.15rc1

    ~ > python3 --version
    3.6.7

Second, there might be reasons for a distribution to never change the name
of the python command, i.e. always keep it at e.g. 'python3', with no
'python' provided even after the distribution drops Python 2.x, so waiting
for a 'python --version' to produe 3.x might as well mean 'never'.

Andre'


    

    
> 
> Kevin
> 

Re: Proposal: Drop GDB support for Python versions < 2.6

[John Baldwin]

On 2/21/19 10:37 AM, André Pönitz wrote:
> On Wed, Feb 20, 2019 at 11:39:15PM -0700, Kevin Buettner wrote:
>> On Thu, 21 Feb 2019 00:28:48 +0100
>> André Pönitz <apoenitz@t-online.de> wrote:
>>
>>> On Wed, Feb 20, 2019 at 03:11:45PM -0700, Kevin Buettner wrote:
>>>> On Wed, 20 Feb 2019 21:44:39 +0000
>>>> Jan Vrany <jan.vrany@fit.cvut.cz> wrote:
>>>>   
>>>>> Actually, I'd even be fine with more radical move, dropping support 
>>>>> for 2.x altogether. Python 2.7 support will end in less a year 
>>>>> from now anyway.   
>>>>
>>>> I'm not ready to drop support for all of 2.X.  
>>>
>>> Out of curiosity: Why?
>>>
>>> I.e. are there realistic scenarios where people actively use GDB's Python
>>> interface (in this context here I am tempted to call it a fairly "recent"
>>> addition to GDB, the first commit seems to be dated Aug 6, 2008), but are
>>> not able to use it with Python 3.x (3.0 released on Dec 3, also 2008)?
>>
>> I think so.  See Eli's reply in this thread.
> 
> I saw it after I wrote my mail. 
>  
>> When I build GDB on Fedora, I get a gdb enabled for python 2.7 unless
>> I take measures (via --with-python=/usr/bin/python3) to use python 3.X
>> instead.
>>
>> I just checked three recent linux distro releases: Mint 19.1, Debian 9.8, and
>> Fedora 29.  For each of them, running "python --version" shows that they're
>> all Python 2.7.X.  Python 3 is often available, but you have to use the
>> python3 command to use it.
>>
>> Checking my CentOS 7.6 box, I find that Python 2.7.5 is installed, but
>> Python 3 is not.  However, I see that I could install some version of
>> Python 3 if I needed it.  (I'm not using this machine for development.)
>>
>> I think we can drop Python 2.7 (and lower) sometime after the major
>> Linux distributions start defaulting to python 3.X for the "python"
>> command.
> 
> I am not sure that the name of the python command is a good indicator
> for the timimg of the dropping support for Python 2.x:
> 
> First, the version of Python used for 'python' is technical, and in a few
> cases also practically to the version of Python GDB uses. E.g. on some Ubuntu
> machine here I see something like:
> 
>     ~ > gdb -batch -ex 'import sys' -ex 'py print(sys.version)'
>     3.6.7 (default, Oct 22 2018, 11:32:17)
> 
>     ~ > python --version
>     2.7.15rc1
> 
>     ~ > python3 --version
>     3.6.7
> 
> Second, there might be reasons for a distribution to never change the name
> of the python command, i.e. always keep it at e.g. 'python3', with no
> 'python' provided even after the distribution drops Python 2.x, so waiting
> for a 'python --version' to produe 3.x might as well mean 'never'.

On the other hand, there is a notion of "what is the default python version
most packages use".  On FreeBSD this is still python 2.7 as well for many
things, though you can request python3 (e.g. for gdb there are 'gdb' and
'gdb-py3' packages where the first (default) one uses 2.7).  I agree that
'python' might stay 2.7 forever due to legacy compat reasons, but I think
the metric of when distributions start preferrring python3 by default for
various other packages isn't a bad metric.

-- 
John Baldwin

                                                                            

Re: Proposal: Drop GDB support for Python versions < 2.6

[Dmitry Samersoff]

Andre,

On 21.02.2019 2:28, André Pönitz wrote:

> I.e. are there realistic scenarios where people actively use GDB's Python
> interface (in this context here I am tempted to call it a fairly "recent"
> addition to GDB, the first commit seems to be dated Aug 6, 2008), but are
> not able to use it with Python 3.x (3.0 released on Dec 3, also 2008)?

Yes.

Lots of embedded staff is still on Python 2.x and maintaining separate
version of Python just for gdb is problematic.

Re: Proposal: Drop GDB support for Python versions < 2.6

[Paul Koning]

> On Feb 20, 2019, at 4:29 PM, Paul Smith <psmith@gnu.org> wrote:
> 
> On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
>> Going even further, since 2.6 is no longer supported by the Python
>> community, I'd also be okay with saying that GDB only supports Python
>> 2.7 and Python 3.X.
> 
> Don't know if anyone cares, but as a heavy user of Python support in
> GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> A-OK with me.

I concur.

Along the same lines, do you want to drop support for <= 3.x for some x?  Python 3 is up to 3.7 now; I'm not sure if it matters much to the code or maintenance burden, but dropping support for some of the older 3.x releases might also make sense.

	paul

Re: Proposal: Drop GDB support for Python versions < 2.6

[Tom Tromey]

>>>>> "Paul" == Paul Koning <paulkoning@comcast.net> writes:

Paul> Along the same lines, do you want to drop support for <= 3.x for
Paul> some x?  Python 3 is up to 3.7 now; I'm not sure if it matters
Paul> much to the code or maintenance burden, but dropping support for
Paul> some of the older 3.x releases might also make sense.

I looked and there aren't any major compatibility hacks to handle
different minor versions of Python 3.  It's all stuff along these lines,
and not many instances:

    #if PY_MAJOR_VERSION == 3 && PY_MINOR_VERSION >= 4
                            const char *prompt)
    #else
                            char *prompt)
    #endif

So while I think it would be fine to drop some of this, there doesn't
seem to be a big benefit to doing so.

Tom

Re: Proposal: Drop GDB support for Python versions < 2.6

[André Pönitz]

On Wed, Feb 20, 2019 at 04:29:35PM -0500, Paul Smith wrote:
> On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
> > Going even further, since 2.6 is no longer supported by the Python
> > community, I'd also be okay with saying that GDB only supports Python
> > 2.7 and Python 3.X.
> 
> Don't know if anyone cares, but as a heavy user of Python support in
> GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> A-OK with me.

As a data point: the Qt Creator IDE which uses GDB's Python interface
extensively when using GDB as backed, dropped support for Python <= 2.6 in
September 2015 and never received a single complaint about it.

Andre'

Re: Proposal: Drop GDB support for Python versions < 2.6

[Joel Brobecker]

> > Going even further, since 2.6 is no longer supported by the Python
> > community, I'd also be okay with saying that GDB only supports Python
> > 2.7 and Python 3.X.
> 
> Don't know if anyone cares, but as a heavy user of Python support in
> GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> A-OK with me.

+1.

As for Python 2.7, let's keep it for a year or two more, before
we completely drop it.

-- 
Joel

Re: Proposal: Drop GDB support for Python versions < 2.6

[Eli Zaretskii]

> Date: Thu, 21 Feb 2019 06:39:04 +0400
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Kevin Buettner <kevinb@redhat.com>, gdb@sourceware.org
> 
> > > Going even further, since 2.6 is no longer supported by the Python
> > > community, I'd also be okay with saying that GDB only supports Python
> > > 2.7 and Python 3.X.
> > 
> > Don't know if anyone cares, but as a heavy user of Python support in
> > GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> > A-OK with me.
> 
> +1.
> 
> As for Python 2.7, let's keep it for a year or two more, before
> we completely drop it.

Dropping 2.6, let alone 2.7, would be a terrible nuisance for me.  So
I'm asking to keep that until they really put a drag on the GDB
development (which doesn't seem to be the case now).

TIA

Re: Proposal: Drop GDB support for Python versions < 2.6

[Kevin Buettner]

On Thu, 21 Feb 2019 05:45:12 +0200
Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Thu, 21 Feb 2019 06:39:04 +0400
> > From: Joel Brobecker <brobecker@adacore.com>
> > Cc: Kevin Buettner <kevinb@redhat.com>, gdb@sourceware.org
> >   
> > > > Going even further, since 2.6 is no longer supported by the Python
> > > > community, I'd also be okay with saying that GDB only supports Python
> > > > 2.7 and Python 3.X.  
> > > 
> > > Don't know if anyone cares, but as a heavy user of Python support in
> > > GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> > > A-OK with me.  
> > 
> > +1.
> > 
> > As for Python 2.7, let's keep it for a year or two more, before
> > we completely drop it.  
> 
> Dropping 2.6, let alone 2.7, would be a terrible nuisance for me.  So
> I'm asking to keep that until they really put a drag on the GDB
> development (which doesn't seem to be the case now).

That's fine.  At the moment, there's no real reason to not continue to
(potentially) support 2.6.  I say "potentially" because for some of us,
figuring out how to test against 2.6 is really hard.  However, if you
continue to do regular builds of upstream gdb using Python 2.6,
it'll get tested.

Kevin

Re: Proposal: Drop GDB support for Python versions < 2.6

[Eli Zaretskii]

> Date: Wed, 20 Feb 2019 23:46:10 -0700
> From: Kevin Buettner <kevinb@redhat.com>
> 
> > Dropping 2.6, let alone 2.7, would be a terrible nuisance for me.  So
> > I'm asking to keep that until they really put a drag on the GDB
> > development (which doesn't seem to be the case now).
> 
> That's fine.  At the moment, there's no real reason to not continue to
> (potentially) support 2.6.  I say "potentially" because for some of us,
> figuring out how to test against 2.6 is really hard.  However, if you
> continue to do regular builds of upstream gdb using Python 2.6,
> it'll get tested.

Yes, I build all the GDB versions with Python 2.6 and at least
debugging Emacs some of the Python support is in constant use, as
.gdbinit that ships with Emacs uses that.

When we add a GDB feature whose support with Python 2.6 will be
problematic, I won't object dropping 2.6.

Thanks.

Re: Proposal: Drop GDB support for Python versions < 2.6

[Mark Wielaard]

On Thu, 2019-02-21 at 06:39 +0400, Joel Brobecker wrote:
> > > Going even further, since 2.6 is no longer supported by the Python
> > > community, I'd also be okay with saying that GDB only supports Python
> > > 2.7 and Python 3.X.
> > 
> > Don't know if anyone cares, but as a heavy user of Python support in
> > GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> > A-OK with me.
> 
> +1.
> 
> As for Python 2.7, let's keep it for a year or two more, before
> we completely drop it.

It is probably a good idea to coordinate on when to drop 2.7 support
and announce it in advance so everybody has enough time to prepare.

2020 seems the agreed upon time to do it:
https://pythonclock.org/
https://python3statement.org/

Since many projects already did drop 2.x support using (and testing)
the gdb python 2.x bindings is already getting somewhat complicated on
modern distros.

Cheers,

Mark

Re: Proposal: Drop GDB support for Python versions < 2.6

[Eli Zaretskii]

> From: Paul Smith <psmith@gnu.org>
> Date: Wed, 20 Feb 2019 16:29:35 -0500
> 
> On Wed, 2019-02-20 at 13:45 -0700, Kevin Buettner wrote:
> > Going even further, since 2.6 is no longer supported by the Python
> > community, I'd also be okay with saying that GDB only supports Python
> > 2.7 and Python 3.X.
> 
> Don't know if anyone cares, but as a heavy user of Python support in
> GDB, I'm fine with this.  As long as GDB still supports Python 2.7 it's
> A-OK with me.

Not with me, though.  I still use Python 2.6.x for reasons unrelated
to GDB, and would like to avoid installing one more version just to
compile GDB.  So please leave Python 2.6 supported if it's reasonably
possible.

Re: Proposal: Drop GDB support for Python versions < 2.6

[Pedro Alves]

If we do this, it'd be good to go over gdb/python/python-internal.h and
remove obsolete workarounds such as:

~~~

/* The second argument to PyObject_GetAttrString was missing the 'const'
   qualifier in Python-2.4.  Hence, we wrap it in a function to avoid errors
   when compiled with -Werror.  */

static inline PyObject *
gdb_PyObject_GetAttrString (PyObject *obj,
                            const char *attr) /* ARI: editCase function */
{
  return PyObject_GetAttrString (obj, (char *) attr);
}

#define PyObject_GetAttrString(obj, attr) gdb_PyObject_GetAttrString (obj, attr)

~~~

/* Python 2.4 doesn't include stdint.h soon enough to get {u,}intptr_t
   needed by pyport.h.  */
/* /usr/include/features.h on linux systems will define _POSIX_C_SOURCE
   if it sees _GNU_SOURCE (which config.h will define).
   pyconfig.h defines _POSIX_C_SOURCE to a different value than
   /usr/include/features.h does causing compilation to fail.
   To work around this, undef _POSIX_C_SOURCE before we include Python.h.

   Same problem with _XOPEN_SOURCE.  */
#undef _POSIX_C_SOURCE
#undef _XOPEN_SOURCE

~~~

etc.

Thanks,
Pedro Alves