Re: Some questions/suggestions

Greg Ward writes: 

>> - _match_abbrev and get_prog_name in the OptionParser class.
> 
> For these two, there's no compelling reason either way.  My tendency is
> to make things functions when they don't really need to be methods.
> This is probably a sub-optimal habit -- making things methods means it
> possible for subclasses to override them.

I'd like to add one point: when I see a global function, that seems to fit 
into a class, I start trying to think up why these are so important that 
they're in the module interface. They're not used outside the OptionParser 
class, so I think they should be in there. 

>> - check_builtin, check_choice and _builtin_cvt in the Option class.
> 
> For check_builtin() and check_choice(), there's a good reason to make
> them functions: the code defining the TYPE_CHECKER class attribute can
> refer to them directly, rather than by name.  That makes check_value()
> simpler.  And subclasses don't need to override these -- they can
> override TYPE_CHECKER instead.

Okay. 

>> What to do with options created without a dest that contain characters not 
>> in valid python identifiers?
> 
> Good point!  The current behaviour assumes the programmer knows full
> well what he's doing.  It should probably raise an exception instead,
> but that raises backwards incompatibility issues.  Hmmm.

Maybe I'm naive, but I don't see anyone sane accessing invalid identifiers 
using the __dict__. The '-' to '_' conversion should stay, docutils seems to 
use it. I agree an exception should be raised. 

> Config files.

Okay. 

>> Why doesn't OptionParser subclass from OptionGroup? I can see some problems 
>> with the current implementation, but I view an OptionParser as the root 
>> OptionGroup, not as some separate identity. 
> 
> Good point.  Again, I'd have to look hard and think hard before I could
> answer this one properly. 
> 
> Can you enumerate the problems you see with the current design? 
> 

I'm not sure what you're asking for here. Are you referring to my 'I can see 
some problems with the current implementation'? 

>> If Optik is released separately, I think it would be a good idea 
>> to adopt the same tests and docs as in the standard library. 
> 
> For the tests: absolutely positively.

I haven't got the tests here, but I'll upload them tomorrow. 

> For the docs: I'd have to see what you've done first.  I don't want to
> lose any of the text I wrote for Optik's docs (unless it's crappy text,
> of course), but I'm not convinced all of that text belongs in the Python
> manual.

I made a patch with only the text documentation out of Optik in LaTeX 
available at http://python.org/sf/642236 . I didn't update the docs to 
include the OptionGroup and Values classes, but I wanted to do that later, 
when I understood their purpose/design better. 

>         Greg

Johannes 

> Jesus Saves -- but Moses gets the rebound, he shoots, he SCORES!

P.S.: Could you please not post any more funny taglines. I got the feeling 
half of my schools library was looking at me like I was some fool (which was 
probably true). ;) 


-------------------------------------------------------
This SF.net email is sponsored by: Get the new Palm Tungsten T 
handheld. Power & Color in a compact size! 
http://ads.sourceforge.net/cgi-bin/redirect.pl?palm0002en