Worarrounding hardcoded Option class in optparse in Python 2.3

[Pupeno]

Hello,
I am doing some extreme use of optparse, that is, extending it as explained
on

http://docs.python.org/lib/optparse-other-reasons-to-extend-optparse.html

I have subclassed OptionParser and Option. MyOptionParser uses MyOption as
option_class and in Python 2.4 it works. But I have to target Python 2.3.
In Python 2.3 the help and version options seem to be created before even a
parser is created and they are created using a hardcoded call to Option.
So, they are not using MyOption. I am creating MyOption specifically for
the help and version Option so I need the to be MyOption.
I check out the documentation of this module for Python 2.3 and it
recommends the same procedure:

http://www.python.org/doc/2.3/lib/optparse-extending-other-reasons.html

Is this a bug in Python 2.3 that was solved in 2.4 and nobody cared to
backport ?
At any rate, what are my options (no pun intended) ?
I could copy and paste the fix[1] from Python 2.4 into MyOptionParser; I
checked it carefull and it seems it would work, but I am not sure, does
anybody know ?
Should I override the hardcoded module variables of optparse in 2.3 ? (that
seems like a bad, bad idea).
I am open to suggestions.
Thanks.
--
Pupeno <pupeno@pupeno. com(http://pupeno.com)

[1] That would be:

def _add_help_optio n(self):
self.add_option ("-h", "--help",
action="help",
help=_("show this help message and exit"))

def _add_version_op tion(self):
self.add_option ("--version",
action="version ",
help=_("show program's version number and exit"))

def _populate_optio n_list(self, option_list, add_help=True):
if self.standard_o ption_list:
self.add_option s(self.standard _option_list)
if option_list:
self.add_option s(option_list)
if self.version:
self._add_versi on_option()
if add_help:
self._add_help_ option()

[Pupeno]

Re: Worarrounding hardcoded Option class in optparse in Python 2.3

For the record, the copy and paste fix seems to have worked, so far.

Pupeno wrote:

Hello,
I am doing some extreme use of optparse, that is, extending it as
explained on

http://docs.python.org/lib/optparse-other-reasons-to-extend-optparse.html

I have subclassed OptionParser and Option. MyOptionParser uses MyOption as
option_class and in Python 2.4 it works. But I have to target Python 2.3.
In Python 2.3 the help and version options seem to be created before even
a parser is created and they are created using a hardcoded call to Option.
So, they are not using MyOption. I am creating MyOption specifically for
the help and version Option so I need the to be MyOption.
I check out the documentation of this module for Python 2.3 and it
recommends the same procedure:

http://www.python.org/doc/2.3/lib/optparse-extending-other-reasons.html

Is this a bug in Python 2.3 that was solved in 2.4 and nobody cared to
backport ?
At any rate, what are my options (no pun intended) ?
I could copy and paste the fix[1] from Python 2.4 into MyOptionParser; I
checked it carefull and it seems it would work, but I am not sure, does
anybody know ?
Should I override the hardcoded module variables of optparse in 2.3 ?
(that seems like a bad, bad idea).
I am open to suggestions.
Thanks.

--
Pupeno <pupeno@pupeno. com(http://pupeno.com)