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

[Joel Brobecker <brobecker@adacore.com>]

> Eli> I'm okay with this, but I think Tom had some valid reasons for
> Eli> having Python scripts that don't have a certain extension.
> 
> It is a convenience when using scratch files.
> In practice I don't use -p much.  I don't mind removing it.

Ok, we can try without, and see if we get any request?

> I considered this early on and rejected it, because "source" is
> clearer and "felt natural".

Yeah ... I would have to agree with that.

So, where do you think we should go from now?
a tri-state setting:

  1. Use filename extension and evaluate accordingly.
     Error if the language was not compiled in.

  2, Use filename extension and evaluate accordingly.
     Fallback to GDB scripting if the language was not compiled in.

  3. No filename extension recognition, always treat sourced files
     as GDB scripts.

Would that be acceptable to everyone?

Otherwise, I'd be OK with a two state that just deactivates filename
extension recognition, and implements option (2) above when turned on,
but for some reason this fallback, which causes GDBs of the same version
to behavior differently, feels VERY wrong to me. So I'd like to have
a setting that allows me to provide behavior (1).

-- 
Joel