-
Notifications
You must be signed in to change notification settings - Fork 26
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
Generic enter/exit visitor to replace BaseNode.traverse and friends #97
Comments
I'm looking forward to retiring the The proposed I really liked it how you based the read-only For a read-write visitor, I'm looking at Python's |
Looking at their source [1], they're doing in-place modifications. That's an interesting way to get performance, as it avoids a lot of object creation and GC. One can't implement Maybe that's OK? Maybe we'll just add an explicit Clarification re [1] https://github.com/python/cpython/blob/2f1a317d5fdc45b9d714b067906f612f636ba08e/Lib/ast.py#L290-L311 |
Thanks for your thoughts, @Pike.
To document our discussion on IRC, this sounds like a good path forward. It allows us to separate two concerns: transformation and copying. The old For use-cases which require the original AST to remain intact, an explicit This highlights an interesting difference between the partial evaluator (#95) and the runtime interpreter which landed in #81 (whichis similar to the one in |
I've got a local branch, that I still need to polish. But I did some perf tests, and while a The perf test I'm doing is the search-and-replace code we have in Pontoon, https://github.com/mozilla/pontoon/blob/78c56b63a1233db0a4754136b0b4f57506ec4341/pontoon/batch/utils.py#L53-L62, to show a somewhat realistic example. Somewhat realistic because it also hits the parser, which is probably gonna be dominant here. Here are the perf results so far:
With that in mind, I'm going to add a deprecation note to |
In projectfluent#97, we deprecated `BaseNode.traverse`. It's now time to remove it. The reason it was still around is mostly for a niche in performance, but dedicated iterators are probably the way to go for that niche. That's what fluent.runtime does, for example.
In #97, we deprecated `BaseNode.traverse`. It's now time to remove it. The reason it was still around is mostly for a niche in performance, but dedicated iterators are probably the way to go for that niche. That's what fluent.runtime does, for example.
The simple read-only visitor we landed in #96 is great for performance, but doesn't cut it for actual transformations. I'm having a local branch, that I hope is generic enough to replace traverse.
Not happy with the name of it, I'm using
ContextVisitor
, because it usesenter
andexit
, but I can't really use python context managers, because you can't pass arguments to__exit__
.I'm implementing
.traverse()
as part of the patch tofluent.syntax
, but to make things more tangible, here's howtransforms_from
could look like. Compare with https://hg.mozilla.org/l10n/fluent-migration/file/797c19359d4b/fluent/migrate/helpers.py#l43 through line 123.The text was updated successfully, but these errors were encountered: