You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Would it be useful to add a default implementation of visit_Constant(self, node) on NodeVisitor that go through all the isinstance() check and call the appropriate backward compatible method ?
We would still have the simplification without having any breakage in backward compatibility.
That feels like best of both worlds ?
asottile commented on May 14, 2019
asottilemannequin
MannequinAuthor
More actions
There would still be a breakage for that if someone was defining py36+ visit_Constant (which would clobber the ast.NodeVisitor.visit_Constant if we were to add it)
Carreau commented on May 14, 2019
Carreaumannequin
Mannequin
More actions
There would still be a breakage for that if someone was defining py36+ visit_Constant (which would clobber the ast.NodeVisitor.visit_Constant if we were to add it)
Ok, it would still break in some cases, but that would still be a net improvement for codebase that do not override visit_Constant; right ?
We could also push the patch further if we really want and call explicitly NodeVisitor.visit_Constant before the overridden method in NodeVisitor.visit.
Not advocating for the second part, but minimal breakage and code repetition in libraries when we can.
asottile commented on May 15, 2019
asottilemannequin
MannequinAuthor
More actions
spent some more time thinking about this and I think we should strongly consider reverting. simplification in the core interpreter should not be weighed lightly against complexity and breaking changes for users.
the change is also unfortunate because it reduces the expressivity of the ast
as we discuss shims, I believe the intention is to remove the Num / Str / etc. layer eventually so it's really just delaying that.
so my vote is to revert, keep the complexity in the compiler and out of user code
Carreau commented on May 15, 2019
Carreaumannequin
Mannequin
More actions
so my vote is to revert, keep the complexity in the compiler and out of user code
Playing Devil advocate here, but the complexity depends on what transformations user want to do; with the current state of 3.8, a user that wants to visit all immutable types can do with a single visit_Constant; once 32892 reverted; they would need to implement all of visit_Str,NamedConstant,Num,Bytes, and have it called the same visit_Constant.
This is not a new case. This is exactly the same problem which has already been fixed in multiple other projects.
Could you show your real code Anthony? In all known opensource examples (astroid, pyflakes, genshi, chameleon, mako) the compatibility fix is as simple as
In return, you can remove several methods, such as visit_Str, visit_Num, etc, once you drop the support of Python versions <3.8.
AST is not stable. Virtually in every version the new nodes are added: for asynchronous constructions, for f-strings, etc, and the structure and meaning of existing nodes can be changed.
asottile commented on May 15, 2019
asottilemannequin
MannequinAuthor
More actions
The simplest case is just the addition of an isinstance check:
But I have another case where there's much more complex (sorry this one's private, I'll give the pseudo-code of it though which ends up in a whole mess of slow isinstance(...) calls
classV(ast.NodeVisitor):
defvisit_Str(self, node):
...
defvisit_Bytes(self, node):
...
defvisit_Num(self, node):
...
defvisit_Constant(self, node):
ifisinstance(node.value, str):
returnself.visit_Str(node)
# Annoying special case, bools are ints, before this wouldn't call# `visit_Num` because there was a separate `visit_NameConstant` for `True` / `False`elifisinstance(node.value, int) andnotisinstance(node.value, bool):
returnself.visit_Num(node)
elifisinstance(node.value, bytes):
returnself.visit_Bytes(node)
else:
returnself.generic_visit(node)
Whereas the opposite case (where handling all constants the same) is much much easier to simplify the code and not need the Constant mess (if required)
classV(ast.NodeVisitor):
def_visit_constant(self, node):
# generic handling of constant _if you want it_visit_Str=visit_Num=visit_Bytes=visit_NameConstant=visit_Ellipsis=_visit_constant
Maybe I haven't been in the community long enough but this is the first *removal* of the ast I've seen, and it makes all my uses of these functions objectively worse, and none of the cases get simpler (whereas there's an existing easy way to simplify constants already, without breaking the ast)
github search isn't a great measure of this but it's currently showing 10k+ usages of visit_{Str,Num,Bytes} that would presumably be broken by this change: https://github.com/search?q=visit_Num+visit_Str+visit_Bytes&type=Code -- backward compatibility is very valuable, I would hope it isn't squandered for an internal cleanup
You can not use the same implementation of the visitor for Num, Str, NameConstant and Ellipsis, because all these classes use different attribute for saving the value (Ellipsis does not have it at all). For the same reasons you can not just pass the argument of visit_Constant() to visit_Str() -- they have different types.
No need to call generic_visit() from visit_Constant() -- Constant nodes should not contain AST nodes.
asottile commented on May 15, 2019
asottilemannequin
MannequinAuthor
More actions
You can not use the same implementation of the visitor for Num, Str, NameConstant and Ellipsis, because all these classes use different attribute for saving the value
ah yes, this is true -- maybe the better change would be to just add @property value to each of those instead of collapsing the classes? (If that's the actual convenience we're trying to achieve)
No need to call generic_visit() from visit_Constant() -- Constant nodes should not contain AST nodes.
correct there's no need, but it's a best practice to always call generic_visit in all visit_* methods, I have a linter I haven't finished up yet that checks this. And who knows if that'll be true in the future!
What about adding visit_Constant to NodeVisitor for at least one relase period and call visit_Str, visit_Num etc?
TylerWince commented on Jun 25, 2019
TylerWincemannequin
Mannequin
More actions
Another example of the breaking change here is in the security linter PyCQA/bandit. It may be a simple addition of a check in the meta parser for the ast but I would tend to agree with Anthony around whether or not it is worth it.
Anyone else have any thoughts on this since the conversation ended last month?
New changeset c3ea41e by Serhiy Storchaka in branch 'master': bpo-36917: Add default implementation of ast.NodeVisitor.visit_Constant(). (GH-15490) c3ea41e
Added the default implementation of visit_Constant which calls corresponding visitor for old constant nodes. It emits a deprecation warning (PendingDeprecationWarning in 3.8 and DeprecationWarning in 3.9) as a reminder that you finally will need to implement your own visit_Constant. You can temporary ignore them.
Note that the implementation in the stdlib is not future proof (and it should not, because visit_Constant will likely be removed at the same time or before removing classes Num and Str and removing properties "n" and "s" from Constant). In long term solution you should write something like:
Activity
asottile commentedon May 14, 2019
More fallout from the Constant change in https://bugs.python.org/issue32892
minimal reproduction:
asottile commentedon May 14, 2019
wrong bpo, this is the right one: https://bugs.python.org/issue32892
Carreau commentedon May 14, 2019
Would it be useful to add a default implementation of
visit_Constant(self, node)on NodeVisitor that go through all the isinstance() check and call the appropriate backward compatible method ?We would still have the simplification without having any breakage in backward compatibility.
That feels like best of both worlds ?
asottile commentedon May 14, 2019
There would still be a breakage for that if someone was defining py36+
visit_Constant(which would clobber theast.NodeVisitor.visit_Constantif we were to add it)Carreau commentedon May 14, 2019
Ok, it would still break in some cases, but that would still be a net improvement for codebase that do not override visit_Constant; right ?
We could also push the patch further if we really want and call explicitly NodeVisitor.visit_Constant before the overridden method in NodeVisitor.visit.
Not advocating for the second part, but minimal breakage and code repetition in libraries when we can.
asottile commentedon May 15, 2019
spent some more time thinking about this and I think we should strongly consider reverting. simplification in the core interpreter should not be weighed lightly against complexity and breaking changes for users.
the change is also unfortunate because it reduces the expressivity of the ast
as we discuss shims, I believe the intention is to remove the
Num/Str/ etc. layer eventually so it's really just delaying that.so my vote is to revert, keep the complexity in the compiler and out of user code
Carreau commentedon May 15, 2019
Playing Devil advocate here, but the complexity depends on what transformations user want to do; with the current state of 3.8, a user that wants to visit all immutable types can do with a single visit_Constant; once 32892 reverted; they would need to implement all of visit_Str,NamedConstant,Num,Bytes, and have it called the same visit_Constant.
serhiy-storchaka commentedon May 15, 2019
This is not a new case. This is exactly the same problem which has already been fixed in multiple other projects.
Could you show your real code Anthony? In all known opensource examples (astroid, pyflakes, genshi, chameleon, mako) the compatibility fix is as simple as
In return, you can remove several methods, such as visit_Str, visit_Num, etc, once you drop the support of Python versions <3.8.
AST is not stable. Virtually in every version the new nodes are added: for asynchronous constructions, for f-strings, etc, and the structure and meaning of existing nodes can be changed.
asottile commentedon May 15, 2019
The simplest case is just the addition of an
isinstancecheck:https://github.com/asottile/dead/blob/85f5edbb84b5e118beab4be3346a630e41418a02/dead.py#L165-L170
But I have another case where there's much more complex (sorry this one's private, I'll give the pseudo-code of it though which ends up in a whole mess of slow
isinstance(...)callsWhereas the opposite case (where handling all constants the same) is much much easier to simplify the code and not need the
Constantmess (if required)Maybe I haven't been in the community long enough but this is the first *removal* of the ast I've seen, and it makes all my uses of these functions objectively worse, and none of the cases get simpler (whereas there's an existing easy way to simplify constants already, without breaking the ast)
github search isn't a great measure of this but it's currently showing 10k+ usages of
visit_{Str,Num,Bytes}that would presumably be broken by this change: https://github.com/search?q=visit_Num+visit_Str+visit_Bytes&type=Code -- backward compatibility is very valuable, I would hope it isn't squandered for an internal cleanupserhiy-storchaka commentedon May 15, 2019
You can not use the same implementation of the visitor for Num, Str, NameConstant and Ellipsis, because all these classes use different attribute for saving the value (Ellipsis does not have it at all). For the same reasons you can not just pass the argument of visit_Constant() to visit_Str() -- they have different types.
No need to call generic_visit() from visit_Constant() -- Constant nodes should not contain AST nodes.
asottile commentedon May 15, 2019
ah yes, this is true -- maybe the better change would be to just add
@property valueto each of those instead of collapsing the classes? (If that's the actual convenience we're trying to achieve)correct there's no need, but it's a best practice to always call
generic_visitin allvisit_*methods, I have a linter I haven't finished up yet that checks this. And who knows if that'll be true in the future!isidentical commentedon May 19, 2019
What about adding visit_Constant to NodeVisitor for at least one relase period and call visit_Str, visit_Num etc?
TylerWince commentedon Jun 25, 2019
Another example of the breaking change here is in the security linter
PyCQA/bandit. It may be a simple addition of a check in the meta parser for the ast but I would tend to agree with Anthony around whether or not it is worth it.Anyone else have any thoughts on this since the conversation ended last month?
serhiy-storchaka commentedon Aug 26, 2019
New changeset c3ea41e by Serhiy Storchaka in branch 'master':
bpo-36917: Add default implementation of ast.NodeVisitor.visit_Constant(). (GH-15490)
c3ea41e
serhiy-storchaka commentedon Aug 26, 2019
New changeset 522a394 by Serhiy Storchaka (Miss Islington (bot)) in branch '3.8':
[3.8] bpo-36917: Add default implementation of ast.NodeVisitor.visit_Constant(). (GH-15490) (GH-15509)
522a394
serhiy-storchaka commentedon Aug 26, 2019
New changeset c238862 by Serhiy Storchaka in branch '3.7':
bpo-36917: Backport basic test for ast.NodeVisitor. (GH-15511)
c238862
serhiy-storchaka commentedon Aug 26, 2019
Thank you for your report and discussion Anthony.
Added the default implementation of visit_Constant which calls corresponding visitor for old constant nodes. It emits a deprecation warning (PendingDeprecationWarning in 3.8 and DeprecationWarning in 3.9) as a reminder that you finally will need to implement your own visit_Constant. You can temporary ignore them.
Note that the implementation in the stdlib is not future proof (and it should not, because visit_Constant will likely be removed at the same time or before removing classes Num and Str and removing properties "n" and "s" from Constant). In long term solution you should write something like:
Otherwise you can get other deprecation warnings or errors in future releases.