Help improve Python -- Call for reviewers

Discussion in 'Python' started by Raymond Hettinger, Aug 27, 2003.

  1. Sourceforge is used to track bug reports, feature requests, and patches:
    https://sourceforge.net/projects/python/

    Each of those submissions needs to be reviewed and discussed.
    A good way to participate in python development is to spend
    some time adding useful comments to each report.

    Bug reports
    ------------
    * Sometimes the OP thinks a bug is present when, in fact, Python
    is behaving as intended. It is useful to gently steer them in the
    right direction, correct their understanding, and have them close
    the bug report.

    * Sometimes the bug is unique to OP's own environment and it
    is helpful to have another person confirm the bug on another
    machine.

    * Often, a bug report is inadequately specific -- "My 200 line script
    doesn't work". Help is needed to refine the report to the simplest
    possible demonstration of the error: bool("False")!=False.

    * It is even more helpful to specifically identify where the error is
    occurring in the source: line 200 in textwrap.py has an and/or problem.

    * In many cases, discussion is necessary to ascertain whether the
    behavior is truly a bug, a documentation issue, or a natural byproduct
    of other important invariants.

    * It is also helpful to suggest alternative solutions and discuss the
    implications of each.


    Patches
    --------

    * The simplest checks are:
    - does it work
    - does it have unittests
    - does it have a doc patch

    * More advanced considerations:
    - are there subtle code breakages (one man's bug is another's feature)
    - is the change desirable
    - would a refactoring have simplified the problem
    - are there unintended consequences
    - is there a better alternative solution


    Feature Requests
    -------------------
    The basic idea here is to see whether life would truly be better if the
    idea were adopted. Considerations include the minimizing the rate of
    language growth, ease of implementation, how it fits in with the
    rest of the language, and the existence of practice use cases.

    Readers of comp.lang.python are also in a good position to make
    comments on the idea and how it fits in with stated Python design
    goals. For example, IDLE could easily grow macros, RCS buttons,
    templates and such, but it's design goal is to be a relatively simple
    yet complete, portable editor/ide written in pure python -- this means
    that grandiose ideas to transform it into emacs will likely not be accepted.

    The presence of a feature in another language is neither cause for
    acceptance or rejection. Just because Perl, PHP, VB, or Ruby does
    something, it is not necessarily good or necessarily bad. It does
    at least provide a proof-of-concept and real world experience with
    the feature so that we can learn from its successes or failures. The
    itertools module was designed to capture some of the successes
    in Haskell and ML.



    Raymond Hettinger
    Raymond Hettinger, Aug 27, 2003
    #1
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    5
    Views:
    385
    Hywel Jenkins
    Dec 21, 2005
  2. David Mertz, Ph.D.

    Reviewers for _Text Processing in Python_

    David Mertz, Ph.D., Aug 22, 2003, in forum: Python
    Replies:
    0
    Views:
    312
    David Mertz, Ph.D.
    Aug 22, 2003
  3. Han-Wen Nienhuys

    cross-compiling python: reviewers needed

    Han-Wen Nienhuys, Dec 20, 2006, in forum: Python
    Replies:
    1
    Views:
    338
    David Boddie
    Dec 20, 2006
  4. rCs
    Replies:
    0
    Views:
    314
  5. Robert Seacord
    Replies:
    118
    Views:
    2,678
    Douglas A. Gwyn
    Apr 22, 2008
Loading...

Share This Page