[issue12111] email's use of __setitem__ is highly counterintuitive
New submission from Toni Mueller : email's usage of __setitem__ is highly counterintuitive to the point of being dangerous. The documented behaviour is (quote): __setitem__(name, val) Add a header to the message with field name name and value val. The field is appended to the end of the message’s existing fields. Note that this does not overwrite or delete any existing header with the same name. If you want to ensure that the new header is the only one present in the message with field name name, delete the field first, e.g.: ... (taken from http://docs.python.org/library/email.message.html ) The use case of *appending* a header of the same type (eg. a "Received:" header) should be performed by the add_header() method, or an extend_header() method, or something similar, and not by abusing the __setitem__ method. The current behaviour imho deviates extremely from the behaviour of similar libraries in all other programming languages that I'm aware of, and from the standard dict functionality, too. It makes it much too easy to have duplicate headers, esp., duplicate "To:" headers, resulting in mailbombing and information leakage. For the potential damage, this property of the library is highly under-advertised. A side effect appears to be that trying to have your message headers set up in a unique fashion, probably the most frequent use case, one has to make sure to use each operator only once, or "decorate" everything with a del msg[myheader], as the operation is not idempotent. -- messages: 136276 nosy: tonimueller priority: normal severity: normal status: open title: email's use of __setitem__ is highly counterintuitive type: behavior versions: Python 2.6 ___ Python tracker <http://bugs.python.org/issue12111> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue11211] gzip.open() fails for gzipped file
New submission from Toni Mueller : I have files that I would like to read with Python, but can't: $ python jmlreader.py woerter-allg.jml Traceback (most recent call last): File "jmlreader.py", line 14, in readFile(sys.argv[1]) File "jmlreader.py", line 10, in readFile for line in f: File "/usr/lib/python2.6/gzip.py", line 438, in next line = self.readline() File "/usr/lib/python2.6/gzip.py", line 393, in readline c = self.read(readsize) File "/usr/lib/python2.6/gzip.py", line 219, in read self._read(readsize) File "/usr/lib/python2.6/gzip.py", line 255, in _read self._read_gzip_header() File "/usr/lib/python2.6/gzip.py", line 156, in _read_gzip_header raise IOError, 'Not a gzipped file' IOError: Not a gzipped file The file itself is a gzipped file, though: $ gzip -cd woerter-allg.jml|head Unfortunately, the file is a bit weird: $ file woerter-allg.jml woerter-allg.jml: Zip archive data, at least v2.0 to extract Rewriting the program with zlib, instead of gzip, didn't help a bit: $ python jmlreader.py woerter-allg.jml.gz Traceback (most recent call last): File "jmlreader.py", line 15, in readFile(sys.argv[1]) File "jmlreader.py", line 11, in readFile unc = zlib.decompress(s) zlib.error: Error -3 while decompressing data: incorrect header check IOW, the file was actually compressed with gzip, not zip. It would be nice if the gzip module could read the file. I've attached a file that reproduces the problem. -- components: Extension Modules files: test.jml messages: 128550 nosy: tonimueller priority: normal severity: normal status: open title: gzip.open() fails for gzipped file type: behavior versions: Python 2.6 Added file: http://bugs.python.org/file20760/test.jml ___ Python tracker <http://bugs.python.org/issue11211> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
