'_[1]' in .co_names using builtin compile() in Python 2.6
When I run e.g. compile('sin(5) * cos(6)', '', 'eval').co_names, I get
('sin', 'cos'), which is just what I expected.
But when I have a list comprehension in the expression, I get a little surprise:
>>> compile('[x*x for x in y]', '', 'eval').co_names
('_[1]', 'y', 'x')
>>>
This happens in Python 2.6.6 on Red Hat Linux, but not when I run Python 2.7.3
in Windows. Unfortunately I'm stuck with 2.6.
* Are there more surprises similar to this one that I can expect from
compile(...).co_names? Is this "behaviour" documented somewhere?
* Is there perhaps a better way to achieve what I'm trying to do?
What I'm really after, is to check that python expressions embedded in text
files are:
- well behaved (no syntax errors etc)
- don't accidentally access anything it shouldn't
- I serve them with the values they need on execution
So, in the case of "a.b + x" I'm really just interested in a and x, not b. So
the (almost) whole story is that I do:
# Find names not starting with ".", i.e a & b in "a.c + b"
abbr_expr = re.sub(r"\.\w+", "", expr)
names = compile(abbr_expr, '', 'eval').co_names
# Python 2.6 returns '_[1]' in co_names for list comprehension. Bug?
names = [name for name in names if re.match(r'\w+$', name)]
for name in names:
if name not in allowed_names:
raise NameError('Name: %s not permitted in expression: %s' % (name,
expr))
--
https://mail.python.org/mailman/listinfo/python-list
Re: '_[1]' in .co_names using builtin compile() in Python 2.6
On Wednesday, November 27, 2013 9:09:32 PM UTC+1, Ned Batchelder wrote: > I hope you aren't trying to prevent malice this way: you cannot examine > a piece of Python code to prove that it's safe to execute. No worry. Whoever has access to modifying those configuration files can cause a mess in all sorts of other ways, such as writing and running arbitrary programs. I just want to give reasonably rapid feedback when people make mistakes. As with all python code, it's very important to test properly, but the top level names are often defined elsewhere in the configuration, so I want to catch those errors ASAP. -- https://mail.python.org/mailman/listinfo/python-list
Python treats non-breaking space wrong?
It seems that Python treats non-breaking space (\xa0) as a normal whitespace character, e.g. when splitting a string. See below: >>> s='hello\xa0there' >>> s.split() ['hello', 'there'] Surely this is not intended behaviour? -- http://mail.python.org/mailman/listinfo/python-list
Importing package with zip-archives
I'd like to have the following structure of my Python code: I have a directory called 'mysystem'. In this directory, I have files 'comp1.zip' and 'comp2.zip' etc which are zipped archives with python packages and modules. I'd like to be able to use them like this in my code: import mysystem.comp1.module import mysystem.comp2.package.module etc. Can I do that? I guess it requires that the __init__.py in mysystem is written in a clever way, but it's not clear how to do this, and I don't find a lot on this in any Python books or on the net. I tried: mysystem/__init__.py: import sys import os dir = os.path.abspath(os.path.dirname(__file__)) sys.path.insert(0, os.path.join(dir, 'comp1.zip')) import comp1 That doesn't do what I want. To access comp1 with this __init__.py I'll have to do import mysystem import comp1.module instead of import mysystem.comp1.module :-( Optionally, I'd like to be able to patch the system by putting a module.py in mysystem/comp2/package/ and get that to override the 'package/module.py' in comp2.zip. It's OK if I need to patch __init__.py in mysystem to do that. -- http://mail.python.org/mailman/listinfo/python-list
