This is the mail archive of the mailing list for the GCC 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: QMTest and the G++ testsuite

> Minor point: It would help if there's a provision for slightly
> more complex interpreter arrangements, at least "interpreter
> program arg1 arg2" could be "interpreter iarg1 iarg2 ... program
> arg1 arg2".  Maybe it's already there?

Thanks for thinking about this more.

In light of earlier comments about statefulness, what we want to do is
have the interpreter be an arbitrary piece of Python -- one incarnation
of that is to run an external program as you suggest; another is some
more complex machination where you keep track of whatever state you

If we can get happy about QMTest in native environments, we'll move on
to cross environments.

> Is there a document somewhere that describes the preference for
> Python?

There are things that make Python a particularly good choice, in my
opinion, but that's not the real reason it's in use.  The real reason
is that QMTest was developed under a government contract, and that
contract required the use of Python.

A rational reconstruction goes something like this:

- You want a scripting language because you want it to be easy for
  people to write extensions, and you want to be portable.

- Nobody likes Tcl anymore. :-)

- Perl would have been a fine choice too, but (personally) I like
  Python better.  (Let's not start a religious war on this issue;
  it's just a personal preference.)


Mark Mitchell      
CodeSourcery, LLC  

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