[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-16 Thread Jonathan Livni
New submission from Jonathan Livni : all( (x<=y) for x,y in zip(L, L[1:]) ) all([(x<=y) for x,y in zip(L, L[1:])]) Both lines of code above check if L is a non-decreasing list. Both should return the same results. But under some conditions, they don't. I've encountered thi

[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-16 Thread Jonathan Livni
Jonathan Livni added the comment: The exact list of decimals doesn't help - I tried taking the list and reproducing the bug with the following short script, but the problem did not reproduced: from decimal import Decimal L = [Decimal('6.700'), Decimal('6.800'),

[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-16 Thread Jonathan Livni
Jonathan Livni added the comment: Another note - the original problematic code looks like this: def non_decreasing(L): return all(x<=y for x, y in zip(L, L[1:])) Changing it to: def non_decreasing(L): def f(L): return [x<=y for x, y in zip(L, L[1:])] return a

[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-16 Thread Jonathan Livni
Jonathan Livni added the comment: The script I used is a single file single threaded code - but - It uses django's ORM to get the data from a MySQL database. I've reduced the code path to this: import sys,os sys.path.append(os.path.dirname(os.getcwdu())) os.environ['DJANGO_

[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-16 Thread Jonathan Livni
Jonathan Livni added the comment: from pylab import * There lies the rub? -- ___ Python tracker <http://bugs.python.org/issue11221> ___ ___ Python-bugs-list m

[issue11221] all() returns wrong result when the parameters are non-encapsulated list-comprehension

2011-02-17 Thread Jonathan Livni
Jonathan Livni added the comment: Let my foolishness be a reminder to all not to use "from [module] import *" After saying that - I believe overloading a built in Python function in a popular package\module is a mistake! I still don't know if pylab's all() is erroneou

[issue17080] A better error message for float()

2013-01-30 Thread Jonathan Livni
New submission from Jonathan Livni: These lines of Python (2.7): y = float(x) gives the error: TypeError: float() argument must be a string or a number. In various cases such as: x = [0] x = None x = SomeClass() In addition to the information given in the error message