Re: [Bug-gnubg] Python Support

[Jim Segrave]

On Thu 05 Aug 2004 (23:46 +0200), amarganth wrote:
> Hi Jim
> 
> Thanks for the answer. I don't know how to answer into the mailing list of
> gnubg with the same subject "Python Support". So I answer directly to you.
> Sorry 'bout.

Just hit reply to all (or that works for me). The other way is to change the
reply address to address@hidden
 
> Yes, the redirection of the output doesn't work. 
 
> Sorry, but I don't program in C. So I cannot implement the desired function.
> 
> The gnubg.hint() in Python would be absolutely perfect! Not only for my
> planned bot. But who is willing to program that?

I've started learning Python, because I have a lot of ideas on using
the scripting and want to add things to the database. I've been short
on spare time for the last long time (and have been using a lot of
whatever spare time I have playing on-line, which is what got me
involved in gnubg in the first place), but if no-one else picks this
up, I am likely to have a go at it. I want a generic Python interface
to evaluations because I'd like to extend the database with the option
of keeping game records and moves (allow the user to keep moves within
games which meet some criterion, usually because they were flagged as
errors). I think some people would be very happy if they could, along
with commiting a match to a database, could also record all their (and
optionally their opponent's) moves where the EMG equity loss was
greater than some threshold or where the MWC loss was greater than
some threshold, to allow later study. In particular, if the database
had some fixed types which the user could easily assign and provision
for a comment field, then you could take an analysed match, mark some
of your blunders as to type - 'holding game', 'breaking anchor'
whatever is meaningful to the user. Then you'd be able to pull all the
mistakes of a particular type which you've made and get gnubg to bring
up the situation where it happened for further study.


> The easiest way for all the output of the gnubg.command() is to store it in
> a simple variable (s = gnubg.command("something")). A parsing after getting
> the output isn't as nice as this gnubg.hint(). But it would be a solution
> for all the possible commands. But I think I understand, that it's not as
> easy as it looks like.

I'm not opposed to this, but there are some considerations:

This is doable for non-GUI, but becomes very difficult if you invoke
Python functions on a GUI version, since there's no concept of stdout
and information is presented to the user in lots of different ways -
entries in text widgets for example.

It also makes automatic parsing difficult for the Python programmer,
since the parser has to account for changes in output text either as a
reult of gnubg evolving or simply dealing with the problem of text
being in different languages. I think keeping Python scripts tracking
the current language files would be unlikely to be manageable.


-- 
Jim Segrave           address@hidden