Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: John Baldwin <jhb@FreeBSD.org>
To: "André Pönitz" <apoenitz@t-online.de>,
	"Kevin Buettner" <kevinb@redhat.com>
Cc: gdb@sourceware.org
Subject: Re: Proposal: Drop GDB support for Python versions < 2.6
Date: Thu, 21 Feb 2019 18:52:00 -0000	[thread overview]
Message-ID: <473b7a52-de78-d11a-7471-c9a7593fe21c@FreeBSD.org> (raw)
In-Reply-To: <20190221183729.GA2024@klara.mpi.htwm.de>

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

                                                                            


  reply	other threads:[~2019-02-21 18:52 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-20 20:45 Kevin Buettner
2019-02-20 21:30 ` Paul Smith
2019-02-20 21:44   ` Jan Vrany
2019-02-20 21:49     ` Joel Sherrill
2019-02-20 22:05     ` Paul Smith
2019-02-20 22:11     ` Kevin Buettner
2019-02-20 23:26       ` André Pönitz
2019-02-21  6:39         ` Kevin Buettner
2019-02-21 14:40           ` Eli Zaretskii
2019-02-21 18:35           ` André Pönitz
2019-02-21 18:52             ` John Baldwin [this message]
2019-02-21  9:10         ` Dmitry Samersoff
2019-02-20 22:06   ` Paul Koning
2019-02-21 17:11     ` Tom Tromey
2019-02-20 22:58   ` André Pönitz
2019-02-21  2:39   ` Joel Brobecker
2019-02-21  3:46     ` Eli Zaretskii
2019-02-21  6:46       ` Kevin Buettner
2019-02-21 14:42         ` Eli Zaretskii
2019-02-21 10:45     ` Mark Wielaard
2019-02-21  3:40   ` Eli Zaretskii
2019-02-21 17:55 ` Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=473b7a52-de78-d11a-7471-c9a7593fe21c@FreeBSD.org \
    --to=jhb@freebsd.org \
    --cc=apoenitz@t-online.de \
    --cc=gdb@sourceware.org \
    --cc=kevinb@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox