-
Notifications
You must be signed in to change notification settings - Fork 288
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
Python 3 deprecation fixes (including Preparing for Python 3.9) #820
Python 3 deprecation fixes (including Preparing for Python 3.9) #820
Conversation
Codecov Report
@@ Coverage Diff @@
## master #820 +/- ##
==========================================
+ Coverage 84.02% 84.18% +0.16%
==========================================
Files 74 74
Lines 3124 3061 -63
==========================================
- Hits 2625 2577 -48
+ Misses 499 484 -15
Flags with carried forward coverage won't be shown. Click here to find out more.
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.
Out of curiosity is the name "abc" a reasonable acronym for something, or is it some legacy hackiness? If hackiness, I wonder if there's some nicer name to import as. If I am reading "collections.Iterable" it's readable, but reading "abc.Iterable" is kind of out of left field for someone like me who isn't deep into Python arcana :)
abc -> abstract base classes |
Ah, that does sound overly generic to be honest since that's a basic computer science term that doesn't tell us anything about what's being abstracted beyond a "class", which isn't what actually going on here. My personal preference would be that we use a descriptive name. |
I agree about the
Looking at the PEP that introduced this module (https://www.python.org/dev/peps/pep-3119/), it turns out there is just a root level Looking at how six handles this, it uses the rename Side question for the community: How much of a problem would adding a dependency on six be? It's considered the standard for many of the Python 2/3 interoperability problems and would also flag the places in code that can be scrubbed when we drop Python 2 support. |
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.
Thanks for the change!
The six library is a lightweight and robust dependency, in my experience ~ I'm not a Python guru, but six has never caused me a maintenance issue, so with that caveat, it gets a thumbs up from me. |
I'm going to drop the six library thing into an issue to allow that discussion to have it's own place. |
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.
One question in here, and I haven't followed the discussion fully, but this fixes the code but doesn't add the CI support - is that a mistake? If we're going to fix the code, should we also just add CI support? It seems like we're committing to supporting Python3.9 at that point? That would also imply updating the badge.
…uilds - added 3.9 and corrected it still having 3.6 and missing 3.8.
…ch the python 3 naming rather than python 2.
…e context about the Python 3.9.0/pybind11 bug.
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 is great, thanks.
We can integrate the 6 stuff in a future PR.
Thanks Eric!
Link the Issue(s) this Pull Request is related to.
Addressed deprecation warning:
We do this by importing
abc
from collections where available (Python 3.3+), otherwise we aliascollections
asabc
.This fixes OTIO in Python 3.9.
Also addressed:
__next__
(favored instead ofnext
in Python 3.0+) - PEP 3114inspect.getfullargspec
rather thaninspect.getargspec
Reference associated tests.
Existing tests covered the use cases already, under Python 3.9 they were failing. I successfully ran the test suite in Python 3.9 locally and verified the deprecation warnings are no longer dropping to the shell in other versions.
Python 3.9.0 support is not explicitly added due to a known intermittent crash that can be caused by the combination of Python 3.9.0 and pybind11. See #828 for more context.