This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author terry.reedy
Recipients Arfrever, ethan.furman, jcea, nadeem.vawda, oylenshpeegul, terry.reedy, vajrasky, vstinner
Date 2013-10-12.01:30:37
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1381541437.87.0.781707689873.issue19201@psf.upfronthosting.co.za>
In-reply-to
Content
The bug versus feature issue does not depend on whether the patch could cause a regression. (I think feature patches might actually be less likely than bug fixes to cause regressions, but it does not matter.) Nor is oversight, not adding a feature when it could have been added, a bug. The point is that adding a new feature in a bug-fix release makes it a feature release, and this is a new feature. Code that uses the new feature will not run on previous releases of the same version.

The doc for lzma.open says "The mode argument can be any of "r", "rb", "w", "wb", "a" or "ab" for binary mode, or "rt", "wt", or "at" for text mode. The default is "rb"." (I assume that) the code does just what the doc says. (If it did not, *that* would be a bug).

Arfrever's point about the order of characters makes me wonder why mode strings (as opposed to characters in the strings) are being checked. The following tests that exactly one of w, a, x appear in mode.
  if len({'w', 'a', 'x'} & set(mode)) == 1:
If mode is eventually passed to open(), the latter would do what ever it does with junk chars in mode (such as 'q').
History
Date User Action Args
2013-10-12 01:30:37terry.reedysetrecipients: + terry.reedy, jcea, vstinner, nadeem.vawda, Arfrever, ethan.furman, vajrasky, oylenshpeegul
2013-10-12 01:30:37terry.reedysetmessageid: <1381541437.87.0.781707689873.issue19201@psf.upfronthosting.co.za>
2013-10-12 01:30:37terry.reedylinkissue19201 messages
2013-10-12 01:30:37terry.reedycreate