A RetroSearch Logo

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Search Query:

Showing content from https://mail.python.org/pipermail/python-dev/2008-August/081825.html below:

[Python-Dev] eval() accepts compiled 'exec' statements

[Python-Dev] eval() accepts compiled 'exec' statementsPatrick Maupin pmaupin at gmail.com
Sat Aug 16 18:05:12 CEST 2008
This may or may not be relevant to 2.6 or 3.0 (because I don't have
those handy at the moment), but on 2.5 and earlier:

Python 2.5.2 (r252:60911, May  7 2008, 15:19:09)
[GCC 4.2.3 (Ubuntu 4.2.3-2ubuntu7)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> print eval(compile('print "It works"\n', '', 'exec'))
It works
None
>>>

Personally, I'm absolutely fine with this (because I have a use case,
naturally), but eval() does work differently for compiled vs
non-compiled objects, and this behavior doesn't match what the doc at
http://docs.python.org/lib/built-in-funcs.html says, namely "This
function can also be used to execute arbitrary code objects (such as
those created by compile()). In this case pass a code object instead
of a string. The code object must have been compiled passing 'eval' as
the kind argument."

That doc statement is, itself, contradictory.  How can it be an
"arbitrary code object" if it must have been compiled using 'eval'?
Perhaps all that is meant is "In order to return a result other than
None to eval's caller,  the code object must have been compiled
passing 'eval' as the kind argument."

So, either the code or the doc should be fixed.  I would vote +1 for
fixing the doc to match the code, but then I'm the sort of
dysfunctional programmer who sometimes has a use-case for expressions
with side-effects.

Thanks,
Pat
More information about the Python-Dev mailing list

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4