Bugfix releases (RE: profiler results for __getattr__, am I reading this correctly ? )

Anthony Baxter anthony at interlink.com.au
Sun Oct 21 02:37:04 EDT 2001


>>> Aahz Maruch wrote
> >It still doesn't cover the process of deciding what would go in the
> >patch release... 
> It doesn't?

Not to the sort of level I was thinking of. The current working list I have
is:

  Code that adds 
    new packages
    new modules
    new methods
  is out. (duh)

  Anything that introduces a large chunk of code should be out.

  Anyone who's subclassing a standard library class shouldn't get screwed
  over - even if they're playing with the internals of the classes.

  C code changes should be _very_ _very_ conservative. Bug fixes that fix 
  problems that people are having are good - anything else should be
  regarded with a hell of a lot of suspicion. And the "don't introduce
  large chunks of new code" test would obviously apply here.

  Things that shouldn't be considered:
    Fixes that "make something work better"
    Fixes that "remove a nasty workaround" 

  In general, I'd like the starting point for any patch to be considered
  as "guilty until proven necessary".

  An example (from a discussion with Guido) is the recent profiler fixup:

    We made two sets of changes to the profiler.  One fixed profile.py 
    to properly interpret exception events.  This one should go in 
    (I specifically tested it with Python 1.5.2 and 2.1).  

    The other changed the C code that generates profiling events to 
    suppress exception events, and to generate return events even when 
    a frame is exited with an exception.  That one should not go in.
 
In trawling the code changes and CVS logs since 2.1.1, I'm taking the
attitude of "if it's not absolutely clear that the code change is safe,
it's out". 

> PEP 6 was designed more to cover core Python than the standard library,
> I'll admit.  I think the intent is pretty clear, though.  If not, I'll
> clean up the language to add some restrictions on library changes.

It's more a matter of additional detail for the PEP...

Anthony
-- 
Anthony Baxter     <anthony at interlink.com.au>   
It's never too late to have a happy childhood.





More information about the Python-list mailing list