[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 rep...@bugs.python.org
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 rep...@bugs.python.org http://bugs.python.org/issue18102 ___ ___ 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 ha...@zhuliguan.net 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 string:1(module)
10.0000.0000.0000.000
profile:0(itertools.permutations(range(10), 3))
00.000 0.000 profile:0(profiler)
--
___
Python tracker rep...@bugs.python.org
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
New submission from Hagen Fürstenau ha...@zhuliguan.net: 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 rep...@bugs.python.org http://bugs.python.org/issue12953 ___ ___ 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 ha...@zhuliguan.net:
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 module
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 rep...@bugs.python.org
http://bugs.python.org/issue12087
___
___
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 ha...@zhuliguan.net: 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 rep...@bugs.python.org http://bugs.python.org/issue10640 ___ ___ 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 ha...@zhuliguan.net: 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 rep...@bugs.python.org 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 ha...@zhuliguan.net added the comment: Created issue 10419 for the encoding problem in build_scripts. -- ___ Python tracker rep...@bugs.python.org 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
Hagen Fürstenau ha...@zhuliguan.net added the comment: The ReST links in http://docs.python.org/py3k/c-api/dict.html#PyDict_Items seem to be broken. -- ___ Python tracker rep...@bugs.python.org 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
New submission from Hagen Fürstenau ha...@zhuliguan.net: 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 rep...@bugs.python.org http://bugs.python.org/issue10300 ___ ___ 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 hfuerste...@gmx.net added the comment: Why does this matter? PEP 3120 specifies UTF-8 as the default source encoding. -- ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue9561 ___ ___ 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue9887 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net added the comment: Attaching a combined patch against the current py3k. -- Added file: http://bugs.python.org/file18404/combined.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue8785 ___ ___ 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
Hagen Fürstenau hfuerste...@gmx.net added the comment: Apparently this was never backported to 3.1. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6352 ___ ___ 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: -- keywords: +patch Added file: http://bugs.python.org/file14842/bytearray.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue6847 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org 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 hfuerste...@gmx.net added the comment: Seems to have been fixed around r73896. -- ___ Python tracker rep...@bugs.python.org 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
Changes by Hagen Fürstenau hfuerste...@gmx.net: -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue2698 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net added the comment: Seems like this has already been fixed as issue 1385. -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue6473 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: I think the following error messages are inconsistent and confusing: def f(a, b): pass ... f(a=1) Traceback (most recent call last): File stdin, line 1, in module TypeError: f() takes exactly 2 non-keyword positional arguments (1 given) f(b=1) Traceback (most recent call last): File stdin, line 1, in module 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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
New submission from Hagen Fürstenau hfuerste...@gmx.net: 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org http://bugs.python.org/issue6364 ___ ___ 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue6352 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org http://bugs.python.org/issue6288 ___ ___ 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue6256 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org http://bugs.python.org/issue6137 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: Removed file: http://bugs.python.org/file14166/TypeError.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ 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 hfuerste...@gmx.net:
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 rep...@bugs.python.org
http://bugs.python.org/issue6150
___
___
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 hfuerste...@gmx.net:
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 stdin, line 1, in module
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 rep...@bugs.python.org
http://bugs.python.org/issue6038
___
___
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 hfuerste...@gmx.net added the comment: The automatic conversion can't be perfect in all cases, but I think my second suggestion is more in line with the other transformations done by 2to3 (string literals, str, basestring etc.). I propose applying the second patch, but don't care enough to argue for it much more if it's rejected. -- message_count: 7.0 - 8.0 status: closed - open Added file: http://bugs.python.org/file13265/2to3_StringTypes_2.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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
New submission from Hagen Fürstenau hfuerste...@gmx.net: In Python 2.6 we have types.StringTypes (type 'str', type 'unicode') 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org http://bugs.python.org/issue5425 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org
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
New submission from Hagen Fürstenau hfuerste...@gmx.net:
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 string:1(module)
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 string:1(module)
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 rep...@bugs.python.org
http://bugs.python.org/issue5330
___
___
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 hfuerste...@gmx.net added the comment: I can't reproduce this. For me it works as expected. -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5242 ___ ___ 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 hfuerste...@gmx.net added the comment: This also solves issue 3729. -- nosy: +hagen ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: 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 rep...@bugs.python.org http://bugs.python.org/issue5198 ___ ___ 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 hfuerste...@gmx.net: -- nosy: +hagen ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue5182 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: Removed file: http://bugs.python.org/file11497/pickletst.py ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org http://bugs.python.org/issue3873 ___ ___ 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 hfuerste...@gmx.net added the comment: Seems that this problem is being taken care of in issue #4751. ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue3745 ___ ___ 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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
New submission from Hagen Fürstenau hfuerste...@gmx.net: 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 stdin, line 1, in module 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 rep...@bugs.python.org http://bugs.python.org/issue4806 ___ ___ 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 hfuerste...@gmx.net 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__
method-wrapper '__hash__' of range object at 0x7f2d61dbd210
{range(10), range(10)}
{range(0, 10), range(0, 10)}
I can see only confusion arising from that.
___
Python tracker rep...@bugs.python.org
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
New submission from Hagen Fürstenau hfuerste...@gmx.net: 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: -- keywords: +patch Added file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net added the comment: Why does every other place seem to do the cast? Historical reasons? ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net 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 rep...@bugs.python.org 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 hfuerste...@gmx.net: Added file: http://bugs.python.org/file12402/remove_casts.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: Removed file: http://bugs.python.org/file12400/rangehash.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: Added file: http://bugs.python.org/file12403/rangehash3.patch ___ Python tracker rep...@bugs.python.org 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 hfuerste...@gmx.net: Removed file: http://bugs.python.org/file12401/rangehash2.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue4701 ___ ___ 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
[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
[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 module import py3setup File /home/MP/hagenf/src/pyskein/py3setup.py, line 22, in module 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
[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
[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
[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
[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
[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 stdin, line 1, in module 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
[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
[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
[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
[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 stdin, line 1, in module 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
[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
[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
[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
[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 stdin, line 1, in module 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 stdin, line 1, in module 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
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 stdin, line 1, in module
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
[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
