Re: RFC: add ability to "source" Python code

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli> To clarify, I think "source" without Python compiled should behave
Eli> exactly as it did before this patch: treat foo.py as any other file
Eli> name and treat -p as it does today (i.e. source "-p foo.gdb" if it
Eli> exists).

Eli> Yes, this is called "backward compatibility".  It just could be that
Eli> one reason why someone configures GDB without Python is that they
Eli> don't want this incompatible change.

I find this difficult to swallow.  This argument is that someone out
there finds the need to source a file named "-p something" so
compelling that he disables Python support rather than simply writing
"source ./-p something".

My view, instead, is that users generally do not use files with weird
names, or put gdb scripts into files with extensions clearly used by
other languages, or do other odd things like that.  And, if they do,
they will not mind renaming these files after a major release of GDB.

Major releases are when we can break some things in order to make GDB
better overall.  I do not think we should be constrained by scenarios
like this one, scenarios which, IMNSHO, have never once happened in
real life.

The reason I made the "source" command work the way I did is that it
is a familiar pattern to Unix users: you provide an option to get an
effect, and if the tool cannot provide that effect, you get an error.

Tom