[issue6352] Compiler warning in unicodeobject.c
Hagen Fürstenau added the comment: Apparently this was never backported to 3.1. -- ___ Python tracker <http://bugs.python.org/issue6352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8785] findall() and finditer() docs misleading
New submission from Hagen Fürstenau : The docs for the RegexpObject methods findall and finditer are misleading: They are said to behave the same way as the respective functions, but in fact the parameter semantics are different. -- assignee: d...@python components: Documentation messages: 106286 nosy: d...@python, hagen priority: normal severity: normal status: open title: findall() and finditer() docs misleading versions: Python 2.6, Python 2.7, Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue8785> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau added the comment: IIUC, the only change you suggest for my patch is using "finite iterable" instead of "sequence" or "iterable", right? I've looked at the docs and there seems to be no precedent for "finite iterable". I think it's just as obvious that the iterable has to yield a correct (and finite) number of parameters as the fact that "list(itertools.count())" is a bad idea. So for consistency I would like to keep "iterable". -- ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau added the comment: Attaching a combined patch against the current py3k. -- Added file: http://bugs.python.org/file18404/combined.patch ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9887] distutil's build_scripts doesn't read utf-8 in all locales
New submission from Hagen Fürstenau : "LANG=C python3 setup.py build_scripts" chokes on UTF-8 encoded scripts. The problem is that "copy_scripts" uses "open" without specifying an encoding. This issue may be related to #9561. -- assignee: tarek components: Distutils messages: 116660 nosy: eric.araujo, hagen, tarek priority: normal severity: normal status: open title: distutil's build_scripts doesn't read utf-8 in all locales versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue9887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9887] distutil's build_scripts doesn't read utf-8 in all locales
Hagen Fürstenau added the comment: Why does this matter? PEP 3120 specifies UTF-8 as the default source encoding. -- ___ Python tracker <http://bugs.python.org/issue9887> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9561] distutils: set encoding to utf-8 for input and output files
Changes by Hagen Fürstenau : -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue9561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10300] Documentation of three PyDict_* functions
New submission from Hagen Fürstenau : The documentation of the functions PyDict_Items, PyDict_Keys and PyDict_Values is incorrect: They do return PyListObject, but in Python 3.x this is not the same as dict.items() etc. -- assignee: d...@python components: Documentation messages: 120328 nosy: d...@python, hagen priority: normal severity: normal status: open title: Documentation of three PyDict_* functions versions: Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue10300> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10300] Documentation of three PyDict_* functions
Hagen Fürstenau added the comment: The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem to be broken. -- ___ Python tracker <http://bugs.python.org/issue10300> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12087] install_egg_info fails with UnicodeEncodeError depending on locale
New submission from Hagen Fürstenau : With issue 10419 fixed, I've run into the next distutils unicode bug: The command "install_egg_info" doesn't specify an encoding when opening the ".egg-info" file for writing. Depending on the locale, this may result in something like the following: $ python setup.py install [...] Traceback (most recent call last): File "setup.py", line 67, in main() File "setup.py", line 62, in main cmdclass={"test":TestCommand}, File "/home/hagen/src/python/Lib/distutils/core.py", line 149, in setup dist.run_commands() File "/home/hagen/src/python/Lib/distutils/dist.py", line 919, in run_commands self.run_command(cmd) File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command cmd_obj.run() File "/home/hagen/src/python/Lib/distutils/command/install.py", line 583, in run self.run_command(cmd_name) File "/home/hagen/src/python/Lib/distutils/cmd.py", line 315, in run_command self.distribution.run_command(command) File "/home/hagen/src/python/Lib/distutils/dist.py", line 938, in run_command cmd_obj.run() File "/home/hagen/src/python/Lib/distutils/command/install_egg_info.py", line 44, in run self.distribution.metadata.write_pkg_file(f) File "/home/hagen/src/python/Lib/distutils/dist.py", line 1033, in write_pkg_file file.write('Author: %s\n' % self.get_contact() ) UnicodeEncodeError: 'ascii' codec can't encode character '\xfc' in position 15: ordinal not in range(128) I guess some encoding (UTF-8?) should be specified in the "run" method of "install_egg_info". -- assignee: tarek components: Distutils messages: 136084 nosy: eric.araujo, hagen, tarek priority: normal severity: normal status: open title: install_egg_info fails with UnicodeEncodeError depending on locale type: crash versions: Python 3.2, Python 3.3 ___ Python tracker <http://bugs.python.org/issue12087> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10419] distutils command build_scripts fails with UnicodeDecodeError
New submission from Hagen Fürstenau : As suggested in issue 9561, I'm creating a new bug for the encoding problem in build_scripts: If a script file can't be decoded with the (locale dependent) standard encoding, then "build_scripts" fails with UnicodeDecodeError. Reproducable e.g. with LANG=C and a script file containing non ASCII chars near the beginning (so that they're read on a single readline()). Attaching a patch that uses "surrogateescape", as proposed for issue 6011. -- assignee: tarek components: Distutils files: surrogateescape.patch keywords: patch messages: 121207 nosy: eric.araujo, hagen, tarek priority: normal severity: normal status: open title: distutils command build_scripts fails with UnicodeDecodeError type: crash versions: Python 3.1, Python 3.2 Added file: http://bugs.python.org/file19607/surrogateescape.patch ___ Python tracker <http://bugs.python.org/issue10419> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue9561] distutils: set encoding to utf-8 for input and output files
Hagen Fürstenau added the comment: Created issue 10419 for the encoding problem in "build_scripts". -- ___ Python tracker <http://bugs.python.org/issue9561> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10640] SystemError on pickling bytes >= 4GB
New submission from Hagen Fürstenau : Pickling a bytes object of length >= 2**32 results in a "SystemError: error return without exception set". If pickling large bytes objects isn't supported, this should be documented and a helpful exception be raised. -- components: Library (Lib) messages: 123499 nosy: hagen priority: normal severity: normal status: open title: SystemError on pickling bytes >= 4GB versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue10640> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12953] Function calls missing from profiler output
New submission from Hagen Fürstenau : I noticed that some function calls don't get reported by profile/cProfile. For example, 'len' works fine, but calls to 'range' or functions in 'itertools' don't show up. Is this a known limitation? I remember that there was a bug in profiling C-functions with keyword arguments (issue5330, fixed), but I don't have the time right now to investigate whether this is related. -- components: Library (Lib) messages: 143813 nosy: hagen priority: normal severity: normal status: open title: Function calls missing from profiler output type: behavior versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue12953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue12953] Function calls missing from profiler output
Hagen Fürstenau added the comment: It happens for other C functions as well, e.g. itertools.permutations: >>> profile.run('itertools.permutations(range(10), 3)') 4 function calls in 0.000 seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.0000.0000.000 :0(exec) 10.0000.0000.0000.000 :0(setprofile) 10.0000.0000.0000.000 :1() 10.0000.0000.0000.000 profile:0(itertools.permutations(range(10), 3)) 00.000 0.000 profile:0(profiler) -- ___ Python tracker <http://bugs.python.org/issue12953> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6038] Should collections.Counter check for int?
New submission from Hagen Fürstenau : I noticed that while the docs say that "Counts are allowed to be any integer value including zero or negative counts", collections.Counter doesn't perform any check on the types of count values. Instead, non-numerical values will lead to strange behaviour or exceptions later on: >>> c = collections.Counter({'a':'3', 'b':'20', 'c':'100'}) >>> c.most_common(2) [('a', '3'), ('b', '20')] >>> c+c Traceback (most recent call last): File "", line 1, in File "/local/hagenf/lib/python3.1/collections.py", line 467, in __add__ if newcount > 0: TypeError: unorderable types: str() > int() I'd prefer Counter to refuse non-numerical values right away as the present behaviour may hide bugs (e.g. a forgotten string->int conversion). Any opinions? (And what about negative values or floats?) -- components: Library (Lib) messages: 87874 nosy: hagen severity: normal status: open title: Should collections.Counter check for int? type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6038> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6150] test_unicode fails in wide unicode build
New submission from Hagen Fürstenau : ERROR: test_codecs_utf8 (__main__.UnicodeTest) -- Traceback (most recent call last): File "Lib/test/test_unicode.py", line 911, in test_codecs_utf8 self.assertEqual('\ud800\udc02'.encode('utf-8'), b'\xf0\x90\x80\x82') UnicodeEncodeError: 'utf-8' codec can't encode character '\ud800' in position 0: surrogates not allowed -- components: Tests messages: 88579 nosy: hagen severity: normal status: open title: test_unicode fails in wide unicode build versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6150> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau added the comment: I added a simple check for iterables. This is not very elegant, but performance is only affected in the case of an exception. Patch and corresponsing test are attached as "TypeError.patch". As I pointed out above, the actual error message "must be a sequence" is also inconsistent with the implementation (and tests) which allows any kind of iterable. The attached and independent patch "message_and_docs.patch" changes this to "must be an iterable" and corrects docs and tests accordingly. -- keywords: +patch versions: +Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14166/TypeError.patch ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Changes by Hagen Fürstenau : Added file: http://bugs.python.org/file14167/message_and_docs.patch ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau added the comment: Sorry, I had meant to use PyIter_Check instead of PyObject_GetIter. Don't know why I didn't do so... ;-) I corrected the patch. -- Added file: http://bugs.python.org/file14169/TypeError2.patch ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file14166/TypeError.patch ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Hagen Fürstenau added the comment: The latest patch is missing the file "Lib/_compat.pickle.py". (Seems as if you forgot to svn add it after patching.) -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue6137> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6137] Make pickle generated by Python 3.x compatible with 2.x and vice-versa.
Hagen Fürstenau added the comment: I think it is worth noting that now some Python 3.1 protocol 2 pickles can't be read by Python 3.0. We probably don't have to do anything about that, but perhaps it should be mentioned somewhere? Docs, release notes? -- status: pending -> open ___ Python tracker <http://bugs.python.org/issue6137> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6256] Wrong stacklevel in warning for contextlib.nested
New submission from Hagen Fürstenau : This leads to unhelpful warnings: >>> with contextlib.nested(open("x", "w")) as f: pass ... /usr/local/lib/python3.1/contextlib.py:17: DeprecationWarning: With-statements now directly support multiple context managers return next(self.gen) Patch is attached. -- components: Library (Lib) files: warning_stacklevel.patch keywords: patch messages: 89209 nosy: hagen severity: normal status: open title: Wrong stacklevel in warning for contextlib.nested type: behavior versions: Python 2.7, Python 3.1 Added file: http://bugs.python.org/file14259/warning_stacklevel.patch ___ Python tracker <http://bugs.python.org/issue6256> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6288] Update contextlib.nested docs in light of deprecation
Hagen Fürstenau added the comment: Does that mean that nested() can be removed or changed incompatibly in 3.2 at the same time that an alternative way for handling the remaining use case is introduced? This would seem to violate the promise in PEP 5, that "users will have at least a year to test their programs and migrate them from use of the deprecated construct to the alternative one". -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue6288> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6351] Compiler warning in _cursesmodule.c
New submission from Hagen Fürstenau : My gcc complains that the variables x and y might be used uninitialized in the function PyCurses_getsyx in Modules/_cursesmodule.c. This is because the macro getsyx of curses.h apparently only sets x and y if newscr is not NULL. There seems to have been a related discussion last year: http://mail.python.org/pipermail/python-dev/2008-March/077496.html -- components: Build messages: 89763 nosy: hagen severity: normal status: open title: Compiler warning in _cursesmodule.c versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6351> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6352] Compiler warning in unicodeobject.c
New submission from Hagen Fürstenau : Compiling --with-wide-unicode there's a warning that encodeUCS4 is defined, but not used. A trivial patch for this is attached. -- files: warning.patch keywords: patch messages: 89764 nosy: hagen severity: normal status: open title: Compiler warning in unicodeobject.c versions: Python 3.1 Added file: http://bugs.python.org/file14373/warning.patch ___ Python tracker <http://bugs.python.org/issue6352> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6364] freeze tool broken in Python 3.x
New submission from Hagen Fürstenau : The freeze tool seems to be severely broken in Python 3.x. Applying it to a "hello world" script produces: Warning: unknown modules remain: _bisect _collections _ctypes _hashlib _heapq _multiprocessing _pickle _random _socket _ssl _struct _tkinter array atexit binascii datetime fcntl itertools math mmap operator pyexpat readline select termios time and a subsequent make results in config.o:(.data+0x8): undefined reference to `init_codecs' config.o:(.data+0x18): undefined reference to `init_functools' config.o:(.data+0x28): undefined reference to `init_io' config.o:(.data+0x38): undefined reference to `init_locale' config.o:(.data+0x48): undefined reference to `init_sre' config.o:(.data+0x58): undefined reference to `init_thread' config.o:(.data+0x68): undefined reference to `init_weakref' config.o:(.data+0x78): undefined reference to `initerrno' config.o:(.data+0x88): undefined reference to `initgc' config.o:(.data+0x98): undefined reference to `initimp' config.o:(.data+0xa8): undefined reference to `initposix' config.o:(.data+0xb8): undefined reference to `initpwd' config.o:(.data+0xc8): undefined reference to `initsignal' config.o:(.data+0xd8): undefined reference to `initzipimport' -- components: Demos and Tools messages: 89808 nosy: hagen severity: normal status: open title: freeze tool broken in Python 3.x type: behavior versions: Python 3.1 ___ Python tracker <http://bugs.python.org/issue6364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6364] freeze tool broken in Python 3.x
Hagen Fürstenau added the comment: > Would you like to provide a patch? I wouldn't mind if someone beat me to it. But if that doesn't happen, I'll look into it when I have some time to spare. -- ___ Python tracker <http://bugs.python.org/issue6364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6364] freeze tool broken in Python 3.x
Hagen Fürstenau added the comment: I get the same error as before with a fresh install of r73676 on Linux. $ uname -a Linux zhuangzi 2.6.28-13-generic #44-Ubuntu SMP Tue Jun 2 07:55:09 UTC 2009 x86_64 GNU/Linux -- ___ Python tracker <http://bugs.python.org/issue6364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6474] Inconsistent TypeError message on function calls with wrong number of arguments
New submission from Hagen Fürstenau : I think the following error messages are inconsistent and confusing: >>> def f(a, b): pass ... >>> f(a=1) Traceback (most recent call last): File "", line 1, in TypeError: f() takes exactly 2 non-keyword positional arguments (1 given) >>> f(b=1) Traceback (most recent call last): File "", line 1, in TypeError: f() takes exactly 2 non-keyword positional arguments (0 given) Strictly speaking, no positional arguments are given in either case, so it should say "(0 given)" in both cases. On the other hand, the given keyword arguments are filled into the positional argument slots, so stating something like "(1 missing)" or "(1 unspecified)" in both cases seems to make more sense. Any opinions? -- components: Interpreter Core messages: 90485 nosy: hagen severity: normal status: open title: Inconsistent TypeError message on function calls with wrong number of arguments type: behavior versions: Python 2.7, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6474> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6364] freeze tool broken in Python 3.x
Hagen Fürstenau added the comment: I'm attaching a patch with the minimal changes I had to make to get a "hello world" script frozen under 3.x. They all have to do with changes between 2.x and 3.x. -- keywords: +patch Added file: http://bugs.python.org/file14502/freeze.patch ___ Python tracker <http://bugs.python.org/issue6364> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6477] Pickling of NoneType raises PicklingError
Hagen Fürstenau added the comment: > but I think it is a bug I think it is either a feature request (make NoneType picklable) or a documentation issue (document that it's not). -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue6477> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6473] hmac sha384/sha512 fails test vectors
Hagen Fürstenau added the comment: Seems like this has already been fixed as issue 1385. -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue6473> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Changes by Hagen Fürstenau : -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Hagen Fürstenau added the comment: Seems to have been fixed around r73896. -- ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6738] Wrong doc strings in itertools
New submission from Hagen Fürstenau : The doc strings of itertools.combinations and itertools.combinations_with_replacement are wrong: The parameter "r" is not optional here (like it is for itertools.permutations). Attached trivial patch. -- components: Library (Lib) files: docstring.patch keywords: patch messages: 91761 nosy: hagen severity: normal status: open title: Wrong doc strings in itertools type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14746/docstring.patch ___ Python tracker <http://bugs.python.org/issue6738> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2698] Extension module build fails for MinGW: missing vcvarsall.bat
Hagen Fürstenau added the comment: Shouldn't r73896 be backported to the 3.1 branch? I still get "Unable to find vcvarsall.bat" with Python 3.1.1. -- ___ Python tracker <http://bugs.python.org/issue2698> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6846] bytearray.pop() returns negative ints
New submission from Hagen Fürstenau : This looks pretty bad: >>> b = bytearray(b"\xff") >>> b[0] 255 >>> b.pop() -1 Fortunately it's easy too fix (attached). -- components: Interpreter Core messages: 92292 nosy: hagen severity: normal status: open title: bytearray.pop() returns negative ints type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 ___ Python tracker <http://bugs.python.org/issue6846> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6846] bytearray.pop() returns negative ints
Changes by Hagen Fürstenau : -- keywords: +patch Added file: http://bugs.python.org/file14842/bytearray.patch ___ Python tracker <http://bugs.python.org/issue6846> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue6847] Exception strings for bytearray say "bytes"
New submission from Hagen Fürstenau : Various exceptions thrown by bytearray objects talk of "bytes" instead of "bytearray". Correction attached. -- components: Interpreter Core files: bytearray_strings.patch keywords: patch messages: 92293 nosy: hagen severity: normal status: open title: Exception strings for bytearray say "bytes" type: behavior versions: Python 2.6, Python 2.7, Python 3.1, Python 3.2 Added file: http://bugs.python.org/file14843/bytearray_strings.patch ___ Python tracker <http://bugs.python.org/issue6847> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3404] wrong precision in float formatting
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: This seems to be wrong: >>> "{0:.2}".format(1.2345) '1.2' The same happens for format specifiers "g" and "n", but not for "f": >>> "{0:.2f}".format(1.2345) '1.23' With empty format specifier it can even get really wrong: >>> "{0:.1}".format(1.2345) '1.0' -- components: Interpreter Core messages: 69947 nosy: hagen severity: normal status: open title: wrong precision in float formatting type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3404> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3404] wrong precision in float formatting or doc error
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Just found it documented for the % operator: There precision is number of digits before and after decimal point for format "g". But then the documentation for 2.6 is wrong: "The precision is a decimal number indicating how many digits should be displayed after the decimal point for a floating point value." -- assignee: -> georg.brandl components: +Documentation nosy: +georg.brandl title: wrong precision in float formatting -> wrong precision in float formatting or doc error type: behavior -> ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3404> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3411] str.format() on negative floats
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: This happens with an empty type field in the format specification: >>> "{0:1}".format(-1.23) '.0-1.23' With type "g" it's ok: >>> "{0:1g}".format(-1.23) '-1.23' -- components: Library (Lib) messages: 69988 nosy: hagen severity: normal status: open title: str.format() on negative floats versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3411> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3675] Python 2.6 can't read sets pickled with Python 3.0
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: After pickling a set of ints with Python 3.0 and pickle protocol 2: [EMAIL PROTECTED] ~]$ python3.0 Python 3.0b3 (r30b3:65927, Aug 21 2008, 11:48:29) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> f = open("test", "wb") >>> pickle.dump({1,2,3}, f, 2) >>> f.close() I get the following error when trying to read this with Python 2.6: [EMAIL PROTECTED] ~]$ python Python 2.6b3 (r26b3:65922, Aug 21 2008, 11:42:25) [GCC 4.1.0 20060304 (Red Hat 4.1.0-3)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> f = open("test", "rb") >>> pickle.load(f) Traceback (most recent call last): File "", line 1, in File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1370, in load return Unpickler(file).load() File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 858, in load dispatch[key](self) File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1090, in load_global klass = self.find_class(module, name) File "/home/MC/hagenf/local/lib/python2.6/pickle.py", line 1124, in find_class __import__(module) ImportError: No module named builtins -- components: Library (Lib) messages: 71916 nosy: hagen severity: normal status: open title: Python 2.6 can't read sets pickled with Python 3.0 versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3675] Python 2.6 can't read sets pickled with Python 3.0
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Well, this is obviously caused by renaming "__builtin__" to "builtins" and the fact that set (as well as frozenset) doesn't have its own opcode and therefore gets looked up in "builtins". The problem therefore extends to all builtin objects without opcode special casing (e.g. object, slice, property, ...) I'm afraid that means we have to pickle "builtins" as "__builtin__" for backwards compatibility in protocols <= 2. But aside from that, wouldn't it be more consistent to have opcodes for set/frozenset in protocol 3? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3703] open() on directory raises IOError with unhelpful message
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: When trying to open a directory (on Linux), Python 2.x complained with >>> open("local") Traceback (most recent call last): File "", line 1, in IOError: [Errno 21] Is a directory Python 3.0 however gives the rather unhelpful or even wrong >>> open("local") Traceback (most recent call last): File "", line 1, in File "/home/MC/hagenf/local/lib/python3.0/io.py", line 284, in __new__ return open(*args, **kwargs) File "/home/MC/hagenf/local/lib/python3.0/io.py", line 223, in open closefd) IOError: [Errno 0] Error: 'local' -- components: Library (Lib) messages: 72033 nosy: hagen severity: normal status: open title: open() on directory raises IOError with unhelpful message type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3703> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3675] Python 2.6 can't read sets pickled with Python 3.0
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Well, Python <= 2.5 still wouldn't be able to unpickle those built in objects. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3675> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: On Python 3.0: >>> class C: ... def __len__(self): return "foo" ... >>> len(C()) Traceback (most recent call last): File "", line 1, in SystemError: Objects/longobject.c:433: bad argument to internal function On Python 2.6 the behaviour is different for old and new-style classes, with old-style classes giving the more informative error message and both accepting (and truncating) floats. I attached a patch for Python 3.0, which refuses everything but ints and gives an informative error message. Or does the float-truncating behaviour of Python 2.x need to be preserved? -- files: len_check.diff keywords: patch messages: 72141 nosy: hagen severity: normal status: open title: SystemError on calling len() if __len__() doesn't return an int type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file11307/len_check.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Sounds ok, but then you get a more generic "object cannot be interpreted as an integer" at the point where len() is called, instead of the clearer "__len__() should return an int". I'm not sure if this could be confusing. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Of course we can do both: Accept integral-like types and reset the exception text. The new patch does this and adds a test for the new behaviour. Review carefully - I'm a newbie! ;-) Added file: http://bugs.python.org/file11308/len_check2.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue2723] Truncate __len__() at sys.maxsize
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>: -- nosy: +hagen ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue2723> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: In the latest list message I could find Guido wanted len() to lie: http://mail.python.org/pipermail/python-3000/2008-May/013387.html Has this been resolved in issue 2723? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3745] _sha256 et al. encode to UTF-8 by default
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: Whereas openssl-based _hashlib refuses to accept unencoded strings: >>> _hashlib.openssl_sha256("\xff") Traceback (most recent call last): File "", line 1, in TypeError: object supporting the buffer API required the _sha256 version encodes to UTF-8 by default: >>> _sha256.sha256("\xff").digest() == _sha256.sha256("\xff".encode("utf-8")).digest() True I think refusing is better, but at least the behaviour should be consistent. Same for the other algorithms in hashlib. -- components: Library (Lib) messages: 72220 nosy: hagen severity: normal status: open title: _sha256 et al. encode to UTF-8 by default type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3745> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: There seems to be a pronouncement now (http://mail.python.org/pipermail/python-3000/2008-September/014692.html), so I'm attaching a patch which clips to sys.maxsize and includes Amaury's suggestions. Added file: http://bugs.python.org/file11349/len_check3.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11307/len_check.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3729] SystemError on calling len() if __len__() doesn't return an int
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>: Removed file: http://bugs.python.org/file11308/len_check2.diff ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3729> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3860] GzipFile and BZ2File should support context manager protocol
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: When you've become used to writing with open("xzy", "w") as f: it's strange when it doesn't work for gzip.open or bz2.BZ2File. Or is there a reason for them not being context managers? -- components: Library (Lib) messages: 73194 nosy: hagen severity: normal status: open title: GzipFile and BZ2File should support context manager protocol type: feature request versions: Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3860> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Yes, it gets much better, but even so (first reading file and timing only "loads") unpickling takes four times as long in Python 3.0 as with the old cPickle module: [EMAIL PROTECTED] hagenf]$ python pickletst2.py 0.0744678974152 0.0514161586761 [EMAIL PROTECTED] hagenf]$ python3.0 pickletst3.py 0.0911619663239 0.208593845367 But I guess this can still be blamed on the BytesIO implementation... ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: Unpickling e.g. a large list seems to be really slow in Python 3.0. The attached test script gives the following results for pickling and unpickling a list of 1M zeros, showing that although the C implementation seems to be used in Python 3.0, unpickling is even slower than with the "pickle" module of Python 2.6! [EMAIL PROTECTED] hagenf]$ python pickletst.py 2.71067500114 2.77484893799 [EMAIL PROTECTED] hagenf]$ python3.0 pickletst.py 0.0925059318542 5.76121616364 -- components: Library (Lib) files: pickletst.py messages: 73267 nosy: hagen severity: normal status: open title: Unpickling is really slow type: performance versions: Python 3.0 Added file: http://bugs.python.org/file11497/pickletst.py ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3929] Incorrect exception raising in dbm.open on non-existing DB
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: Opening a dbm database which doesn't exist without a "c" or "n" flag results in this exception: >>> import dbm >>> dbm.open("abc") Traceback (most recent call last): File "", line 1, in File "/home/MP.shadow/hagenf/local/src/py3k/Lib/dbm/__init__.py", line 79, in open raise error("need 'c' or 'n' flag to open new db") TypeError: 'tuple' object is not callable "error" is a tuple of dbm's own exception class and IOError, but this doesn't seem to make sense in the present code and Python 3.0. The attached patch fixes the problem and adds a test for the correct exception being raised. -- components: Library (Lib) files: dbm.patch keywords: patch messages: 73563 nosy: hagen severity: normal status: open title: Incorrect exception raising in dbm.open on non-existing DB type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11555/dbm.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3929> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3929] Incorrect exception raising in dbm.open on non-existing DB
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: I didn't know until I had googled this: http://mail.python.org/pipermail/python-3000/2007-March/005916.html ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3929> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4283] "python3.0 setup.py install --user" raises AttributeError
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: A simple left-over "dict.iteritems". Patch is attached. -- components: Distutils files: distutils.patch keywords: patch messages: 75634 nosy: hagen severity: normal status: open title: "python3.0 setup.py install --user" raises AttributeError type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11965/distutils.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4283> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4298] pickle segfault or MemoryError on invalid input
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: On a 64-bit build pickle.loads segfaults on the following bytes. (Same for pickle.load on a corresponding file.) On a 32-bit build there is only a MemoryError. Python 3.0rc2 (r30rc2:67114, Nov 10 2008, 12:09:54) [GCC 4.1.2 20070925 (Red Hat 4.1.2-27)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import pickle >>> pickle.loads(bytes([0x58, 0, 0, 0, 0x54])) Segmentation fault -- components: Library (Lib) messages: 75743 nosy: hagen severity: normal status: open title: pickle segfault or MemoryError on invalid input type: crash versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4298> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4307] inspect.FullArgSpec does not match the docs
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: The docs say that inspect.FullArgSpec is a named tuple FullArgSpec(args, varargs, varkw, defaults, kwonlyargs, kwonlydefaults, annotations) However the implementation has "kwdefaults" instead of "kwonlydefaults". The name in the docs seems to make more sense. A patch fixing this is attached. -- components: Library (Lib) files: inspect.patch keywords: patch messages: 75788 nosy: hagen severity: normal status: open title: inspect.FullArgSpec does not match the docs type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file11994/inspect.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4307> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4312] Unicode in distutils meta-data?
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: http://docs.python.org/dev/3.0/distutils/setupscript.html#additional-meta-data says "None of the string values may be Unicode.". How is this to be interpreted (or changed) w.r.t. Python 3.0? -- assignee: georg.brandl components: Documentation messages: 75816 nosy: georg.brandl, hagen severity: normal status: open title: Unicode in distutils meta-data? versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4312> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4338] TypeError (bytes/str) in distutils command "upload"
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: "python3.0 setup.py upload" (on an otherwise sane setup script) results in the following: Traceback (most recent call last): File "setup.py", line 5, in import py3setup File "/home/MP/hagenf/src/pyskein/py3setup.py", line 22, in ext_modules=[ext]) File "/home/MP/hagenf/local/lib/python3.0/distutils/core.py", line 149, in setup dist.run_commands() File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line 942, in run_commands self.run_command(cmd) File "/home/MP/hagenf/local/lib/python3.0/distutils/dist.py", line 962, in run_command cmd_obj.run() File "/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line 55, in run self.upload_file(command, pyversion, filename) File "/home/MP/hagenf/local/lib/python3.0/distutils/command/upload.py", line 116, in upload_file auth = "Basic " + base64.encodestring(self.username + ":" + self.password).strip() File "/home/MP/hagenf/local/lib/python3.0/base64.py", line 338, in encodestring raise TypeError("expected bytes, not %s" % s.__class__.__name__) TypeError: expected bytes, not str -- components: Distutils messages: 75975 nosy: hagen severity: normal status: open title: TypeError (bytes/str) in distutils command "upload" type: behavior versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4338> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4338] TypeError (bytes/str) in distutils command "upload"
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: I just tested Amaury's patch and it seems to work fine. There's a similar str/bytes issue with the "register" command, but I'll open another issue for that. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4338> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4354] distutils.command.register is broken
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: The distutils command "register" has two problems with Python 3.0: 1. The authentication dialog crashes because of a problem with the functiopn raw_input defined there. 2. Uploading the data fails because of str/bytes confusion. The attached patch addresses both problems. -- components: Distutils files: distutils_register.patch keywords: patch messages: 76055 nosy: hagen severity: normal status: open title: distutils.command.register is broken type: behavior versions: Python 3.0 Added file: http://bugs.python.org/file12058/distutils_register.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4355] Error in docs of urllib.request and urllib.parse
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: The docs refer to urllib.urlencode instead of urllib.parse.urlencode. A patch is attached. -- assignee: georg.brandl components: Documentation files: doc_urlencode.patch keywords: patch messages: 76056 nosy: georg.brandl, hagen severity: normal status: open title: Error in docs of urllib.request and urllib.parse versions: Python 3.0 Added file: http://bugs.python.org/file12059/doc_urlencode.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4355> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4354] distutils.command.register is broken
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: Attached new patch without "sys". Added file: http://bugs.python.org/file12061/distutils_register_2.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4354> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4521] "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb"
New submission from Hagen Fürstenau <[EMAIL PROTECTED]>: Patch is attached. -- assignee: georg.brandl components: Documentation files: whatsnew.patch keywords: patch messages: 76877 nosy: georg.brandl, hagen severity: normal status: open title: "What's New in Python 3.0" mentions "getcwdu" instead of "getcwdb" versions: Python 3.0, Python 3.1 Added file: http://bugs.python.org/file12215/whatsnew.patch ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue4521> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
Hagen Fürstenau <[EMAIL PROTECTED]> added the comment: I think a read buffer is not possible without being able to unread bytes from the stream. pickle shoudn't consume bytes after the end of a pickled object! ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination
New submission from Hagen Fürstenau: The following code will sometimes warn about an ignored TypeError('catching classes that do not inherit from BaseException is not allowed',) on termination: class MyException(Exception): pass def gen(): try: yield except MyException: pass g = gen() next(g) Of course, MyException inherits from Exception, so there should be no problem. Apparently, MyException gets destroyed before the generator object (at least sometimes, presumably depending on the hash randomization seed), and the destructor of the generator object then complains because there is no MyException any more. At least that's my explanation of this, without having digged into the code. -- components: Interpreter Core messages: 190365 nosy: hagen priority: normal severity: normal status: open title: except-clause with own exception class inside generator can lead to confusing warning on termination type: behavior versions: Python 3.3 ___ Python tracker <http://bugs.python.org/issue18102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18102] except-clause with own exception class inside generator can lead to confusing warning on termination
Hagen Fürstenau added the comment: s/digged/dug/ :-) -- ___ Python tracker <http://bugs.python.org/issue18102> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
New submission from Hagen Fürstenau : As reported by Dmitry Vasiliev on python-dev, a range object suddenly becomes hash()able after an attribute access, e.g. by dir(). If I understand correctly, then the reason is that PyRange_Type doesn't set tp_hash and PyType_Ready is not normally called on the type, but only e.g. in PyObject_GenericGetAttr. I don't see any use for range objects being hashable, as they don't even have meaningful equality defined on them. So I'd recommend making them unhashable. The attached patch does this and adds a test. -- components: Interpreter Core messages: 78059 nosy: hagen severity: normal status: open title: range objects becomes hashable after attribute access type: behavior versions: Python 3.0, Python 3.1 ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Changes by Hagen Fürstenau : -- keywords: +patch Added file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Hagen Fürstenau added the comment: Why does every other place seem to do the cast? Historical reasons? ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Hagen Fürstenau added the comment: I'm talking about places like these: [hag...@chage py3k]$ grep -R "(hashfunc)PyObject_HashNotImplemented" Objects/*.c Modules/*.c Objects/dictobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Objects/listobject.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Objects/setobject.c:(hashfunc)PyObject_HashNotImplemented, /* tp_hash */ Modules/_collectionsmodule.c: (hashfunc)PyObject_HashNotImplemented, /* tp_hash */ ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Hagen Fürstenau added the comment: Here's an updated patch without the cast and a separate patch for removing the other casts. Added file: http://bugs.python.org/file12401/rangehash2.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Changes by Hagen Fürstenau : Added file: http://bugs.python.org/file12402/remove_casts.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Changes by Hagen Fürstenau : Added file: http://bugs.python.org/file12403/rangehash3.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file12401/rangehash2.patch ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4701] range objects becomes hashable after attribute access
Hagen Fürstenau added the comment: > I don't believe there is any driving reason for them not to be hashable. On the other hand, what is the use case for hashing objects whose equality is defined as object identity? Python 3.0 (r30:67503, Dec 4 2008, 06:47:38) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> range(10).__hash__ >>> {range(10), range(10)} {range(0, 10), range(0, 10)} I can see only confusion arising from that. ___ Python tracker <http://bugs.python.org/issue4701> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
New submission from Hagen Fürstenau : If we call some function f with a generator as star argument and this generator raises a TypeError, we get the following exception: >>> def f(x): pass ... >>> def broken(): raise TypeError ... >>> f(*(broken() for x in (0,))) Traceback (most recent call last): File "", line 1, in TypeError: f() argument after * must be a sequence, not generator This is a misleading error message, as it's usually no problem to use a generator as a star argument. Even just replacing the TypeError by some other exception leads to the expected result, i.e. the exception gets correctly propagated. The problem seems to be around line 3710 of Python/ceval.c where the generator is converted to a tuple. If this conversion raises a TypeError, then the error message is replaced, which will mask any TypeError raised by the generator. I'm not sure how to solve this. We probably can't distinguish a "good" TypeError from a "bad" TypeError at this point, so we might have to make a special case for the conversion of generators. -- components: Interpreter Core messages: 78788 nosy: hagen severity: normal status: open title: Function calls taking a generator as star argument can mask TypeErrors in the generator type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4806] Function calls taking a generator as star argument can mask TypeErrors in the generator
Hagen Fürstenau added the comment: I'm getting confused about whether it's actually desired behaviour that generators can be star arguments. The error message seems to say it's not: "argument after * must be a sequence". The docs seem to agree: "If the syntax *expression appears in the function call, expression must evaluate to a sequence." However test_extcall specifically tests function calls with (non-sequence) iterables as star arguments. ___ Python tracker <http://bugs.python.org/issue4806> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3745] _sha256 et al. encode to UTF-8 by default
Hagen Fürstenau added the comment: Seems that this problem is being taken care of in issue #4751. ___ Python tracker <http://bugs.python.org/issue3745> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
Hagen Fürstenau added the comment: With the io-c branch I see much better unpickling performance than before. But it still seems to be around 2 or 3 times slower than with cPickle in 2.6. Is this expected at this point of io-c development? Otherwise perhaps this issue should stay open until it can be verified that nothing else can be done to get closer to the old cPickle performance. ___ Python tracker <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
Changes by Hagen Fürstenau : Removed file: http://bugs.python.org/file11497/pickletst.py ___ Python tracker <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3873] Unpickling is really slow
Hagen Fürstenau added the comment: I uploaded a new pickletst.py which specifies protocol 2, otherwise we're comparing apples with oranges. With this I get: 0.211881160736 0.322369813919 for Python 2.6 and 0.158488035202 1.21621990204 on the io-c branch. Can you confirm this? Added file: http://bugs.python.org/file12785/pickletst.py ___ Python tracker <http://bugs.python.org/issue3873> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5182] str() on memoryview of bytearray failing on py3k
Changes by Hagen Fürstenau : -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue5182> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5137] SystemError when __len__ returns a non-number
Hagen Fürstenau added the comment: This also solves issue 3729. -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue5137> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5198] Strange DeprecationWarning behaviour in module struct
New submission from Hagen Fürstenau : struct.pack seems to raise a DeprecationWarning for some structure formats, but not for others: Python 2.6.1 (r261:67515, Dec 5 2008, 07:40:41) [GCC 4.3.2] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import struct >>> struct.pack(">H", 1.0) sys:1: DeprecationWarning: integer argument expected, got float '\x00\x01' >>> struct.pack("H", 1.0) '\x01\x00' In addition the DeprecationWarning message gives a strange location for the problem. With the attached struct_warning.py it locates the problem at the function call foo() instead of the problematic call of struct.pack: $ python2.6 struct_warning.py struct_warning.py:6: DeprecationWarning: integer argument expected, got float foo() -- components: Library (Lib) files: struct_warning.py messages: 81532 nosy: hagen severity: normal status: open title: Strange DeprecationWarning behaviour in module struct type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file13007/struct_warning.py ___ Python tracker <http://bugs.python.org/issue5198> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5242] eval() function in List Comprehension doesn't work
Hagen Fürstenau added the comment: I can't reproduce this. For me it works as expected. -- nosy: +hagen ___ Python tracker <http://bugs.python.org/issue5242> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5330] profile and cProfile do not report C functions called with keyword arguments
New submission from Hagen Fürstenau : A C function or method call without keyword arguments gets reported by the profiler as expected (in the line with "{method 'sort' of 'list' object}"): >>> cProfile.run("[].sort()") 4 function calls in 0.000 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.0000.0000.000 :1() 10.0000.0000.0000.000 {built-in method exec} 10.0000.0000.0000.000 {method 'disable' of '_lsprof.Profiler' objects} 10.0000.0000.0000.000 {method 'sort' of 'list' objects} However, once a keyword argument is given, the relevant line is missing: >>> cProfile.run("[].sort(reverse=True)") 3 function calls in 0.000 CPU seconds Ordered by: standard name ncalls tottime percall cumtime percall filename:lineno(function) 10.0000.0000.0000.000 :1() 10.0000.0000.0000.000 {built-in method exec} 10.0000.0000.0000.000 {method 'disable' of '_lsprof.Profiler' objects} This happens with profile and cProfile in 2.6 and 3.0. -- components: Library (Lib) messages: 82530 nosy: hagen severity: normal status: open title: profile and cProfile do not report C functions called with keyword arguments type: behavior versions: Python 2.6, Python 3.0 ___ Python tracker <http://bugs.python.org/issue5330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5330] profile and cProfile do not report C functions called with keyword arguments
Hagen Fürstenau added the comment: I found the reason for this problem: C function calls with keyword arguments follow a different path than those without keywords in the function "call_function" of ceval.c. They end up being handled by "do_call", but there the call is not wrapped by C_TRACE, so a profiler function registered through sys.setprofile() doesn't see such calls. The same problem occurs in "ext_do_call", which gets called in the handling of the opcodes CALL_FUNCTION_VAR and CALL_FUNCTION_KW, causing omission of a function call like >>> [].sort(**{'reverse':True}) from the profiler report. The attached patch solves the problem, but I don't know if it's the best solution. Handling calls with keyword arguments at the beginning of "call_function" seems to have bigger performance drawbacks though. -- keywords: +patch Added file: http://bugs.python.org/file13146/ceval.patch ___ Python tracker <http://bugs.python.org/issue5330> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5425] 2to3 wrong for types.StringTypes
New submission from Hagen Fürstenau : In Python 2.6 we have >>> types.StringTypes (, ) but 2to3 translates "types.StringTypes" into "str", which is obviously wrong. The attached patch changes it into "(str, bytes)". -- components: 2to3 (2.x to 3.0 conversion tool) files: 2to3_StringTypes.patch keywords: patch messages: 83198 nosy: hagen severity: normal status: open title: 2to3 wrong for types.StringTypes type: behavior versions: Python 2.6, Python 3.0 Added file: http://bugs.python.org/file13248/2to3_StringTypes.patch ___ Python tracker <http://bugs.python.org/issue5425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5425] 2to3 wrong for types.StringTypes
Hagen Fürstenau added the comment: Why I considered the existing translation incorrect was because it translates something which was a tuple of types in Python 2.x into a type of Python 3.x. I fail to see how this can be useful. (A check like "x in types.StringTypes" gets translated into "x in str", which will always fail.) I agree that translating into "(str, bytes)" won't always be correct, but it seems to have a much better chance of being correct than the existing translation into "str". Otherwise it should at least be "(str,)". ___ Python tracker <http://bugs.python.org/issue5425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue5425] 2to3 wrong for types.StringTypes
Hagen Fürstenau added the comment: I can see the merit of not including "bytes" in StringTypes, but then the translation of StringType should be changed accordingly. How about changing the present StringType -> bytes StringTypes -> str into StringType -> str StringTypes -> (str,) ___ Python tracker <http://bugs.python.org/issue5425> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com