public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: tom@tromey.com, paulkoning@comcast.net, gdb@sourceware.org
Subject: Re: Proposal to remove Python 2 support
Date: Thu, 17 Sep 2020 11:16:26 -0700	[thread overview]
Message-ID: <20200917181626.GM5797@adacore.com> (raw)
In-Reply-To: <83o8m45lih.fsf@gnu.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.

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

  parent reply	other threads:[~2020-09-17 18:16 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-15 20:46 Tom Tromey
2020-09-15 20:58 ` Paul Koning
2020-09-15 22:54   ` Re[2]: " fedor_qd
2020-09-16 13:00     ` Joel Brobecker
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-17 17:07             ` Tom Tromey
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:45                     ` Eli Zaretskii
2020-09-18  7:15                       ` vincent Dupaquis
2020-09-18  7:25                         ` Eli Zaretskii
2020-09-17 18:16                   ` Joel Brobecker [this message]
2020-09-16 15:44           ` Eli Zaretskii
2020-09-16 17:50         ` André Pönitz
2020-09-17 17:03         ` Tom Tromey
2020-09-18 15:59 ` Pedro Alves
2020-09-18 16:39   ` Mikhail.Terekhov
2020-09-18 16:55     ` Tom Tromey
2020-09-18 17:13       ` Mikhail.Terekhov
2020-09-18 17:35         ` Pedro Alves
2020-09-18 19:20       ` Jeffrey Walton

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=20200917181626.GM5797@adacore.com \
    --to=brobecker@adacore.com \
    --cc=eliz@gnu.org \
    --cc=gdb@sourceware.org \
    --cc=paulkoning@comcast.net \
    --cc=tom@tromey.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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).