Ezio Melotti <ezio.melo...@gmail.com> added the comment:

> Out of curiosity, what is typically the convention on that?

In theory every issue should be about a single problem and therefore have a 
single patch to fix it.  Sometimes a secondary "problem" that is not strictly 
related to the first one arises, for example when a cleanup is necessary before 
applying the patch, or when a new feature is added and a few places get changed 
to use it.  In these cases is not worth opening another issue, so both the 
patches are attached to the same issue, but committed separately because they 
address two different "problems".

> Sometime people forget to add a News or Acks entry and have to
> followup with an addendum. (Mark's patch still lack that, for 
> instance.)

Avoiding to include the NEWS entry in patches is common, because the file gets 
updated often and it will most likely cause conflicts.  `make patchcheck` 
remind us to add it -- assuming you don't forget to use it.

> Ezio's patch looks fine to me, though as Meador points out in the 
> Rietveld review, there are a couple of omissions that could be fixed.

Adding keepends there would have made the line too long, required some 
splitting and probably made the code less readable overall, so I prefer to keep 
it out.

> Personally, I'm not so convinced of the value of upgrading all the
> existing uses of splitlines to use 'keepends'; I just wanted to be
> able to do this in *new* code. :-)

If we can make old code more readable too and we already have a patch to do it, 
why not?  (one instance also had the comment # True == keep line ends)

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue13012>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to