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 rhpvorderman
Recipients rhpvorderman
Date 2021-02-24.14:34:00
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1614177240.99.0.73469579254.issue43316@roundup.psfhosted.org>
In-reply-to
Content
`Python -m gzip -d myfile` will throw an error because myfile does not end in '.gz'. That is fair (even though a bit redundant, GzipFile contains a header check, so why bother checking the extension?).

The problem is how this error is thrown.
1. Error is printed to stdout instead of stderr
2. Tool exits with exit 0.

This is not the behaviour that is expected when using python -m gzip in a script.

The error is even codified in a test: https://github.com/python/cpython/blob/1f433406bd46fbd00b88223ad64daea6bc9eaadc/Lib/test/test_gzip.py#L776

    def test_decompress_infile_outfile_error(self):
        rc, out, err = assert_python_ok('-m', 'gzip', '-d', 'thisisatest.out')
        self.assertIn(b"filename doesn't end in .gz:", out)
        self.assertEqual(rc, 0)
        self.assertEqual(err, b'')

This should be assert_python_failure, out and err should be swapped, and exit code should be something different than 0.

From the zen of python: Errors should never pass silently.

I am willing to fix this in a PR, but first I would like some feedback on how to solve this exactly. 

I propose raising a ValueError("can not determine output filename: 'myfile' does not end in '.gz'").
History
Date User Action Args
2021-02-24 14:34:01rhpvordermansetrecipients: + rhpvorderman
2021-02-24 14:34:00rhpvordermansetmessageid: <1614177240.99.0.73469579254.issue43316@roundup.psfhosted.org>
2021-02-24 14:34:00rhpvordermanlinkissue43316 messages
2021-02-24 14:34:00rhpvordermancreate