I love the 'x' mode open in recent versions of Python. I just discovered that lzma.open doesn't support it. It seems there's an elif that explicitly checks the modes allowed. I added "x" and "xb" to the choices and now it works as I would like.

Looks good. Being strict this would be 3.4 material, but patch is trivial and looks like a oversight. We should check other compression modules like gzip, bzip2, etc.

Being strict this would be 3.4 material,

Why? The patch is trivial, I don't how it could cause a regression.

If you don't want regression, add a unit test to test_lzma.py.

Here is the unit test for Tim Heaney's work. There is a test that explicitly tests that we get error when opening in 'x' mode. Also, this test is only for lzma. I think we should create separate tickets for other compression methods.

Okay, I just made similar issues for gzip (bpo-19222) and bz2
(bpo-19223). It's weird how different these three patches are! We're
essentially doing the same thing: "please allow the x option to pass
through to builtins.open." Why don't these three modules look more alike?

On Thu, Oct 10, 2013 at 6:31 AM, Vajrasky Kok <report@bugs.python.org>wrote:

Vajrasky Kok added the comment:

Here is the unit test for Tim Heaney's work. There is a test that
explicitly tests that we get error when opening in 'x' mode. Also, this
test is only for lzma. I think we should create separate tickets for other
compression methods.

----------
keywords: +patch
nosy: +vajrasky
Added file: http://bugs.python.org/file32030/add_x_mode_to_lzma.patch

---

Python tracker <report@bugs.python.org>
<http://bugs.python.org/issue19201\>

---

Is there any reason why the order of characters matters here?
builtins.open() supports them in any order ("br"=="rb", "bw"=="wb", "ba"=="ab", "bx"=="xb").

Also tarfile.open() could support "x" mode.

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').

Added doc. Revamped the test. The patch did not cater to the order of modes ("wb" is equal to "bw"?). I think that deserves a separate ticket.

Stopped the leaking after running the test by adding self.addCleanup.

New changeset b7948aaca1dd by Nadeem Vawda in branch 'default':
Issue bpo-19201: Add support for the 'x' mode to the lzma module.
http://hg.python.org/cpython/rev/b7948aaca1dd

Fix committed. Thanks for the patches!

As Jesús and Terry have said, this won't be backported to 3.3/2.7, since
it is a new feature.

[oylenshpeegul]
| It's weird how different these three patches are! We're
| essentially doing the same thing: "please allow the x option to pass
| through to builtins.open." Why don't these three modules look more alike?

Mostly because they were written at different times, by different people,
with different things to be backward-compatible with. Ideally they would
share the bulk of their code, but it's tricky to do that without changing
behavior in some corner cases.

[terry.reedy]
| 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').

There are two separate questions here - how rigid we are about modes
containing only valid characters, and how we handle invalid characters.

I don't think there's any point in passing through unrecognized chars
to builtins.open(), since it results in a ValueError either way.

On the first point, the code only accepts modes like 'r' and 'rb' (but
not 'br') for the sake of simplicity. There doesn't seem to be much
practical value in accepting arbitrarily-ordered modes, but if someone
has a compelling use-case (or a patch that's no more complex than the
status quo), please bring it up in a separate issue.