* Re: Proposal to remove Python 2 support
2020-09-16 13:53 ` Andrew Burgess
@ 2020-09-16 15:03 ` Paul Koning
2020-09-16 15:23 ` Joel Brobecker
` (2 subsequent siblings)
3 siblings, 0 replies; 25+ messages in thread
From: Paul Koning @ 2020-09-16 15:03 UTC (permalink / raw)
To: Andrew Burgess; +Cc: Joel Brobecker, fedor_qd, Tom Tromey, gdb
> On Sep 16, 2020, at 9:53 AM, Andrew Burgess <andrew.burgess@embecosm.com> wrote:
>
> * Joel Brobecker <brobecker@adacore.com> [2020-09-16 06:00:13 -0700]:
>
>>> That has no sense for me because Python 2 doesn't disappear from distros.
>>
>> I don't know how long this is going to be True, but "distros" have
>> been shipping Python 3.x for quite a while now, so lack of Python 2
>> support wouldn't prevent you from building GDB with Python support
>> enabled.
>
> But a user might potentially have a significant body of Python 2 code
> that they run through GDB, so it's not as simple as "just" building
> with Python 3 and off they go.
An interesting experiment would be to take some significant Python 2 based GDB scripts and see (a) if they run unchanged with Python 3, (b) if they run correctly if processed through the 2to3 tool.
For many situations it's easy to write a bilingual Python script, and in scripts that don't use "print" statements the differences are often tiny or non-existent.
paul
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 13:53 ` Andrew Burgess
2020-09-16 15:03 ` Paul Koning
@ 2020-09-16 15:23 ` Joel Brobecker
2020-09-16 15:34 ` Andrew Burgess
2020-09-16 15:44 ` Eli Zaretskii
2020-09-16 17:50 ` André Pönitz
2020-09-17 17:03 ` Tom Tromey
3 siblings, 2 replies; 25+ messages in thread
From: Joel Brobecker @ 2020-09-16 15:23 UTC (permalink / raw)
To: Andrew Burgess; +Cc: fedor_qd, Paul Koning, Tom Tromey, gdb
> > I don't know how long this is going to be True, but "distros" have
> > been shipping Python 3.x for quite a while now, so lack of Python 2
> > support wouldn't prevent you from building GDB with Python support
> > enabled.
>
> But a user might potentially have a significant body of Python 2 code
> that they run through GDB, so it's not as simple as "just" building
> with Python 3 and off they go.
That is true, and I understand that. I have been involved in quite
a few transitions from Python 2 to Python 3, and it's been a lot
of work for a number of projects.
That being said, we need to be careful and try to find the right
balance between the users who are still stuck on Python 2, those
who have made the effort to transition in time, and the cost of
keeping Python 2 support for a little longer. If the cost remains
reasonable, then of course, let's help everyone.
Here, what we are talking about, is the fact that keeping Python 2
support would delay the implementation of a feature (or force us
to implement it in a way that's more complex -- something I don't
think Tom is interested in doing).
The question therefore is: Do we wait a little more to see what
entities outside our community decide to do re: Python 2.x support,
at the cost of delaying some features and improvements?
I don't have a strong opinion on this. My feeling is that the end
of Python 2.x is something we have known about for a very long time,
and those still stuck on it have a workaround: They can continue
using older versions of GDB.
> I think once distros start to drop Python 2 then there's a really good
> argument that GDB should drop Python 2 also, but before then we need
> to go in with our eyes open, if the distros still ship Python 2 then
> users might be annoyed if they have to rewrite their scripts.
--
Joel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 15:23 ` Joel Brobecker
@ 2020-09-16 15:34 ` Andrew Burgess
2020-09-17 17:07 ` Tom Tromey
2020-09-16 15:44 ` Eli Zaretskii
1 sibling, 1 reply; 25+ messages in thread
From: Andrew Burgess @ 2020-09-16 15:34 UTC (permalink / raw)
To: Joel Brobecker; +Cc: fedor_qd, Paul Koning, Tom Tromey, gdb
* Joel Brobecker <brobecker@adacore.com> [2020-09-16 08:23:29 -0700]:
> > > I don't know how long this is going to be True, but "distros" have
> > > been shipping Python 3.x for quite a while now, so lack of Python 2
> > > support wouldn't prevent you from building GDB with Python support
> > > enabled.
> >
> > But a user might potentially have a significant body of Python 2 code
> > that they run through GDB, so it's not as simple as "just" building
> > with Python 3 and off they go.
>
> That is true, and I understand that. I have been involved in quite
> a few transitions from Python 2 to Python 3, and it's been a lot
> of work for a number of projects.
>
> That being said, we need to be careful and try to find the right
> balance between the users who are still stuck on Python 2, those
> who have made the effort to transition in time, and the cost of
> keeping Python 2 support for a little longer. If the cost remains
> reasonable, then of course, let's help everyone.
>
> Here, what we are talking about, is the fact that keeping Python 2
> support would delay the implementation of a feature (or force us
> to implement it in a way that's more complex -- something I don't
> think Tom is interested in doing).
Something that I think might be related here, or at least worth
mentioning, is guile support.
Without knowing (a) what the new feature is, or (b) how Tom plans to
implement...
Can the feature be added to guile in the same super clean / clever
way? If not are we taking the position that this feature just
wouldn't be available on guile? Or would we potentially end up
implementing the feature the "other way" anyway?
Additionally there's always the option of supporting a particular
feature only when the user compiles against a particular Python
version. I guess this would depend on how tightly coupled the feature
ends up being to the rest of the GDB/Python code.
Thanks,
Andrew
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 15:34 ` Andrew Burgess
@ 2020-09-17 17:07 ` Tom Tromey
2020-09-17 17:49 ` Joel Brobecker
0 siblings, 1 reply; 25+ messages in thread
From: Tom Tromey @ 2020-09-17 17:07 UTC (permalink / raw)
To: Andrew Burgess; +Cc: Joel Brobecker, Paul Koning, Tom Tromey, gdb
>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
Andrew> Something that I think might be related here, or at least worth
Andrew> mentioning, is guile support.
Andrew> Without knowing (a) what the new feature is, or (b) how Tom plans to
Andrew> implement...
Andrew> Can the feature be added to guile in the same super clean / clever
Andrew> way? If not are we taking the position that this feature just
Andrew> wouldn't be available on guile? Or would we potentially end up
Andrew> implementing the feature the "other way" anyway?
Normally features are added to the Python or Guile layer based on
developer interest. So, they aren't really at parity in general.
I don't really know if Guile has anything that Python is missing. Maybe
something to do with I/O -- I'm not super familiar with it.
But IIRC Guile doesn't have frame filters, unwinder support, or TUI
windows. Maybe more is missing there as well.
I don't know if inferior control can be added to the Guile layer easily,
but I would assume so, because Scheme generally has better support for
continuation-like things than other languages.
Andrew> Additionally there's always the option of supporting a particular
Andrew> feature only when the user compiles against a particular Python
Andrew> version. I guess this would depend on how tightly coupled the feature
Andrew> ends up being to the rest of the GDB/Python code.
I don't really like to do this kind of thing because the user experience
is bad -- gdb might or might not work. Though of course we're already
in that situation since the entire scripting layer is optional.
Tom
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 17:07 ` Tom Tromey
@ 2020-09-17 17:49 ` Joel Brobecker
2020-09-17 18:03 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: Joel Brobecker @ 2020-09-17 17:49 UTC (permalink / raw)
To: Tom Tromey; +Cc: Andrew Burgess, Paul Koning, gdb
> Andrew> Additionally there's always the option of supporting a particular
> Andrew> feature only when the user compiles against a particular Python
> Andrew> version. I guess this would depend on how tightly coupled the feature
> Andrew> ends up being to the rest of the GDB/Python code.
>
> I don't really like to do this kind of thing because the user experience
> is bad -- gdb might or might not work. Though of course we're already
> in that situation since the entire scripting layer is optional.
I agree we should be very careful about that, and keep things clear
for the users. One the one hand, a full on/off switch, with a clear
message "your GDB was configured without Python support" is simple
for users to understand. On the other hand, having the API itself
depend on what version of Python GDB was built with would make things
pretty confusing, in my opinion.
--
Joel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 17:49 ` Joel Brobecker
@ 2020-09-17 18:03 ` Eli Zaretskii
2020-09-17 18:10 ` Jan Kratochvil
2020-09-17 18:16 ` Joel Brobecker
0 siblings, 2 replies; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-17 18:03 UTC (permalink / raw)
To: Joel Brobecker; +Cc: tom, paulkoning, gdb
> Date: Thu, 17 Sep 2020 10:49:40 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Paul Koning <paulkoning@comcast.net>, gdb@sourceware.org
>
> I agree we should be very careful about that, and keep things clear
> for the users. One the one hand, a full on/off switch, with a clear
> message "your GDB was configured without Python support" is simple
> for users to understand. On the other hand, having the API itself
> depend on what version of Python GDB was built with would make things
> pretty confusing, in my opinion.
But that kind of thing is inevitable when one relies on external
libraries for some of our features. For example, suppose that the
source-highlight package learns to highlight sources better -- these
improvements will only available to users if they upgrade their
installed source-highlight library before building GDB. Granted,
these differences are smaller than entire commands or features
missing, but they still do exist, and always will.
So I don't think we should be too worried about this.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 18:03 ` Eli Zaretskii
@ 2020-09-17 18:10 ` Jan Kratochvil
2020-09-17 18:45 ` Eli Zaretskii
2020-09-17 18:16 ` Joel Brobecker
1 sibling, 1 reply; 25+ messages in thread
From: Jan Kratochvil @ 2020-09-17 18:10 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Joel Brobecker, paulkoning, tom, gdb
On Thu, 17 Sep 2020 20:03:02 +0200, Eli Zaretskii wrote:
> But that kind of thing is inevitable when one relies on external
> libraries for some of our features. For example, suppose that the
> source-highlight package learns to highlight sources better -- these
> improvements will only available to users if they upgrade their
> installed source-highlight library before building GDB.
That is different.
There will always be installed only one version of source-highlight package.
With Python there can be (and currently commonly is) installed both Python
2 & 3 and it is sometimes tricky to convince a package to use the other
version than the one it uses by default.
Jan
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 18:10 ` Jan Kratochvil
@ 2020-09-17 18:45 ` Eli Zaretskii
2020-09-18 7:15 ` vincent Dupaquis
0 siblings, 1 reply; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-17 18:45 UTC (permalink / raw)
To: Jan Kratochvil; +Cc: brobecker, paulkoning, tom, gdb
> Date: Thu, 17 Sep 2020 20:10:05 +0200
> From: Jan Kratochvil <jan.kratochvil@redhat.com>
> Cc: Joel Brobecker <brobecker@adacore.com>, paulkoning@comcast.net,
> tom@tromey.com, gdb@sourceware.org
>
> On Thu, 17 Sep 2020 20:03:02 +0200, Eli Zaretskii wrote:
> > But that kind of thing is inevitable when one relies on external
> > libraries for some of our features. For example, suppose that the
> > source-highlight package learns to highlight sources better -- these
> > improvements will only available to users if they upgrade their
> > installed source-highlight library before building GDB.
>
> That is different.
>
> There will always be installed only one version of source-highlight package.
>
> With Python there can be (and currently commonly is) installed both Python
> 2 & 3 and it is sometimes tricky to convince a package to use the other
> version than the one it uses by default.
Sorry, I don't think I understand how what you say is relevant to what
I wrote.
What I tried to convey is that having some features in GDB that only
work if you build GDB with Python 3 is not an acute problem.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 18:45 ` Eli Zaretskii
@ 2020-09-18 7:15 ` vincent Dupaquis
2020-09-18 7:25 ` Eli Zaretskii
0 siblings, 1 reply; 25+ messages in thread
From: vincent Dupaquis @ 2020-09-18 7:15 UTC (permalink / raw)
To: gdb
Some vendors are still delivering gdb with python2 by default, for
instance ARM in their arm-none-eabi delivery
(https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads).
Le 17/09/2020 à 20:45, Eli Zaretskii a écrit :
>> Date: Thu, 17 Sep 2020 20:10:05 +0200
>> From: Jan Kratochvil <jan.kratochvil@redhat.com>
>> Cc: Joel Brobecker <brobecker@adacore.com>, paulkoning@comcast.net,
>> tom@tromey.com, gdb@sourceware.org
>>
>> On Thu, 17 Sep 2020 20:03:02 +0200, Eli Zaretskii wrote:
>>> But that kind of thing is inevitable when one relies on external
>>> libraries for some of our features. For example, suppose that the
>>> source-highlight package learns to highlight sources better -- these
>>> improvements will only available to users if they upgrade their
>>> installed source-highlight library before building GDB.
>> That is different.
>>
>> There will always be installed only one version of source-highlight package.
>>
>> With Python there can be (and currently commonly is) installed both Python
>> 2 & 3 and it is sometimes tricky to convince a package to use the other
>> version than the one it uses by default.
> Sorry, I don't think I understand how what you say is relevant to what
> I wrote.
>
> What I tried to convey is that having some features in GDB that only
> work if you build GDB with Python 3 is not an acute problem.
--
*Vincent Dupaquis*
Software security & Cryptography expert
06 24 58 17 05
/Europarc de Pichaury Bâtiment B8 1330 rue Guillibert de la Lauzière
13290 Aix-en-Provence/
www.trusted-objects.com <http://www.trusted-objects.com>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-18 7:15 ` vincent Dupaquis
@ 2020-09-18 7:25 ` Eli Zaretskii
0 siblings, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-18 7:25 UTC (permalink / raw)
To: vincent Dupaquis; +Cc: gdb
> From: vincent Dupaquis <v.dupaquis@trusted-objects.com>
> Date: Fri, 18 Sep 2020 09:15:35 +0200
>
> Some vendors are still delivering gdb with python2 by default, for
> instance ARM in their arm-none-eabi delivery
> (https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm/downloads).
To clarify, I didn't mean to say that we should decide not to have new
features supported for Python 2. What I wrote was written in response
to an opinion that keeping Python 2 supported might induce some heavy
development and maintenance costs. I then said that we could decide
not to support some of the newer features for Python 2, because doing
that would be better than dropping Python 2 support completely.
FTR, I'm the last person to be happy with dropping Python 2 support: I
have it installed, and I'm building GDB with Python 2. I even
volunteered to be the tester of Python 2.6 usage in GDB, because that
is even older.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-17 18:03 ` Eli Zaretskii
2020-09-17 18:10 ` Jan Kratochvil
@ 2020-09-17 18:16 ` Joel Brobecker
1 sibling, 0 replies; 25+ messages in thread
From: Joel Brobecker @ 2020-09-17 18:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: tom, paulkoning, gdb
> > I agree we should be very careful about that, and keep things clear
> > for the users. One the one hand, a full on/off switch, with a clear
> > message "your GDB was configured without Python support" is simple
> > for users to understand. On the other hand, having the API itself
> > depend on what version of Python GDB was built with would make things
> > pretty confusing, in my opinion.
>
> But that kind of thing is inevitable when one relies on external
> libraries for some of our features. For example, suppose that the
> source-highlight package learns to highlight sources better -- these
> improvements will only available to users if they upgrade their
> installed source-highlight library before building GDB. Granted,
> these differences are smaller than entire commands or features
> missing, but they still do exist, and always will.
>
> So I don't think we should be too worried about this.
I do not agree with this sentiment in general, but this is making me
realize that it's not so easy to categorize things. We can have
guidelines, but each probably deserves to be considered individually.
Taking Tom's feature proposal, however, I feel it would be a mistake
to have it only conditionally based on the version of Python being
used to build GDB.
--
Joel
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 15:23 ` Joel Brobecker
2020-09-16 15:34 ` Andrew Burgess
@ 2020-09-16 15:44 ` Eli Zaretskii
1 sibling, 0 replies; 25+ messages in thread
From: Eli Zaretskii @ 2020-09-16 15:44 UTC (permalink / raw)
To: Joel Brobecker; +Cc: andrew.burgess, paulkoning, tom, gdb
> Date: Wed, 16 Sep 2020 08:23:29 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: Paul Koning <paulkoning@comcast.net>, Tom Tromey <tom@tromey.com>,
> gdb@sourceware.org
>
> Here, what we are talking about, is the fact that keeping Python 2
> support would delay the implementation of a feature (or force us
> to implement it in a way that's more complex -- something I don't
> think Tom is interested in doing).
That shouldn't be a problem: it's perfectly fine to say that some GDB
feature requires Python 3.x. We already have something similar with
Guile, I believe.
> My feeling is that the end of Python 2.x is something we have known
> about for a very long time, and those still stuck on it have a
> workaround: They can continue using older versions of GDB.
That is not always possible, though. One may need a GDB feature that
was introduced in a newer version, but still have good reason to be
"stuck" with old Python versions.
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 13:53 ` Andrew Burgess
2020-09-16 15:03 ` Paul Koning
2020-09-16 15:23 ` Joel Brobecker
@ 2020-09-16 17:50 ` André Pönitz
2020-09-17 17:03 ` Tom Tromey
3 siblings, 0 replies; 25+ messages in thread
From: André Pönitz @ 2020-09-16 17:50 UTC (permalink / raw)
To: Andrew Burgess; +Cc: gdb
On Wed, Sep 16, 2020 at 02:53:12PM +0100, Andrew Burgess wrote:
> * Joel Brobecker <brobecker@adacore.com> [2020-09-16 06:00:13 -0700]:
>
> > > That has no sense for me because Python 2 doesn't disappear from distros.
> >
> > I don't know how long this is going to be True, but "distros" have
> > been shipping Python 3.x for quite a while now, so lack of Python 2
> > support wouldn't prevent you from building GDB with Python support
> > enabled.
>
> But a user might potentially have a significant body of Python 2 code
> that they run through GDB, so it's not as simple as "just" building
> with Python 3 and off they go.
>
> I think once distros start to drop Python 2 then there's a really good
> argument that GDB should drop Python 2 also, but before then we need
> to go in with our eyes open, if the distros still ship Python 2 then
> users might be annoyed if they have to rewrite their scripts.
I am not sure whether this is significant, but I have a data point here:
I have ~13kLOC of Python code to be used with GDB that I currently need
to keep compatible with Python 2 and 3, as this may be used with any GDB.
Dropping Python 2 would certainly make /my/ life simpler.
Regards,
André
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: Proposal to remove Python 2 support
2020-09-16 13:53 ` Andrew Burgess
` (2 preceding siblings ...)
2020-09-16 17:50 ` André Pönitz
@ 2020-09-17 17:03 ` Tom Tromey
3 siblings, 0 replies; 25+ messages in thread
From: Tom Tromey @ 2020-09-17 17:03 UTC (permalink / raw)
To: Andrew Burgess; +Cc: Joel Brobecker, Paul Koning, Tom Tromey, gdb
Andrew> I think once distros start to drop Python 2 then there's a really good
Andrew> argument that GDB should drop Python 2 also, but before then we need
Andrew> to go in with our eyes open, if the distros still ship Python 2 then
Andrew> users might be annoyed if they have to rewrite their scripts.
At least Ubuntu and Fedora ship a gdb that is linked against Python 3.
I didn't check the dates, but Joel said Ubuntu has done this since 18.04
(2.5 years ago).
Tom
^ permalink raw reply [flat|nested] 25+ messages in thread