Re: Some questions/suggestions

On 02 December 2002, [email protected] said:
> I'm working on the LaTeX documentation and unit tests for Optik in the 
> standard library, and although it was quite easy, I still have some 
> questions. 

Wonderful -- thank you!

> I'm not sure why the following functions/variables are not in classes, 
> where they seem to fit naturally:
> - _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.

> - 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.

> - _create_option_mappings in OptionParser

Huh?  that's already a method, and it has to be.  Oh, I see, you're
wondering why it's in OptionContainer and not OptionParser.
Ummm... errr... ahhh... I don't remember.  There might be a good reason,
or there might not.  I'd have to look hard at the code and think hard
about it.

> - share_option_mappings in OptionGroup 

Ditto.

> What to do with options created without a dest that contain characters not 
> in valid python identifiers? In long options, '-' is converted to '_', but 
> that's the only conversion done. When I create an Option class with 
> Option('-%'), the Values.% attribute does get set, but I have to access it 
> through Values.__dict__ to get it (I was surprised that Python allows these 
> identifiers in the __dict__). 

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.

> What are the read_file and read_module methods in the Values class for? I 
> can see what they do, I just couldn't think up a usecase. 

Config files.

> 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?

> And the final question: will Optik be packaged up separately after 
> inclusion in 2.3?

Probably, but I think Optik's life-cycle is winding down: it will
probably stabilize for good somewhere around 1.4.1 (or maaaaybe 1.5).

> Although I've converted the docs to LaTeX and the tests 
> to unittest, I'm not willing to do this again and again for new Optik 
> releases.

I don't blame you!

> 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.

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.

        Greg
-- 
Greg Ward <[email protected]>                         http://www.gerg.ca/
Jesus Saves -- but Moses gets the rebound, he shoots, he SCORES!


-------------------------------------------------------
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