[Python-Dev] Patch 1644818: Allow importing built-in submodules

"Martin v. Löwis" martin at v.loewis.de
Mon Mar 12 16:52:16 CET 2007

Miguel Lobo schrieb:
>     Personally, I can't apply it as-is right now, since a) I would have to
>     check that the test case conditionalization works fine, and b) I would
>     have to come up with a patch for the Windows build process.
> Sorry, I couldn't understand the second point.  Why would you have to 
> patch the Windows build process?

I need to integrate the extra test file into a project file (probably

> Well, it's not really my place to ask that this patch is prioritised 
> above others, since as I said if I'm asking for its inclusion it is in 
> order to benefit other Python users who may easily hit the same 
> problem.  

Yet, the same can be said for most other patches: they are all for the
benefit of users running into the same respective problems.

> Anyway, I'm intrigued about this "review 5 other patches" procedure you 
> suggest.  What exactly would be involved in such a review?  Please note 
> that I hadn't touched CPython code before I wrote my patch and I haven't 
> been following CPython development closely.

There are a number of mostly mechanical steps that should be applied
to any patch that hasn't seen these steps done yet:
- is it clear what the objective of the patch is? If not, complain to
   the submitter that they should clarify what problem precisely they
   try to solve.
- if so, does the patch actually achieve that objective? If not,
   complain to the submitter that the stated objective and the
   implemented change differ. To determine that, you can either
   * review the code, to see how it fixes the problem, or
   * run the code, to verify that it actually does change the problem
     for the cases tested
   In your review, state which of these approaches you've used.
- As the result of the previous step, it may be that you find that
   the patch is out-of-date. If so, state that in the report.
- Does the patch come with test suite changes, if it changes observable
   behavior? (irrelevant only for pure documentation changes)
- Does the patch come with documentation changes (patches to the Doc
   directory)? These can be waived only for mere bug fixes (e.g. when
   the documented behavior already states what the patch achieves)
- Does the patch include unnecessary changes, or combine multiple
   changes in a single one? That should normally not be done.

When you have all this information collected, write a brief message
into the report indicating what your conclusions are. Ideally, conclude
with one of the following recommendations:
- accept
- reject
- "conditional accept", i.e. needs more work, if so, state what that
   work would be.

When you have dealt with 5 reports that way, post a summary message here
what reports you've looked at, what your conclusion is, and what patch
you want to see expedite processing for.


More information about the Python-Dev mailing list