Skip to content
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

Feature request: provide support for DictComp #57

Closed
Reskov opened this issue Jun 11, 2019 · 6 comments
Closed

Feature request: provide support for DictComp #57

Reskov opened this issue Jun 11, 2019 · 6 comments
Labels
next release probably fixed Probably Fixed, waiting for confirmation
Milestone

Comments

@Reskov
Copy link

Reskov commented Jun 11, 2019

Such code is not support by EvalWithCompoundTypes

{i:i for i in range(3)}

Basically, it is should be easy to support such functionality with something like that Reskov@695bb68

I can do more tests and prepare PR if you agree in general

@patricksurry
Copy link

I guess this is another example, trying to evaluate something like {**a, **b}:

>>> names = dict(a=dict(x=1, y=2), b=dict(z=3))
>>> EvalWithCompoundTypes(names=names).eval('{**a, **b}')
Traceback (most recent call last):
  File "/Users/psurry/Downloads/simpleeval.py", line 395, in _eval
    handler = self.nodes[type(node)]
KeyError: <class 'NoneType'>

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/Users/psurry/Downloads/simpleeval.py", line 616, in eval
    return super(EvalWithCompoundTypes, self).eval(expr)
  File "/Users/psurry/Downloads/simpleeval.py", line 389, in eval
    return self._eval(ast.parse(expr.strip()).body[0])
  File "/Users/psurry/Downloads/simpleeval.py", line 401, in _eval
    return handler(node)
  File "/Users/psurry/Downloads/simpleeval.py", line 404, in _eval_expr
    return self._eval(node.value)
  File "/Users/psurry/Downloads/simpleeval.py", line 401, in _eval
    return handler(node)
  File "/Users/psurry/Downloads/simpleeval.py", line 619, in _eval_dict
    return {self._eval(k): self._eval(v) for (k, v) in zip(node.keys, node.values)}
  File "/Users/psurry/Downloads/simpleeval.py", line 619, in <dictcomp>
    return {self._eval(k): self._eval(v) for (k, v) in zip(node.keys, node.values)}
  File "/Users/psurry/Downloads/simpleeval.py", line 398, in _eval
    "Sorry, {0} is not available in this " "evaluator".format(type(node).__name__)
simpleeval.FeatureNotAvailable: Sorry, NoneType is not available in this evaluator
>>> 

@patricksurry
Copy link

patricksurry commented Feb 16, 2022

I used a workaround by evaluating something like this dict(list(a.items()) + list(b.items())). Looking at the AST parse:

>>> ast.dump(ast.parse('{**a}'))
"Module(body=[Expr(value=Dict(keys=[None], values=[Name(id='a', ctx=Load())]))])"

I guess it's not handling the keys=[None] piece? Adding an explicit key doesn't help:

>>> ast.dump(ast.parse('{"a": 1, **a}'))
"Module(body=[Expr(value=Dict(keys=[Str(s='a'), None], values=[Num(n=1), Name(id='a', ctx=Load())]))])"
>>> 

I guess this would be fixed by either tweaking _eval_dict to handle injection of a dictionary in v when k was None? See the ast docs where it explains: "When doing dictionary unpacking using dictionary literals the expression to be expanded goes in the values list, with a None at the corresponding position in keys."

Perhaps this is a different bug that the originally reported one?

@danthedeckie
Copy link
Owner

This would be really cool to add

@amyasnikov
Copy link

+1 for this feature request. DictComp is really a missing thing for this cool library.
@Reskov could you prepare a PR? As I see in the previous comment @danthedeckie is ready to accept it (please correct me if I'm wrong)

@Reskov
Copy link
Author

Reskov commented Apr 17, 2023

@amyasnikov Not sure. Personally, I am not interested in this anymore. 😞 And there was already PR #62.

@danthedeckie
Copy link
Owner

Should be fixed in 1.0.0

@danthedeckie danthedeckie added this to the 1.0 Release milestone Oct 4, 2024
@danthedeckie danthedeckie added probably fixed Probably Fixed, waiting for confirmation next release labels Oct 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next release probably fixed Probably Fixed, waiting for confirmation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants