Re: freshly-cut python patches

[Thiago Jung Bauermann <bauerman at br dot ibm dot com>]

El mar, 14-10-2008 a las 13:45 -0600, Tom Tromey escribiÃ:
> Thiago> I saw some fixes from you on that code, not sure if it was
> Thiago> related to pretty-printing or not.
> 
> I've tried to be careful about making separate commits, but I think
> there is a case or two where I didn't.  Sorry about that.

Nothing to be sorry about, it was easy to work with the commits you
made. I was just pointing out what I saw while working with them.

> Thiago> - I'm not sure yet how to organize the pretty-printing work. A few
> Thiago> commits are floating around in isolation as a result of this. Initially,
> Thiago> I was thinking of having two patches: a "ground work and CLI pretty
> Thiago> printing" patch and an "MI pretty printing" patch, but it would take
> Thiago> some effort to make the division. Besides, you and Vladimir will
> Thiago> probably have to agree anyway before submitting any of the patches, so
> Thiago> there seems to be no benefit in the separation and I'm thinking of
> Thiago> making only one pretty printing patch. WDYT?
> 
> Yes, I think one patch is what we should do.  The MI and CLI cases are
> tied together now -- they share a good amount of code.
> 
> The pretty-printing code isn't really ready yet, though.  I am still
> working on the MI bits.  Also, I think we might want to change the
> auto-loading stuff a little.

Ok. I'll merge all the pretty-printing-related patches and commits in
the near future. For the auto-loading bits, I suggest keeping them
separate since they have a good chance of being discussed for some time
when submitted, and the pretty-printing part could be committed earlier.

> I think a good candidate for the next patch would be more additions to
> Value.  On the branch I added a couple methods, and these are needed
> to write decent pretty-printers.  I can submit this one if you would
> prefer.

Either way is fine by me.

> There are a few other things that are a bit less intertwined that we
> could clean up and submit after that.  Specifically I'm thinking of
> convenience functions, commands, and parameters.

Ok. Convenience functions in particular is a good one, because Rob
Quill's scope checking patch (which didn't go in yet) could use it. The
others are good candidates too.
-- 
[]'s
Thiago Jung Bauermann
IBM Linux Technology Center