New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ast.literal_eval() doesn't support empty sets #83339
Comments
We already support sets but not empty sets. After the PR, this now works: >>> from ast import literal_eval
>>> literal_eval('set()')
set() If we wanted, it would be a simple matter to extend it frozensets: >>> literal_eval('frozenset({10, 20, 30})')
frozenset({10, 20, 30}) |
set() is neither literal nor container display. |
Yes, that is obvious. However, we do support sets and set() is how make an empty set. It is weird to support sets but not empty sets, especially when it is so easy to do so safely. |
The function literal_eval is not safe anymore as the constructor can be intercepted: >>> import builtins
>>> def evil_code(*args):
... print("Something evil")
...
>>> builtins.set = evil_code
>>> ast.literal_eval("set()")
Something evil I think we should either use {0}.__class__. Also, the documentation now is wrong as the function does more than evaluate literals or container displays. |
Well, actually it can also be done with any other builtin via the same trick, so this is no different but is only slightly more obvious that it can be done. I still find a bit weird that the documentation says "literal or container display" but 'set' is neither. |
I am re-closing the issue as I don't think is worth complicating the docs for this edge case and the security concern is non existent. Apologies for the noise. If someone feels strongly about the documentation, they can reopen the issue. |
The documentation for ast.literal_eval(): Safely evaluate an expression node or a string containing a Python literal or https://docs.python.org/3/library/ast.html#ast.literal_eval If we are going to add support of a function call set(), we should change the documentation. And if add support of non-literals, where should we stop? Should we support also frozenset() and bytearray()? inf and nan? infj and nanj? complex()? Ellipsis? __debug__? |
Then the name of the function would be a bit misleading (for frozenset() and bytearray()), no? I think the set() change is somehow inconsistent already with the function name. |
"Safe" means safe from user input to literal_eval(). If a person can already write arbitrary code that redefines a builtin, then they can already do anything they want. |
Yup, apologies. I had something in mind and I realized after writing my initial comment. That is why I said afterwards:
|
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: