On 31 May 2002, Steven Lott said:
> The question of <was>Optik</was><is>options</is> having several
> reusable elements pushes my envelope. If it's job is to parse
> command line arguments, how many different reusable elements can
> their really be? Perhaps there are several candidate modules
> here. It seems difficult to justify putting them all into a
> library. The problem doesn't seem complex enough to justify a
> complex solution.
I think I agree with everything you said. There are only two important
classes in Optik: OptionParser and Option. Together with one trivial
support class (OptionValue) and some exception classes, that is the
module -- the unit of reusability, in your terms.
For convenience while developing, I split Optik into three source files
-- optik/option_parser.py, optik/option.py, and optik/errors.py.
There's not that much code; about 1100 lines. And it's all pretty
tightly related -- the OptionParser class is useless without Option, and
vice-versa.
If you just want to use the code, it doesn't much matter if optik (or
OptionParser) is a package with three sub-modules or a single file. If
you just want to read the code, it's probably easier to have a single
file. If you're hacking on it, it's probably easier to split the code
up. I think Optik is now moving into that long, happy phase where it is
mostly read and rarely hacked on, so I think it's time to merge the
three separate source files into one. I very much doubt that it's too
complex for this -- I have worked hard to keep it tightly focussed on
doing one thing well.
Greg
--
Greg Ward - nerd gward@python.net
http://starship.python.net/~gward/
I appoint you ambassador to Fantasy Island!!!
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4