[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 17:48
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Feature Requests-1152248 ] Enhance file.readlines by making line separator selectable
Feature Requests item #1152248, was opened at 2005-02-26 07:24 Message generated for change (Comment added) made by nessus42 You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nick Coghlan (ncoghlan) Assigned to: Nobody/Anonymous (nobody) Summary: Enhance file.readlines by making line separator selectable Initial Comment: There is no canonical way to iterate through a file on chunks *other* than whole lines without reading the whole file into memory. Allowing the separator to be specified as an argument to file.readlines and file.xreadlines would greatly simplify the task. See here for an example interface of the useful options: http://mail.python.org/pipermail/python-list/2005-February/268482.html -- Comment By: Douglas Alan (nessus42) Date: 2005-02-28 18:57 Message: Logged In: YES user_id=401880 In reply to birkenfeld, I'm not sure why you don't want to call lines separated with an alternate line-separation string "lines", but if you want to call them something else, I should think they should be called "records" rather than "chunks". |>oug -- Comment By: Reinhold Birkenfeld (birkenfeld) Date: 2005-02-26 07:38 Message: Logged In: YES user_id=1188172 I don't know whether (x)readlines is the right place, since you are _not_ operating on lines. What about (x)readchunks? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1152248&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153769 ] String interpolation needs PEP 237 update
Bugs item #1153769, was opened at 2005-02-28 20:37 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153769&group_id=5470 Category: Documentation Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Richard Brodie (leogah) Assigned to: Nobody/Anonymous (nobody) Summary: String interpolation needs PEP 237 update Initial Comment: String interpolation in libstdtypes.tex doesn't yet document PEP 237 (integer unification) changes. Specifically that: %u %x %X and %o now do signed conversions and that %u is obsolescent. Also, I can't parse the sentence beginning "The length modifier" -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153769&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153163 ] reflected operator not used when operands have the same type
Bugs item #1153163, was opened at 2005-02-27 20:09
Message generated for change (Comment added) made by hughsw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type
Initial Comment:
The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.
The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion. Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."
This code demonstrates the correct behavior and then
the problem:
class A(object):
def __radd__(self, other):
return '__radd__', other
print None + A()
print A() + A()
giving
('__radd__', None)
Traceback (most recent call last):
File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'
I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A. In all
these cases the __radd__ operator is used as
documented. I've only seen the problem when the two
operands are of the same type.
This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.
This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.
--
>Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 23:36
Message:
Logged In: YES
user_id=1146279
The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c. In two places it ensures that the reflected
(reversed, swapped, rop, you name it) operator won't
be called if the two operands are of the same type.
Removing these two exclusions fixes the problem.
However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?). And,
elsewhere, I saw high-level code that had a similar check on
operands having the same type with a comment that talked
about avoiding an infinite loop that could happen if there's
coercion and other subtly involved
FWIW, with the changes I made, 256 tests are OK and 35 tests
are skipped -- as is usual on my Linux system.
I can post a trivial patch and figure out how to add a
regression test, but expert analysis is needed.
Also, the code in this macro (and perhaps helped by
abstract.c) implements curious and
not-documented-on-the-Emulating-numeric-types-page
semantics: if the operand on the right is a subtype of the
operand on the left and if the right operand overloads the
reflected operator, then the reflected operator will be
called, even if the left-hand operand implements the regular
operator! This is either a bug or it should be documented,
preferably with some rationale. E.g.
class A(object):
def __add__(self, other):
return 'A.__add__', other
class B(A):
def __radd__(self, other):
return 'B.__radd__', other
>>> B()+A()
('A.__add__', <__main__.A object at 0x00B65A30>)
>>> B()+B()
('A.__add__', <__main__.B object at 0x00B836F0>)
>>> 1+B()
('B.__radd__', 1)
>>> A()+B()
('B.__radd__', <__main__.A object at 0x00B65A30>)
Where the last one is what's curious or a bug.
-Hugh
--
Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 01:09
Message:
Logged In: YES
user_id=1146279
I've looked into this a little. Newbie that I am, I don't
know where the
x = slotw(v, w);
call goes (in binary_op1() in abstract.c near line 377)
AFAICT, this code in abstract.c behaves reasonably, so
problem would seem to be in the tp_as_number slot-function
that's getting called. And whereever that is, it's not the
binary-op functions in classobject.c that I thought it would
be
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailma
[ python-Bugs-1153163 ] reflected operator not used when operands have the same type
Bugs item #1153163, was opened at 2005-02-27 20:09
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153163&group_id=5470
Category: Python Interpreter Core
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Hugh Secker-Walker (hughsw)
Assigned to: Nobody/Anonymous (nobody)
Summary: reflected operator not used when operands have the same type
Initial Comment:
The reflected operators, e.g. __radd__, are used when
the left operand does not have the non-reflected
operator, *unless* the right operand is of the same type.
The documentation on the "Emulating numeric types" page
doesn't mention this peculiar exclusion. Of the
reflected operators it says:
"These methods are called to implement the binary
arithmetic operations (+, -, *, /, %, divmod(), pow(),
**, <<, >>, &, ^, |) with reflected (swapped) operands.
These functions are only called if the left operand
does not support the corresponding operation. For
instance, to evaluate the expression x-y, where y is an
instance of a class that has an __rsub__() method,
y.__rsub__(x) is called."
This code demonstrates the correct behavior and then
the problem:
class A(object):
def __radd__(self, other):
return '__radd__', other
print None + A()
print A() + A()
giving
('__radd__', None)
Traceback (most recent call last):
File "C:/Temp/reflectedbug.py", line 6, in -toplevel-
print A() + A()
TypeError: unsupported operand type(s) for +: 'A' and 'A'
I've replaced None in the first print statement with
many kinds of builtin objects, instances of other
classes, and with instances of subclasses of A. In all
these cases the __radd__ operator is used as
documented. I've only seen the problem when the two
operands are of the same type.
This problem also occurs during the backing-off to
plain operators that occurs when augmented operators,
e.g. __iadd__, aren't implemented by the type and the
operands are of the same type.
This problem is present in 2.4 on Linux and Windows,
and in the current CVS version (2.5a0, 27-Feb-05) on Linux.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:08
Message:
Logged In: YES
user_id=593130
I believe Python's designer(s) intend that if A()+A() is valid, then
A will have an __add__ method. __rxxx__ is only intended for
backup use with mixed types. So your example sends a mixed
message to the interpreter.
If the current behavior is both intended and still necessary, the
manual sentence
"These functions are only called if the left operand
does not support the corresponding operation"
could be augmented with
"and has a different type than the right operand"
--
Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 23:36
Message:
Logged In: YES
user_id=1146279
The problem is in the SLOT1BINFULL() macro near line 4020 in
typeobject.c. In two places it ensures that the reflected
(reversed, swapped, rop, you name it) operator won't
be called if the two operands are of the same type.
Removing these two exclusions fixes the problem.
However, this being my third day ever modifying Python
source code, for all intents and purposes, I have no idea
why the exclusions were there (efficiency?). And,
elsewhere, I saw high-level code that had a similar check on
operands having the same type with a comment that talked
about avoiding an infinite loop that could happen if there's
coercion and other subtly involved
FWIW, with the changes I made, 256 tests are OK and 35 tests
are skipped -- as is usual on my Linux system.
I can post a trivial patch and figure out how to add a
regression test, but expert analysis is needed.
Also, the code in this macro (and perhaps helped by
abstract.c) implements curious and
not-documented-on-the-Emulating-numeric-types-page
semantics: if the operand on the right is a subtype of the
operand on the left and if the right operand overloads the
reflected operator, then the reflected operator will be
called, even if the left-hand operand implements the regular
operator! This is either a bug or it should be documented,
preferably with some rationale. E.g.
class A(object):
def __add__(self, other):
return 'A.__add__', other
class B(A):
def __radd__(self, other):
return 'B.__radd__', other
>>> B()+A()
('A.__add__', <__main__.A object at 0x00B65A30>)
>>> B()+B()
('A.__add__', <__main__.B object at 0x00B836F0>)
>>> 1+B()
('B.__radd__', 1)
>>> A()+B()
('B.__radd__', <__main__.A object at 0x00B65A30>)
Where the last one is what's curious or a bug.
-Hugh
--
Comment By: Hugh Secker-Walker (hughsw)
Date: 2005-02-28 01:09
Message:
Logged In: YES
user_id=1146279
I've looked into this a little. Newbie that I am
[ python-Bugs-1153622 ] eval does not bind variables in lambda bodies correctly
Bugs item #1153622, was opened at 2005-02-28 11:48
Message generated for change (Comment added) made by tjreedy
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
Category: Parser/Compiler
Group: Python 2.4
Status: Open
Resolution: None
Priority: 5
Submitted By: Mattias Engdegård (yorick)
Assigned to: Nobody/Anonymous (nobody)
Summary: eval does not bind variables in lambda bodies correctly
Initial Comment:
eval() does not bind variables in lambda expressions
correctly:
>>>def f(g): return eval('lambda x: g(x)')
>>>f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in
NameError: global name 'g' is not defined
The docs say this about eval():
# If both dictionaries are omitted, the expression is
# executed in the environment where eval is called.
and using plain local variables work as expected:
>>>def h(d): return eval('d(10)')
>>>h(lambda y: y * 2)
20
Also, if locals() is presented as the global dict to
eval(), it works:
>>>def f(g): return eval('lambda x: g(x)', locals(),
locals())
>>>f(lambda y: y * 2)(17)
34
but this does not allow the expression to reference
global variables of course.
--
Comment By: Terry J. Reedy (tjreedy)
Date: 2005-03-01 00:30
Message:
Logged In: YES
user_id=593130
I am 99.5% sure that this is 'invalid' (a Resolution category) and
should be closed. With the default environment, eval('x') is the
same as unquoted x. Variables in Python functions are resolved
when the function is *called*, not when it is defined. There is no
resolution for g in the default globals. Eval does not change this.
The NameError is exactly correct.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153622&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153226 ] string interpolation breaks with %d and large float
Bugs item #1153226, was opened at 2005-02-27 21:10 Message generated for change (Comment added) made by josiahcarlson You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Stephen Thorne (jerub) Assigned to: Nobody/Anonymous (nobody) Summary: string interpolation breaks with %d and large float Initial Comment: We have experienced a problem recently when wanting to render a large float as a string. Converting the float to an int/long manuall was required. '%d' % f throws an exception for all floats f, f >= 2**31 Expected output, shown with 'int()' and 'long()': >>> '%d %d' % (long(float(2**31)), int(float(2**31))) '2147483648 2147483648' Non-Working Example. >>> '%d' % float(2**31) Traceback (most recent call last): File "", line 1, in ? TypeError: int argument required Tested on: Python 2.3.4 (#1, Oct 26 2004, 16:42:40) Python 2.4.1a0 (#2, Feb 9 2005, 22:42:24) -- Comment By: Josiah Carlson (josiahcarlson) Date: 2005-02-28 22:36 Message: Logged In: YES user_id=341410 Note that it will also raise a TypeError when the float f, f < -2**31 Is this a bug? I don't know. I tend to not pass floats when string interpolation is expecting integers. Maybe the documentation should be cleared up. If you really want a truncated float, perhaps "%.0f" is the format you are looking for, to save you the effort of using int() or long(). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153226&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
