This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


> > Add a -p switch to the "source" command that signifies that we're sourcing
> > a python script instead of a GDB script. We drop the part where we're
> > using the filename extension to guess the file language, thus preserving
> > the current behavior.
> 
> Yes.  I would even agree to retaining the language guesswork by
> file-name extension, provided that (a) there's a user option to turn
> that on and off, and (b) that option is off and stays off when Python
> is not compiled in.

OK, I think I see now why we could not agree in the past, and I feel
that it will help in finding an agreeable solution.

> Ideally, it should work as it does today, but if that's too hard to
> implement, how about simply ignoring -p in that case?  That is, let
> "source -p foo" behave like "source foo".

I personally think it's a mistake to have a different behavior
based on how GDB was built, and that causing an error is less confusing.
But I'd be OK with the behavior you propose (no error, just the original
behavior).

Let's see what everyone thinks. I have several issues that I'd like
to discuss before we can finalize a proposal:

  1. If we have filename-extension detection (controlled by a setting),
     do we need the "-p" switch at all? If we agreed that it's an
     acceptable limitation that python scripts in GDB should have
     a .py extension, then we don't really need the .py switch,
     do we?  This in turn would side-step the question of what to do
     with -p when python wasn't compiled in.

  2. Are others OK with interpreting all files as GDB scripts when
     python wasn't compiled in, even files with a .py extension?
     
     Or maybe, how about changing the semantics of that setting
     to apply to files that are detected as python (regardless of
     how the detection is performed): In one case these files are
     sourced as python script, but on the other, these files are
     still treated as GDB scripts. When GDB was built with python,
     then this switch can be used to turn the new feature off,
     whereas if no python was available, the setting would be stuck
     to the value where files are sourced as GDB scripts.

Now that I've written all this and that it has given me a chance
to think this over a little more, I like the idea of falling back
to GDB scripts less and less. So much so that I'm wondering whether
using a different command than "source" might be better? "pysource"
for instance?

-- 
Joel


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]