[ 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 (Comment added) made by yorick
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: Mattias Engdegård (yorick)
Date: 2005-03-02 17:42
Message:
Logged In: YES
user_id=432579
No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.
--
Comment By: Branko (bbange)
Date: 2005-03-02 01:20
Message:
Logged In: YES
user_id=1230541
Obviously I forgot a statement in my previous comment's
code example. So here's the complete version:
n=2
def f(x): return n*x
del n
f(2)
# the Python implementation will result in a name error here.
But what should happen if Python had bound variable n at the
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your
expected implementation?
--
Comment By: Branko (bbange)
Date: 2005-03-02 01:15
Message:
Logged In: YES
user_id=1230541
I think this issue is not special for eval and can be also
reproduced with a def statement. The point is that at function
definition time Python does not do any variable binding
concerning variables not local to the function. Instead Python
looks for that variable in the namespace of the module in
which the function was created at the time the function is
executed. Python determines that module by evaluating the
variable __module__ at function definition time and
remembers it by setting the function attribute with the same
name. That's why only the variable __module__ is relevant at
function definition time. Simply put, Python does only do a
module level variable binding at function definition time. This
is simple and sensible. If you don't agree consider this:
n=2
def f(x): return n*x
del n
f(2)
# the Python implementation will result in a name error here.
But what should happen if Python had bound variable n at the
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your
expected implementation?
As you see, changing the implementation would either make
Pythons semantics more complicated or would remove much
of Pythons dynanism.
--
Comment By: Mattias Engdegård (yorick)
Date: 2005-03-01 19:26
Message:
Logged In: YES
user_id=432579
What you are saying is "it works that way because it is the
way it works". I see no reason at all for this odd behaviour
other than bug-compatibility. I find nothing at all in the
documentation supporting this behaviour either; please
inform me if I have missed something.
All other languages supporting eval and lexical scoping
(Lisp, Scheme, Perl, Ruby, etc) work in the expected way. I
have no problems if Python wants to be different for
whatever reason, but it should be documented.
I did a quick Google in comp.lang.python but could not find
anything that supported this "exception" or gave a rational
explanation. Kindly direct me to any resource you know of
that could help enlighten me on this issue.
># From your comments, I suspect you expect 0.
Of course not. I know very well how lexical scoping works,
so please don't put words in my mouth.
None of your examples have anything to do with scoping. As
we both know, it is not the _values_ of the variables that
is important for variable binding, it is their identity;
which variable is chosen, not what they happen to contain at
the time the lambda expression is evaluated.
--
Comment By: Ter
[ python-Bugs-1155207 ] getElementsbyTagName('*') in dom.minidom
Bugs item #1155207, was opened at 2005-03-02 16:55
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=1155207&group_id=5470
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: bugmenot (bugmenot)
Assigned to: Nobody/Anonymous (nobody)
Summary: getElementsbyTagName('*') in dom.minidom
Initial Comment:
According to the level 1 DOM, getElementsByTagName('*')
on an element node should return all descendants of the
element from which the method is called that are
element nodes.
When i tried it however, the returned nodeList
contained all elements that appear after the original
element in the soruce, regardless of whether or not
they are descendants.
Python 2.4 for windows
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by arigo You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. -- Comment By: Michael Hudson (mwh) Date: 2005-03-01 20:18 Message: Logged In: YES user_id=6656 I wonder if Guido owes Armin a beer (read typeobject.c around line 5230). Well, not really, but it's that code that is making the difference. However, reversing the order of dict and object is sufficient to make 2.2 crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting code chopped out which gives the error jelper observes on the original). I wonder what to do about this. Removing the ability to customize the mro from user code is one obvious approach -- I don't know how much code uses this feature though. -- Comment By: Jeff Epler (jepler) Date: 2005-03-01 19:15 Message: Logged In: YES user_id=2772 Not sure if this is relevant, but the example given didn't crash 2.2: $ python2.2 bug.py Traceback (most recent call last): File "bug.py", line 9, in ? x = X() TypeError: dict.__new__(X) is not safe, use object.__new__() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155207 ] getElementsbyTagName('*') in dom.minidom
Bugs item #1155207, was opened at 2005-03-02 16:55
Message generated for change (Settings changed) made by bugmenot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470
Category: None
Group: None
>Status: Deleted
Resolution: None
Priority: 5
Submitted By: bugmenot (bugmenot)
Assigned to: Nobody/Anonymous (nobody)
Summary: getElementsbyTagName('*') in dom.minidom
Initial Comment:
According to the level 1 DOM, getElementsByTagName('*')
on an element node should return all descendants of the
element from which the method is called that are
element nodes.
When i tried it however, the returned nodeList
contained all elements that appear after the original
element in the soruce, regardless of whether or not
they are descendants.
Python 2.4 for windows
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155207&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1153075 ] PyXxx_Check(x) trusts x->ob_type->tp_mro
Bugs item #1153075, was opened at 2005-02-27 21:55 Message generated for change (Comment added) made by mwh You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Armin Rigo (arigo) Assigned to: Nobody/Anonymous (nobody) Summary: PyXxx_Check(x) trusts x->ob_type->tp_mro Initial Comment: The functions PyInt_Check(), PyString_Check(), PyList_Check() etc. are used all over the core to check which typecasts are safe, from PyObject* to the various PyXxxObject*. But the macros themselves are implemented by inspecting the "tp_mro" tuple of the incoming object's type. As the latter can be completely controlled by the user, an object can pretend to inherit from anything and pass the PyXxx_Check() checks of its choice, even if its memory layout is actually completely wrong. See attached example. -- >Comment By: Michael Hudson (mwh) Date: 2005-03-02 20:11 Message: Logged In: YES user_id=6656 Hmm, yeah, that works. It wasn't totally clear to me that the user couldn't maliciously influence tp_base, but I don't think they can... A helper function is presumably in order, unless PyType_IsSubtype should be changed. -- Comment By: Armin Rigo (arigo) Date: 2005-03-02 17:03 Message: Logged In: YES user_id=4771 To solve the problem, as hinted in the title of this tracker, I think that PyXxx_Check() should simply not trust any mro. What PyInt_Check() really means at the C level is to check if an object memory layout is compatible with PyIntObject. This is easy to figure out by walking the "solid base" chain, tp_base. As a side note, PyPy gives the same error as Python 2.2. However, both in PyPy and in Python 2.2, you can still build an instance of the strange class X as follows: >>> x = object.__new__(X) Still, all the methods of x are resolved via the dict type. In PyPy we get a clean TypeError because the methods thus found don't apply to non-dict objects. In Python 2.2 you can crash the interpreter just as in more recent Python releases, e.g. with x[5]=6. -- Comment By: Michael Hudson (mwh) Date: 2005-03-01 20:18 Message: Logged In: YES user_id=6656 I wonder if Guido owes Armin a beer (read typeobject.c around line 5230). Well, not really, but it's that code that is making the difference. However, reversing the order of dict and object is sufficient to make 2.2 crash (I presume, it crashes CVS HEAD with the __new__ short-circuiting code chopped out which gives the error jelper observes on the original). I wonder what to do about this. Removing the ability to customize the mro from user code is one obvious approach -- I don't know how much code uses this feature though. -- Comment By: Jeff Epler (jepler) Date: 2005-03-01 19:15 Message: Logged In: YES user_id=2772 Not sure if this is relevant, but the example given didn't crash 2.2: $ python2.2 bug.py Traceback (most recent call last): File "bug.py", line 9, in ? x = X() TypeError: dict.__new__(X) is not safe, use object.__new__() -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1153075&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155362 ] Bugs in parsedate_tz
Bugs item #1155362, was opened at 2005-03-02 21:03
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=1155362&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
Assigned to: Nobody/Anonymous (nobody)
Summary: Bugs in parsedate_tz
Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.
For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.
The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :
Index : _parseaddr.py
@@ -60,7 +66,11 @@ def parsedate_tz(data):
if i > 0:
data[3:] = [s[:i], s[i+1:]]
else:
-data.append('') # Dummy tz
+ i = s.find('-')
+ if i > 0:
+ data[3:] = [s[:i], s[i:]]
+ else:
+ data.append('') # Dummy tz
if len(data) < 5:
return None
data = data[:5]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155362 ] Bugs in parsedate_tz
Bugs item #1155362, was opened at 2005-03-02 16:03
Message generated for change (Settings changed) made by bwarsaw
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
Category: Python Library
Group: Python 2.3
Status: Open
Resolution: None
Priority: 5
Submitted By: TH (therve)
>Assigned to: Barry A. Warsaw (bwarsaw)
Summary: Bugs in parsedate_tz
Initial Comment:
The parsing in emails is incomplete in both rfc822.py
and _parseaddr.py.
For example, "Wed, 02 Mar 2005 09:26:53+0800" is parsed
but "Wed, 02 Mar 2005 09:26:53-0800" is not.
The problem is clear by watching the code : only "+"
timezones are corrected.
Following a patch :
Index : _parseaddr.py
@@ -60,7 +66,11 @@ def parsedate_tz(data):
if i > 0:
data[3:] = [s[:i], s[i+1:]]
else:
-data.append('') # Dummy tz
+ i = s.find('-')
+ if i > 0:
+ data[3:] = [s[:i], s[i:]]
+ else:
+ data.append('') # Dummy tz
if len(data) < 5:
return None
data = data[:5]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155362&group_id=5470
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ 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-02 17:59
Message:
Logged In: YES
user_id=593130
No, this issue is not specific to either eval or lambda:
>>> def f(g):
... exec 'def h(x): return g(x)'
... return h
...
>>> f(lambda y: y * 2)(17)
Traceback (most recent call last):
File "", line 1, in ?
File "", line 1, in h
NameError: global name 'g' is not defined
It is specific to creating a function at top-level in a separate
execution environment, as done, by design, by both eval and
exec, and with either a def statement or lambda abbreviation
thereof.
In Python, lexical scoping works because nested functions are
compiled along with the outer function, so that scoped variables
can be identified and both functions adjusted so that the coupling
works. In particular, the scoped variable has to not be deleted
when the outer function returns. Eval/exec compile their string
only later, when the function is called.
"it works that way because it is the way it works".
Those are your words, not mine. If you want Python to work
differently, write a PEP or a patch, or raise the question in the
newsgroup/mailing list. I'm done discussing it here.
--
Comment By: Mattias Engdegård (yorick)
Date: 2005-03-02 11:42
Message:
Logged In: YES
user_id=432579
No, this issue is specific to eval of lambda expressions.
Please read my problem description. Please refer to the
Python documentation if you are confused with how standard
function declaration or lexical scoping works.
--
Comment By: Branko (bbange)
Date: 2005-03-01 19:20
Message:
Logged In: YES
user_id=1230541
Obviously I forgot a statement in my previous comment's
code example. So here's the complete version:
n=2
def f(x): return n*x
del n
f(2)
# the Python implementation will result in a name error here.
But what should happen if Python had bound variable n at the
time of f's definitionf?
# let's define n again
n=3
f(2)
# the implementation will return 6, but how about your
expected implementation?
--
Comment By: Branko (bbange)
Date: 2005-03-01 19:15
Message:
Logged In: YES
user_id=1230541
I think this issue is not special for eval and can be also
reproduced with a def statement. The point is that at function
definition time Python does not do any variable binding
concerning variables not local to the function. Instead Python
looks for that variable in the namespace of the module in
which the function was created at the time the function is
executed. Python determines that module by evaluating the
variable __module__ at function definition time and
remembers it by setting the function attribute with the same
name. That's why only the variable __module__ is relevant at
function definition time. Simply put, Python does only do a
module level variable binding at function definition time. This
is simple and sensible. If you don't agree consider this:
n=2
def f(x): return n*x
del n
f(2)
# the Python implementation will result in a name error here.
But what should happen if Python had bound variable n at the
time of f's definitionf?
# let's define n again
f(2)
# the implementation will return 6, but how about your
expected implementation?
As you see, changing the implementation would either make
Pythons semantics more complicated or would remove much
of Pythons dynanism.
--
Comment By: Mattias Engdegård (yorick)
Date: 2005-03-01 13:26
Message:
Logged
[ python-Feature Requests-1155485 ] file() on a file
Feature Requests item #1155485, was opened at 2005-03-02 23:48 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 Category: Python Interpreter Core Group: None Status: Open Resolution: None Priority: 5 Submitted By: Felix Lee (felixlee) Assigned to: Nobody/Anonymous (nobody) Summary: file() on a file Initial Comment: it would be nice if file(f) worked when f is already a file, either by returning f or by constructing a new file that refers to the same thing. that would make it easy to write functions that can take either a file or a filename as an argument, like so: def p(f): print list(file(f)) which is kind of like using int() as a cast operation. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=355470&aid=1155485&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[ python-Bugs-1155638 ] self.length shield exception in httplib
Bugs item #1155638, was opened at 2005-03-03 07:22 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=1155638&group_id=5470 Category: Python Library Group: Python 2.4 Status: Open Resolution: None Priority: 5 Submitted By: Andrew P. Lentvorski, Jr. (bsder) Assigned to: Nobody/Anonymous (nobody) Summary: self.length shield exception in httplib Initial Comment: Under certain conditions (I'm trying to open a Shoutcast stream), I wind up with the following exception from httplib: Traceback (most recent call last): File "/home/devel/lib/python2.4/threading.py", line 442, in __bootstrap self.run() File "avalanche.py", line 86, in run streamData = streamResponse.read(256) File "/home/devel/lib/python2.4/httplib.py", line 478, in read self.length -= len(s) TypeError: unsupported operand type(s) for -=: 'str' and 'int' Normally, self.length has many shields of the form "if self.length is None:"; however, self.length gets initialize to _UNKNOWN which is the string "UNKNOWN" rather than None. As such, all of the shields are useless. Am I using a deprecated library or something? I'm really surprised no one else has bumped into this. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=105470&aid=1155638&group_id=5470 ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
