Re: Proposal to remove Python 2 support

[Andrew Burgess <andrew.burgess@embecosm.com>]

* 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