Hagen Fürstenau added the comment:
s/digged/dug/ :-)
--
___
Python tracker
<http://bugs.python.org/issue18102>
___
___
Python-bugs-list mailing list
Unsubscribe:
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 M
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 percal
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
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
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.
--
compon
Hagen Fürstenau added the comment:
Created issue 10419 for the encoding problem in "build_scripts".
--
___
Python tracker
<http://bugs.python.
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.
Reprodu
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/issue10
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
Changes by Hagen Fürstenau :
--
nosy: +hagen
___
Python tracker
<http://bugs.python.org/issue9561>
___
___
Python-bugs-list mailing list
Unsubscribe:
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/issue9
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
componen
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/issue4
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
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
Hagen Fürstenau added the comment:
Apparently this was never backported to 3.1.
--
___
Python tracker
<http://bugs.python.org/issue6352>
___
___
Python-bug
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:
Changes by Hagen Fürstenau :
--
keywords: +patch
Added file: http://bugs.python.org/file14842/bytearray.patch
___
Python tracker
<http://bugs.python.org/issue6
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
s
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.py
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 (
Hagen Fürstenau added the comment:
Seems to have been fixed around r73896.
--
___
Python tracker
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list m
Changes by Hagen Fürstenau :
--
nosy: +hagen
___
Python tracker
<http://bugs.python.org/issue2698>
___
___
Python-bugs-list mailing list
Unsubscribe:
Hagen Fürstenau added the comment:
Seems like this has already been fixed as issue 1385.
--
nosy: +hagen
___
Python tracker
<http://bugs.python.org/issue6
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.or
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/file145
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 a
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
<h
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
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 _tki
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 wa
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
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 ye
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
re
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: pendi
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.
Changes by Hagen Fürstenau :
Removed file: http://bugs.python.org/file14166/TypeError.patch
___
Python tracker
<http://bugs.python.org/issue4806>
___
___
Python-bug
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
___
Pyth
Changes by Hagen Fürstenau :
Added file: http://bugs.python.org/file14167/message_and_docs.patch
___
Python tracker
<http://bugs.python.org/issue4806>
___
___
Python-bug
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 "mus
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(&#x
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 stran
Hagen Fürstenau 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,
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
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
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:
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 no
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 i
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/i
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"
Hagen Fürstenau added the comment:
This also solves issue 3729.
--
nosy: +hagen
___
Python tracker
<http://bugs.python.org/issue5137>
___
___
Python-bugs-list m
Changes by Hagen Fürstenau :
--
nosy: +hagen
___
Python tracker
<http://bugs.python.org/issue5182>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
Changes by Hagen Fürstenau :
Removed file: http://bugs.python.org/file11497/pickletst.py
___
Python tracker
<http://bugs.python.org/issue3873>
___
___
Python-bugs-list m
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
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-bug
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 syn
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,)))
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 lin
Changes by Hagen Fürstenau :
Removed file: http://bugs.python.org/file12401/rangehash2.patch
___
Python tracker
<http://bugs.python.org/issue4701>
___
___
Python-bug
Changes by Hagen Fürstenau :
Added file: http://bugs.python.org/file12403/rangehash3.patch
___
Python tracker
<http://bugs.python.org/issue4701>
___
___
Python-bugs-list m
Changes by Hagen Fürstenau :
Removed file: http://bugs.python.org/file12400/rangehash.patch
___
Python tracker
<http://bugs.python.org/issue4701>
___
___
Python-bug
Changes by Hagen Fürstenau :
Added file: http://bugs.python.org/file12402/remove_casts.patch
___
Python tracker
<http://bugs.python.org/issue4701>
___
___
Python-bug
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/i
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
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>
___
___
Pytho
Changes by Hagen Fürstenau :
--
keywords: +patch
Added file: http://bugs.python.org/file12400/rangehash.patch
___
Python tracker
<http://bugs.python.org/issue4
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 call
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 PRO
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 Pyth
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://
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,
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
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 tr
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/py
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.b
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&q
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 2007092
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 i
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.
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 "
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
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
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?
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11308/len_check2.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>:
Removed file: http://bugs.python.org/file11307/len_check.diff
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.pytho
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:/
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 buffe
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 &
Changes by Hagen Fürstenau <[EMAIL PROTECTED]>:
--
nosy: +hagen
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue2723>
___
___
Python
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
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
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 argum
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://bu
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
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
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", "cop
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&#
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 indic
1 - 100 of 101 matches
Mail list logo
