Re: Python failed... Repeatedly
On 2/27/2017 11:16 PM, Jarod Nash wrote: I have just started into python and this was my first time setting up my own software. I ended up with pycharm and chose the python 3.6 or whatever translator. Every time I run my hello world program I get the message "invalid translator" and I get several pop ups giving me the options of This are not a CPython messages or behavior, so must be coming from PyCharm. custom set up, repair, or uninstall I have tried custom set up a few times and repair multiple times and even have gotten successful repairs even and next time I hit test it goes right back to where it was. Finally I was given the information for this from selecting the correct options in the pop ups. Does anyone have suggestions and can someone confirm that pycharm uses cpython instead of anaconda or jython ect. Please? Because I am taking a cpython course. P.s. I have tried visual studio, and like 3 other softwares and none of them had a successful download, and I have windows 10 but am looking into ubuntu. I run standard CPython 3.6 installed on Win 10 with the standard Windows installer from python.org and have no such problems. The same has been mostly true for previous python and windows versions for 20 years. I recommend that you start with that and forget PyCharm, etc., until you have Python running on your machine. -- Terry Jan Reedy -- https://mail.python.org/mailman/listinfo/python-list
Python failed... Repeatedly
I have just started into python and this was my first time setting up my own software. I ended up with pycharm and chose the python 3.6 or whatever translator. Every time I run my hello world program I get the message "invalid translator" and I get several pop ups giving me the options of custom set up, repair, or uninstall I have tried custom set up a few times and repair multiple times and even have gotten successful repairs even and next time I hit test it goes right back to where it was. Finally I was given the information for this from selecting the correct options in the pop ups. Does anyone have suggestions and can someone confirm that pycharm uses cpython instead of anaconda or jython ect. Please? Because I am taking a cpython course. P.s. I have tried visual studio, and like 3 other softwares and none of them had a successful download, and I have windows 10 but am looking into ubuntu. -- https://mail.python.org/mailman/listinfo/python-list
Re: python-libxdo?
On 2017-02-28 04:07, Jim wrote:
I found this module by accident the other day and decided to try to use
it to position some windows on my desktop.
# Script to open and position program windows
import subprocess
from xdo import Xdo
xdo = Xdo()
subprocess.call('firefox')
win = xdo.search_windows(winname = 'Mozilla Firefox')
xdo.move_window(win, 14, 83)
Traceback (most recent call last):
File "/home/jfb/MyProgs/Scripts/place_windows.py", line 9, in
win = xdo.search_windows(winname = 'Mozilla Firefox')
File "/home/jfb/EVs/env/lib/python3.5/site-packages/xdo/__init__.py",
line 708, in search_windows
search.winname = winname
TypeError: bytes or integer address expected instead of str instance
I couldn't find any examples on line, so what do I need to give to
search_windows so I can pass a window id to move_window?
Thanks, Jim
It looks like there are some docs here:
https://rshk.github.io/python-libxdo/index.html
--
https://mail.python.org/mailman/listinfo/python-list
python-libxdo?
I found this module by accident the other day and decided to try to use
it to position some windows on my desktop.
# Script to open and position program windows
import subprocess
from xdo import Xdo
xdo = Xdo()
subprocess.call('firefox')
win = xdo.search_windows(winname = 'Mozilla Firefox')
xdo.move_window(win, 14, 83)
Traceback (most recent call last):
File "/home/jfb/MyProgs/Scripts/place_windows.py", line 9, in
win = xdo.search_windows(winname = 'Mozilla Firefox')
File "/home/jfb/EVs/env/lib/python3.5/site-packages/xdo/__init__.py",
line 708, in search_windows
search.winname = winname
TypeError: bytes or integer address expected instead of str instance
I couldn't find any examples on line, so what do I need to give to
search_windows so I can pass a window id to move_window?
Thanks, Jim
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Tue, Feb 28, 2017 at 11:35 AM, Jon Ribbens wrote: > Sorry, I must have missed something here. What are you talking about? > "lambda: [1,2,3]" is not acceptable input to ast.literal_eval(), it > will throw an exception. [1,2,3] is, though. Go read my previous posts. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On 2017-02-27, Chris Angelico wrote:
> On Tue, Feb 28, 2017 at 3:58 AM, Jon Ribbens
> wrote:
>> Seeing as most of it is code along the lines of "is this an integer
>> constant? if so the value is that constant": no, I think "execution"
>> is a misleading word to use.
>
> That's true of a lot of executors. Doesn't change the fact that it
> will look at a UnaryOp or BinOp and (if it's [U]Add or [U]Sub) perform
> the corresponding operation. That's execution.
Yes. I didn't say the word "executing" was strictly false, just that
it is misleading, which it is.
>> So it isn't a literal "by my definition" after all (which isn't "my"
>> definition by the way).
>
> It's completely acceptable to ast.literal_eval.
Sorry, I must have missed something here. What are you talking about?
"lambda: [1,2,3]" is not acceptable input to ast.literal_eval(), it
will throw an exception.
>>> There's no literal syntax "frozenset({1, 2, 3})", but that got loaded
>>> as a constant.
>>
>> So that isn't a literal either - and it isn't accepted by literal_eval.
>> Jolly good. What's the problem?
>
> According to the disassembly (see my original post), it can be a
> constant. Not even a literal, yet it's a constant that gets baked into
> the function's attributes.
It's not a literal, and literal_eval() doesn't accept it.
A conundrum for the ages indeed.
Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
it is an example of a "list display", but that form is only a subset
of what "list display" means (displays include comprehensions), so
it is not true to say that literal_eval() can evaluate displays.
If we had to choose a way to describe it, it seems unlikely that
there's a better description than "list literal".
>>>
>>> It's a list display.
>>
>> I just explained right there in the text you quoted why that is not
>> sufficient as a description. Just repeating part of what I already
>> said back to me and ignoring the rest isn't going to progress things
>> very much.
>
> My point is that it truly IS a list display, despite your concerns.
Yes. As I already said that I already said, I already said that.
As I also already said, please stop repeating me back to me.
>>> That's a pretty tricky concept to try to bake into a definition, but
>>> that's exactly the recursive definition that literal_eval actually uses.
>>
>> So the definition is useful and accurate then!
>
> Yet it disagrees with the comp sci definition that you espoused earlier.
In what way?
> Nope. I still believe that literal_eval isn't precisely evaluating
> literals in the Python sense,
Yes, that is also what I already said. It's evaluating literals in the
comp sci sense (with an undocumented extension in some versions that
should not be relied on as it's a side effect of the implementation).
> but that it evaluates a subset of expressions that can be safely
> parsed.
Yes, but as I already said it is such a tiny subset of expressions
that even comparing it to that set is utterly misleading. It's like
calling the number 7 "a subset of the real numbers". It's technically
true ("the best kind of true!") but leads you in completely the wrong
direction.
>>> Its docstring most definitely says "expression", though, because
>>> there are some non-literal expressions that it DOES evaluate, and
>>> for good reason.
>>
>> ... the good reason being that they are literals.
>
> Yeah, but we haven't settled a definition that actually means that they are.
I'm getting a bizarre sense of deja vu in pointing out that I'm
repeating myself, but: "a literal is a notation for representing
a fixed value in source code".
--
https://mail.python.org/mailman/listinfo/python-list
Re: panda, column access
On Monday, February 27, 2017 at 4:27:23 PM UTC-5, Pavol Lisy wrote: > On 2/27/17, Andrew Zyman wrote: > I think you meant: > colnames = ['hostname'] arh... Exactly. Now the rest is "unfolding". > What do you want is probably: > >>> data[colnames[0]].tolist() this is great and the rest of the code works. but the output of "list_data = data.hostname.tolist()" is the comma separated strings, and "list_data = data[colnames[0]].get_values()" is space separated list. I suspect the answer to my "why" is in your statements below . > or maybe if you don't want to remember colnames: > >>> data[data.columns[0]].tolist() > Be careful! Type of data[x] depend on what type is x. > >>> type(data['hostname']) # -> pandas.core.series.Series > >>> type(data[['hostname']]) # -> pandas.core.frame.DataFrame Thank you Pavol, very helpful. -- https://mail.python.org/mailman/listinfo/python-list
Re: panda, column access
On 2/27/17, Andrew Zyman wrote: > Hello, > i'm trying to understand what is the difference between the below code. > And how do i access the column's data without hardcoding the column name in > such a way that i'll be able to convert it's values into the list of > strings? > > I appreciate your help. > > Short version: > colnames='hostname' I think you meant: colnames = ['hostname'] > data = pandas.read_csv(input_file, names=colnames) > list_data = data.hostname.tolist() or list_data = data['hostname'].tolist() > returns the list like - ['hostname','hostname1'] - exactly what i want. > but neither of the below versions work as expected (returning the list of > strings): > list_data = data[0].tolist() -> errors with "return > self._getitem_column(key)" > list_data = data[colnames].values.tolist() -> the list_data is : [ > ['hostname'],['hostname1'...] > list_data = data.tolist() -> errors with "AttributeError: 'DataFrame' object > has no attribute 'tolist'" What do you want is probably: >>> data[colnames[0]].tolist() or maybe if you don't want to remember colnames: >>> data[data.columns[0]].tolist() Be careful! Type of data[x] depend on what type is x. >>> type(data['hostname']) # -> pandas.core.series.Series >>> type(data[['hostname']]) # -> pandas.core.frame.DataFrame -- https://mail.python.org/mailman/listinfo/python-list
panda, column access
Hello, i'd appreciate an explanation about the differences in the code versions below. I'm trying to get the list of the strings out of the column and avoid hardcoding the column name. cat Data/2domain.csv hostname hostname1 hostname2 ... ... Working version(s): Python2.7: input_file = r'Data/2domain.csv' colnames = ['hostname'] data = pandas.read_csv(input_file, names=colnames,header=0) list_data = data.hostname.tolist() # or #list_data = data['hostname'].tolist() print list_data ['hostname','hostname1','hostname3'] And confusion is with these versions: colnames = ['hostname'] data = pandas.read_csv(input_file, names=colnames,header=0) list_data = data[colnames].tolist() -AttributeError: 'DataFrame' object has no attribute 'tolist' list_data = data[colnames].get_values().tolist() - [ ['hostname'],['hostname1']..] list_data = data[colnames].get_values() - [ ['hostname'], ['hostname1'] .. ] Thank you AZ [working code] [/working code] [no working code ] [/not working code ] -- https://mail.python.org/mailman/listinfo/python-list
panda, column access
Hello, i'm trying to understand what is the difference between the below code. And how do i access the column's data without hardcoding the column name in such a way that i'll be able to convert it's values into the list of strings? I appreciate your help. Short version: colnames='hostname' data = pandas.read_csv(input_file, names=colnames) list_data = data.hostname.tolist() or list_data = data['hostname'].tolist() returns the list like - ['hostname','hostname1'] - exactly what i want. but neither of the below versions work as expected (returning the list of strings): list_data = data[0].tolist() -> errors with "return self._getitem_column(key)" list_data = data[colnames].values.tolist() -> the list_data is : [ ['hostname'],['hostname1'...] list_data = data.tolist() -> errors with "AttributeError: 'DataFrame' object has no attribute 'tolist'" More details: [code] file ./Data/domain.csv ./domain.csv: ASCII text, with CRLF line terminators head -3 ./Data/domain.csv sunqq.ux.yyy. sunww.ux.yyy. sunee.ux.yyy. [/code] all work is done in Python 2.7. Working version [code] input_file = r'Data/2domain.csv' colnames = ['hostname'] data = pandas.read_csv(input_file, names=colnames) list_data = data.hostname.tolist() list_data = list(set(list_data)) print list_data [/code] Non working version: [code] input_file = r'Data/2domain.csv' colnames = ['hostname'] data = pandas.read_csv(input_file, names=colnames) #list_data = data.hostname.tolist() # neither list_data = data[0].tolist() list_data = data[colnames].tolist() list_data = data['QUERY'].tolist() list_data = data.tolist() # return the list I expected list_data = list(set(list_data)) print list_data [/code] -- https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Tue, Feb 28, 2017 at 3:58 AM, Jon Ribbens wrote:
> On 2017-02-27, Chris Angelico wrote:
>> On Tue, Feb 28, 2017 at 3:17 AM, Jon Ribbens
>> wrote:
>>> On 2017-02-27, Chris Angelico wrote:
Actually it does execute, as you can see from the source code.
>>>
>>> I'm not sure what you mean by that. I was looking at the source code
>>> (and its history) when I wrote my post, and I would be hard pushed to
>>> describe it as "executing" anything.
>>
>> You could say that it "interprets" the AST. It has exactly the same
>> kind of if/elif tree of "this kind of thing? do this" that a naive and
>> unoptimized language interpreter would use. Does that not count as
>> execution?
>
> Seeing as most of it is code along the lines of "is this an integer
> constant? if so the value is that constant": no, I think "execution"
> is a misleading word to use.
That's true of a lot of executors. Doesn't change the fact that it
will look at a UnaryOp or BinOp and (if it's [U]Add or [U]Sub) perform
the corresponding operation. That's execution.
>>> Actually, that is a literal, in the computer science sense: "a literal
>>> is a notation for representing a fixed value in source code".
>>> I realise it isn't a literal in the sense of "as defined by section
>>> 2.4 of the Python Language Reference", but then perhaps most people
>>> would expect the word to have its more generic meaning.
>>
>> So what _is_ a literal?
>
> It's "a notation for representing a fixed value in source code",
> I just said so right there above.
>
>> Can you have a literal that evaluates to a non-constant, or a
>> non-literal that gets compiled to a constant? Here are examples of both:
>>
> dis.dis(lambda: [1,2,3])
>
>> By your definition, this is a literal,
>
> No, it isn't - it's pushing it somewhat to call a function a "value"
> (especially in the context of when words like "literal" were coined),
> and it's certainly not a "fixed value" in this sense. (Yes, I know the
> function itself does not change. That doesn't make it a "fixed value".)
>
>> but it most surely does not represent a fixed value.
>
> So it isn't a literal "by my definition" after all (which isn't "my"
> definition by the way).
It's completely acceptable to ast.literal_eval. You said earlier that
literal_eval really does evaluate literals, not expressions. So how
can this simultaneously be acceptable to literal_eval but not a
literal, of literal_eval evaluates literals? (Woodchucks chucking wood
come to mind.)
>> There's no literal syntax "frozenset({1, 2, 3})", but that got loaded
>> as a constant.
>
> So that isn't a literal either - and it isn't accepted by literal_eval.
> Jolly good. What's the problem?
According to the disassembly (see my original post), it can be a
constant. Not even a literal, yet it's a constant that gets baked into
the function's attributes.
>>> Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
>>> it is an example of a "list display", but that form is only a subset
>>> of what "list display" means (displays include comprehensions), so
>>> it is not true to say that literal_eval() can evaluate displays.
>>> If we had to choose a way to describe it, it seems unlikely that
>>> there's a better description than "list literal".
>>
>> It's a list display.
>
> I just explained right there in the text you quoted why that is not
> sufficient as a description. Just repeating part of what I already
> said back to me and ignoring the rest isn't going to progress things
> very much.
My point is that it truly IS a list display, despite your concerns.
"42" is a subset of the definition of integer literals, but that
doesn't stop it from being one.
>> That's a pretty tricky concept to try to bake into a definition, but
>> that's exactly the recursive definition that literal_eval actually uses.
>
> So the definition is useful and accurate then!
Yet it disagrees with the comp sci definition that you espoused earlier.
>> Given the many subtle differences in usage of the word "literal", I'm
>> happy with it using that name. It's not 100% accurate, but it covers
>> the non-pedantic uses of the term.
>
> You seem to have got turned around and are now arguing in favour of my
> position and against your own previous position.
Nope. I still believe that literal_eval isn't precisely evaluating
literals in the Python sense, but that it evaluates a subset of
expressions that can be safely parsed.
>> Its docstring most definitely says "expression", though, because
>> there are some non-literal expressions that it DOES evaluate, and
>> for good reason.
>
> ... the good reason being that they are literals.
Yeah, but we haven't settled a definition that actually means that they are.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On 2017-02-27, Chris Angelico wrote:
> On Tue, Feb 28, 2017 at 3:17 AM, Jon Ribbens
> wrote:
>> On 2017-02-27, Chris Angelico wrote:
>>> Actually it does execute, as you can see from the source code.
>>
>> I'm not sure what you mean by that. I was looking at the source code
>> (and its history) when I wrote my post, and I would be hard pushed to
>> describe it as "executing" anything.
>
> You could say that it "interprets" the AST. It has exactly the same
> kind of if/elif tree of "this kind of thing? do this" that a naive and
> unoptimized language interpreter would use. Does that not count as
> execution?
Seeing as most of it is code along the lines of "is this an integer
constant? if so the value is that constant": no, I think "execution"
is a misleading word to use.
>> Actually, that is a literal, in the computer science sense: "a literal
>> is a notation for representing a fixed value in source code".
>> I realise it isn't a literal in the sense of "as defined by section
>> 2.4 of the Python Language Reference", but then perhaps most people
>> would expect the word to have its more generic meaning.
>
> So what _is_ a literal?
It's "a notation for representing a fixed value in source code",
I just said so right there above.
> Can you have a literal that evaluates to a non-constant, or a
> non-literal that gets compiled to a constant? Here are examples of both:
>
dis.dis(lambda: [1,2,3])
> By your definition, this is a literal,
No, it isn't - it's pushing it somewhat to call a function a "value"
(especially in the context of when words like "literal" were coined),
and it's certainly not a "fixed value" in this sense. (Yes, I know the
function itself does not change. That doesn't make it a "fixed value".)
> but it most surely does not represent a fixed value.
So it isn't a literal "by my definition" after all (which isn't "my"
definition by the way).
> There's no literal syntax "frozenset({1, 2, 3})", but that got loaded
> as a constant.
So that isn't a literal either - and it isn't accepted by literal_eval.
Jolly good. What's the problem?
>> Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
>> it is an example of a "list display", but that form is only a subset
>> of what "list display" means (displays include comprehensions), so
>> it is not true to say that literal_eval() can evaluate displays.
>> If we had to choose a way to describe it, it seems unlikely that
>> there's a better description than "list literal".
>
> It's a list display.
I just explained right there in the text you quoted why that is not
sufficient as a description. Just repeating part of what I already
said back to me and ignoring the rest isn't going to progress things
very much.
>> (See also the "What's new" announcement for Python 3.2 where the
>> addition of set support to literal_eval() was described as adding
>> "set literals". https://docs.python.org/3/whatsnew/3.2.html#ast )
>
> Technically they're called "set display", too. Does it count as a
> literal if and only if all members are literals?
That seems to be the unavoidable consequence of the definition, yes.
> That's a pretty tricky concept to try to bake into a definition, but
> that's exactly the recursive definition that literal_eval actually uses.
So the definition is useful and accurate then!
> Given the many subtle differences in usage of the word "literal", I'm
> happy with it using that name. It's not 100% accurate, but it covers
> the non-pedantic uses of the term.
You seem to have got turned around and are now arguing in favour of my
position and against your own previous position.
> Its docstring most definitely says "expression", though, because
> there are some non-literal expressions that it DOES evaluate, and
> for good reason.
... the good reason being that they are literals.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Tue, Feb 28, 2017 at 3:17 AM, Jon Ribbens wrote:
> On 2017-02-27, Chris Angelico wrote:
>> Actually it does execute, as you can see from the source code.
>
> I'm not sure what you mean by that. I was looking at the source code
> (and its history) when I wrote my post, and I would be hard pushed to
> describe it as "executing" anything.
You could say that it "interprets" the AST. It has exactly the same
kind of if/elif tree of "this kind of thing? do this" that a naive and
unoptimized language interpreter would use. Does that not count as
execution?
> ast.literal_eval("[1,2,3]")
>> [1, 2, 3]
>>
>> This isn't a literal, and it's evaluated by literal_eval.
>
> Actually, that is a literal, in the computer science sense: "a literal
> is a notation for representing a fixed value in source code".
> I realise it isn't a literal in the sense of "as defined by section
> 2.4 of the Python Language Reference", but then perhaps most people
> would expect the word to have its more generic meaning.
So what _is_ a literal? Can you have a literal that evaluates to a
non-constant, or a non-literal that gets compiled to a constant? Here
are examples of both:
>>> dis.dis(lambda: [1,2,3])
1 0 LOAD_CONST 1 (1)
2 LOAD_CONST 2 (2)
4 LOAD_CONST 3 (3)
6 BUILD_LIST 3
8 RETURN_VALUE
By your definition, this is a literal, but it most surely does not
represent a fixed value. Every time you call this function, it will
construct and return a brand new list.
>>> dis.dis(lambda x: x in {1,2,3})
1 0 LOAD_FAST0 (x)
2 LOAD_CONST 4 (frozenset({1, 2, 3}))
4 COMPARE_OP 6 (in)
6 RETURN_VALUE
There's no literal syntax "frozenset({1, 2, 3})", but that got loaded
as a constant.
> Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
> it is an example of a "list display", but that form is only a subset
> of what "list display" means (displays include comprehensions), so
> it is not true to say that literal_eval() can evaluate displays.
> If we had to choose a way to describe it, it seems unlikely that
> there's a better description than "list literal".
It's a list display.
> (See also the "What's new" announcement for Python 3.2 where the
> addition of set support to literal_eval() was described as adding
> "set literals". https://docs.python.org/3/whatsnew/3.2.html#ast )
Technically they're called "set display", too. Does it count as a
literal if and only if all members are literals? That's a pretty
tricky concept to try to bake into a definition, but that's exactly
the recursive definition that literal_eval actually uses.
>> It's basically a "safe eval of simple expressions".
>
> What I was trying to say was that I think that is a very misleading
> way of describing it. It is not entirely untrue, but it is much closer
> to being false than it is to being true. It isn't "safe eval", and it
> is not intended to deal with any expressions.
>
> (See also http://bugs.python.org/issue22525 )
Given the many subtle differences in usage of the word "literal", I'm
happy with it using that name. It's not 100% accurate, but it covers
the non-pedantic uses of the term. Its docstring most definitely says
"expression", though, because there are some non-literal expressions
that it DOES evaluate, and for good reason.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On 2017-02-27, Chris Angelico wrote:
> On Tue, Feb 28, 2017 at 1:18 AM, Jon Ribbens
> wrote:
>> "execution" isn't really the right way to describe literal_eval().
>> It isn't an code executor or even an expression evaluator, all it
>> does is turns a Python literal in source form into the value that
>> source represents. You can't do literal_eval("2*3") for example,
>> because that's an expression not a literal.
>>
>> The only reason you can do literal_eval("2+3") (in Python>=3.2)
>> is because of a side effect of the fact that complex number literals
>> are, well, complex ("2+3j"), and the support for +/- wasn't restricted
>> to complex literals only.
>
> Actually it does execute, as you can see from the source code.
I'm not sure what you mean by that. I was looking at the source code
(and its history) when I wrote my post, and I would be hard pushed to
describe it as "executing" anything.
> The name "literal" is slightly incorrect technically, as it will run
> some code that isn't actually a literal (nor even covered by constant
> folding, which "2+3j" is - it's two literals and a binary operator,
> but constant folded at compile time).
Actually the name is more correct than the code is! It is clear that
what it is trying to do is exactly as I described above and as its
name indicates. The fact that in Python >= 3.2 it allows binary
addition and subtraction of numeric values is an undocumented
extension to the specification resulting from a side effect of the
implementation.
ast.literal_eval("[1,2,3]")
> [1, 2, 3]
>
> This isn't a literal, and it's evaluated by literal_eval.
Actually, that is a literal, in the computer science sense: "a literal
is a notation for representing a fixed value in source code".
I realise it isn't a literal in the sense of "as defined by section
2.4 of the Python Language Reference", but then perhaps most people
would expect the word to have its more generic meaning.
Python doesn't seem to have a word for "[1, 2, 3]", inasmuch as
it is an example of a "list display", but that form is only a subset
of what "list display" means (displays include comprehensions), so
it is not true to say that literal_eval() can evaluate displays.
If we had to choose a way to describe it, it seems unlikely that
there's a better description than "list literal".
(See also the "What's new" announcement for Python 3.2 where the
addition of set support to literal_eval() was described as adding
"set literals". https://docs.python.org/3/whatsnew/3.2.html#ast )
> It's basically a "safe eval of simple expressions".
What I was trying to say was that I think that is a very misleading
way of describing it. It is not entirely untrue, but it is much closer
to being false than it is to being true. It isn't "safe eval", and it
is not intended to deal with any expressions.
(See also http://bugs.python.org/issue22525 )
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Tue, Feb 28, 2017 at 1:18 AM, Jon Ribbens wrote:
> On 2017-02-27, Vincent Vande Vyvre wrote:
>> Le 27/02/17 à 14:09, Chris Angelico a écrit :
>>> The message is a little confusing, but the error comes from the fact
>>> that literal_eval permits a very few legal operations, and calling a
>>> function isn't one of them. So when you try to evaluate the "literal"
>>> that you've given it, you get back an error saying that a Call is
>>> 'malformed'. More accurate would be to say that it's not permitted.
>>
>> OK, it's coherent with the secure execution.
>
> "execution" isn't really the right way to describe literal_eval().
> It isn't an code executor or even an expression evaluator, all it
> does is turns a Python literal in source form into the value that
> source represents. You can't do literal_eval("2*3") for example,
> because that's an expression not a literal.
>
> The only reason you can do literal_eval("2+3") (in Python>=3.2)
> is because of a side effect of the fact that complex number literals
> are, well, complex ("2+3j"), and the support for +/- wasn't restricted
> to complex literals only.
Actually it does execute, as you can see from the source code. The
name "literal" is slightly incorrect technically, as it will run some
code that isn't actually a literal (nor even covered by constant
folding, which "2+3j" is - it's two literals and a binary operator,
but constant folded at compile time).
>>> ast.literal_eval("[1,2,3]")
[1, 2, 3]
This isn't a literal, and it's evaluated by literal_eval. It's
basically a "safe eval of simple expressions".
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On 2017-02-27, Vincent Vande Vyvre wrote:
> Le 27/02/17 à 14:09, Chris Angelico a écrit :
>> The message is a little confusing, but the error comes from the fact
>> that literal_eval permits a very few legal operations, and calling a
>> function isn't one of them. So when you try to evaluate the "literal"
>> that you've given it, you get back an error saying that a Call is
>> 'malformed'. More accurate would be to say that it's not permitted.
>
> OK, it's coherent with the secure execution.
"execution" isn't really the right way to describe literal_eval().
It isn't an code executor or even an expression evaluator, all it
does is turns a Python literal in source form into the value that
source represents. You can't do literal_eval("2*3") for example,
because that's an expression not a literal.
The only reason you can do literal_eval("2+3") (in Python>=3.2)
is because of a side effect of the fact that complex number literals
are, well, complex ("2+3j"), and the support for +/- wasn't restricted
to complex literals only.
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Tue, Feb 28, 2017 at 12:44 AM, Vincent Vande Vyvre
wrote:
> OK, it's coherent with the secure execution.
>
Yep. Here's a PR to make the message a bit clearer, though:
https://github.com/python/cpython/pull/340
>>> ast.literal_eval("print('hello world')")
Traceback (most recent call last):
File "", line 1, in
File "/usr/local/lib/python3.7/ast.py", line 87, in literal_eval
return _convert(node_or_string)
File "/usr/local/lib/python3.7/ast.py", line 85, in _convert
raise ValueError('%s not allowed in literal' % type(node).__name__)
ValueError: Call not allowed in literal
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
Le 27/02/17 à 14:09, Chris Angelico a écrit :
On Mon, Feb 27, 2017 at 11:57 PM, Vincent Vande Vyvre
wrote:
I've this strange error:
Python 3.4.3 (default, Nov 17 2016, 01:08:31)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
import ast
l = "print('hello world')"
ast.literal_eval(l)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python3.4/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Call object at 0x7fcf955871d0>
Is it an import question ?
The message is a little confusing, but the error comes from the fact
that literal_eval permits a very few legal operations, and calling a
function isn't one of them. So when you try to evaluate the "literal"
that you've given it, you get back an error saying that a Call is
'malformed'. More accurate would be to say that it's not permitted.
ChrisA
OK, it's coherent with the secure execution.
Thanks
Vincent
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
Vincent Vande Vyvre writes:
> I've this strange error:
>
> Python 3.4.3 (default, Nov 17 2016, 01:08:31)
> [GCC 4.8.4] on linux
> Type "help", "copyright", "credits" or "license" for more information.
import ast
l = "print('hello world')"
ast.literal_eval(l)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python3.4/ast.py", line 83, in _convert
> raise ValueError('malformed node or string: ' + repr(node))
> ValueError: malformed node or string: <_ast.Call object at 0x7fcf955871d0>
>
>
> Is it an import question ?
print('hello world') is not a literal.
Literals are expressions that somehow stand for themselves. Try
help(ast.literal_eval) for a more detailed definition.
literal_eval('x') # not ok: x is not a literal
literal_eval('"x"') # ok: "x" is a literal
--
https://mail.python.org/mailman/listinfo/python-list
Re: Usage of ast.
On Mon, Feb 27, 2017 at 11:57 PM, Vincent Vande Vyvre
wrote:
> I've this strange error:
>
> Python 3.4.3 (default, Nov 17 2016, 01:08:31)
> [GCC 4.8.4] on linux
> Type "help", "copyright", "credits" or "license" for more information.
import ast
l = "print('hello world')"
ast.literal_eval(l)
> Traceback (most recent call last):
> File "", line 1, in
> File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
> return _convert(node_or_string)
> File "/usr/lib/python3.4/ast.py", line 83, in _convert
> raise ValueError('malformed node or string: ' + repr(node))
> ValueError: malformed node or string: <_ast.Call object at 0x7fcf955871d0>
>
>
> Is it an import question ?
The message is a little confusing, but the error comes from the fact
that literal_eval permits a very few legal operations, and calling a
function isn't one of them. So when you try to evaluate the "literal"
that you've given it, you get back an error saying that a Call is
'malformed'. More accurate would be to say that it's not permitted.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
Usage of ast.
I've this strange error:
Python 3.4.3 (default, Nov 17 2016, 01:08:31)
[GCC 4.8.4] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import ast
>>> l = "print('hello world')"
>>> ast.literal_eval(l)
Traceback (most recent call last):
File "", line 1, in
File "/usr/lib/python3.4/ast.py", line 84, in literal_eval
return _convert(node_or_string)
File "/usr/lib/python3.4/ast.py", line 83, in _convert
raise ValueError('malformed node or string: ' + repr(node))
ValueError: malformed node or string: <_ast.Call object at 0x7fcf955871d0>
Is it an import question ?
Vincent
--
https://mail.python.org/mailman/listinfo/python-list
Re: dictionary of pickle error when get it in multiprocessing and has name error
Ho Yeung Lee wrote: > before cloususerlogin > Unexpected error: > after map pool > > > ... > passwordlist = pickle.load( open( str(currentworkingdirectory) + > "\\decryptedsecret.p", "rb" ) ) According to https://docs.python.org/dev/library/multiprocessing.html#programming-guidelines you cannot use global resources on Windows: """ Explicitly pass resources to child processes On Unix using the fork start method, a child process can make use of a shared resource created in a parent process using a global resource. However, it is better to pass the object as an argument to the constructor for the child process. Apart from making the code (potentially) compatible with Windows and the other start methods this also ensures that as long as the child process is still alive the object will not be garbage collected in the parent process. This might be important if some resource is freed when the object is garbage collected in the parent process. So for instance from multiprocessing import Process, Lock def f(): ... do something using "lock" ... if __name__ == '__main__': lock = Lock() for i in range(10): Process(target=f).start() should be rewritten as from multiprocessing import Process, Lock def f(l): ... do something using "l" ... if __name__ == '__main__': lock = Lock() for i in range(10): Process(target=f, args=(lock,)).start() """ -- https://mail.python.org/mailman/listinfo/python-list
