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
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
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
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
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
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
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
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
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
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
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
Changes by Hagen Fürstenau hfuerste...@gmx.net:
--
nosy: +hagen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue9561
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
Changes by Hagen Fürstenau hfuerste...@gmx.net:
--
nosy: +hagen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue2698
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Hagen Fürstenau hfuerste...@gmx.net:
--
nosy: +hagen
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue5182
___
___
Python-bugs-list
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Changes by Hagen Fürstenau [EMAIL PROTECTED]:
--
nosy: +hagen
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue2723
___
___
Python-bugs-list mailing list
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
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
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
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
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
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
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
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
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
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
97 matches
Mail list logo
