On 05/08/2010 01:58 PM, Steven D'Aprano wrote:
If your patch doesn't attract the interest of a Python-Dev
developer, you might need to give them a prod occasionally.
Their time for reviewing bugs and patches is always in short
supply.
- where (or to whom) to I submit the patch (and possibly
tests)
Submit the patch and tests to the bug tracker at
http://bugs.python.org/
Okay -- a good first stop, and vastly more helpful than the
non-reply I got regarding my optparse patch.
- any tests needed/expected? run how? internal as an "if
__name__ == '__main__'" block, or an external test suite?
Look at the tests in (e.g.) /usr/local/lib/python2.6/test/ for
an idea of what you should do.
I poked in my Debian analogue (/usr/bin/lib/python2.6/test/) but
the tests there seemed a bit...um...lacking? There was nothing
testing ConfigParser at all, just three high-level test modules.
Granted, I could create some tests that exercise my code, and
perhaps some that should have been there in the first place, but
that's a big jump from merely adding a couple tests (non)existing
ConfigParser tests.
Because this is a new feature, and 2.5 (and 2.6?) are in bug fix only
mode, you should probably aim for 2.7 or 3.2 as the ideal. Patches
written against 2.6 or 3.1 are probably good enough though.
Okay, I've submitted the patch to dev.python.org in the hopes
something comes of it, even if it's 2.7 or 3.2
That's what I thought you meant. Forking is the right term in this case
(you are forking the ConfigParser module, not all of Python), and I still
say it is overkill. Generally speaking, when a module doesn't do what you
want, and modifying it isn't an option, there are five things you can do.
In order of decreasing desirability:
(1) Write a small wrapper function to tweak the behaviour.
(2) Sub-class the class to gain new behaviour.
(3) Monkey-patch the module at runtime.
(4) Fork the module and modify that.
(5) Re-write the whole thing from scratch.
I'd say the ordering of your #3 and #4 are more ambiguous -- if
I'm distributing/deploying a project and my monkey-patching gets
broken (there's a reason monkey-patching feels dirty) by some
python lib upgrade external to my control, then I & my code look
bad. If I freeze a modified/locally-forked library module, it
continues to work regardless of the environment. Maybe that's an
indicator that I did a bad job of monkey patching, but I prefer
to prevent breakage where I can.
-tkc
--
http://mail.python.org/mailman/listinfo/python-list
