-
-
Notifications
You must be signed in to change notification settings - Fork 572
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
Remove anytree #1912
Remove anytree #1912
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #1912 +/- ##
========================================
Coverage 99.32% 99.33%
========================================
Files 346 346
Lines 19135 19105 -30
========================================
- Hits 19006 18977 -29
+ Misses 129 128 -1
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this looks great, glad to be rid of anytree
!
Description
It seems like we can get away with not using
anytree
when creating expression trees, which saves a fair amount of overhead. Functionality likerender
still works fine, as long as the symbol has achildren
attribute.Symbol.new_copy
no longer needs to be used, but I have left the functions there in case we need to go back.Let's give it a couple of releases to be sure, but if things are working well without
anytree
we can also:Symbol.id
and implement__eq__
and__hash__
instead (previously, these were not implemented to avoid loops in anytree)model.new_copy
to just make shallow copiesI'll open an issue for that if this PR is approved.
Type of change
Please add a line in the relevant section of CHANGELOG.md to document the change (include PR #) - note reverse order of PR #s. If necessary, also add to the list of breaking changes.
Key checklist:
$ flake8
$ python run-tests.py --unit
$ cd docs
and then$ make clean; make html
You can run all three at once, using
$ python run-tests.py --quick
.Further checks: