Drop Python 2 and 3.4 support #229
Conversation
peternowee
force-pushed
the
feature/drop-py2
branch
from
ae91cdc
to
401787e
Compare
|
Just noting that 2019 Python's developers survey just came out and Py3.5 usage is really low, 4% of all PY3. Actually 90% comprises just 3.6 + 3.7 + 3.8. |
Wow, that is a big difference with the pydot download stats. I just had another look at them and they still show usage of Python 3.5 around 25%. And that is of Python 2+3 overall, so it is even higher when viewed as a proportion of PY3 only: (25%/80%=) 31% of PY3, vs. the 4% reported by the JetBrains survey. Some possible explanations I can think of right now:
I am not so sure if I would easily give up 5% of our user base just for some new features for us pydot developers. Anyway, luckily, you add "for all new releases after 2020", so that means at least the official Python support for PY3.5 has also been already dropped (2020-09-13), and as I said earlier, I am willing to reconsider then. I assume that by the end of 2020, the pydot download statistics will also have shown a big drop in PY3.5. But currently, it is only May 2020 and I am still hoping this PR gets merged earlier than September or the end of 2020. Also again, I am willing to reconsider earlier if there is a need for it, but then again I would like to know if you use PY3.6-specific functionality in your open PR now, or need it for something else you are working on? |
|
No, no , it's nothing to do with my functionality needs. |
This starts a series of commits to drop support for Python 2 and 3.4 as discussed in [pydot#171][171] and [pydot#229][229]. | Python version | Python EOL | PyPI 2020-05-02 | PyPI 2021-06-21 | |----------------|------------|-----------------|-----------------| | Python 2.7 | 2020-01-01 | 26% | 12% | | Python 3.4 | 2019-03-18 | 0% | 0% | | Python 3.5 | 2020-09-30 | 27% | 3% | | Python 3.6 | 2021-12 | 21% | 14% | | Python 3.7 | 2023-06 | 23% | 51% | | Python 3.8 | 2024-10 | 3% | 13% | | Python 3.9 | 2025-10 | 0% | 6% | | Python 3.10 | 2026-10 | - | 0% | EOL : End of life, from End of security support on [Wikipedia][1]. PyPI: Python Package Index statistics for pydot from [PyPIstats.org][2]. Without support for Python 2, wheel distributions of pydot can [no longer be marked as "universal"][3], so removing that from `setup.cfg`. **USER FEEDBACK REQUESTED** We are considering if pydot 2.0 should drop support for Python 3.5 and 3.6 as well. If this would affect you, please leave a comment in [pydot#268][268]. [1]: https://en.wikipedia.org/w/index.php?title=History_of_Python&oldid=1022680403#Table_of_versions [2]: https://pypistats.org/packages/pydot [3]: https://github.com/pypa/packaging.python.org/blob/44313e5db4d729eede0bcb91c08d6ec93e89c5c8/source/guides/dropping-older-python-versions.rst#dealing-with-the-universal-wheels [171]: pydot#171 (comment) [229]: pydot#229 [268]: pydot#268
This starts a series of commits to drop support for Python 2 and 3.4 as discussed in [pydot#171][171] and [pydot#229][229]. | Python version | Python EOL | PyPI 2020-05-02 | PyPI 2021-06-21 | |----------------|------------|-----------------|-----------------| | Python 2.7 | 2020-01-01 | 26% | 12% | | Python 3.4 | 2019-03-18 | 0% | 0% | | Python 3.5 | 2020-09-30 | 27% | 3% | | Python 3.6 | 2021-12 | 21% | 14% | | Python 3.7 | 2023-06 | 23% | 51% | | Python 3.8 | 2024-10 | 3% | 13% | | Python 3.9 | 2025-10 | 0% | 6% | | Python 3.10 | 2026-10 | - | 0% | EOL : End of life, from End of security support on [Wikipedia][1]. PyPI: Python Package Index statistics for pydot from [PyPIstats.org][2]. Without support for Python 2, wheel distributions of pydot can [no longer be marked as "universal"][3], so removing that from `setup.cfg`. **USER FEEDBACK REQUESTED** We are considering if pydot 2.0 should drop support for Python 3.5 and 3.6 as well. If this would affect you, please leave a comment in [pydot#268][268]. [1]: https://en.wikipedia.org/w/index.php?title=History_of_Python&oldid=1022680403#Table_of_versions [2]: https://pypistats.org/packages/pydot [3]: https://github.com/pypa/packaging.python.org/blob/44313e5db4d729eede0bcb91c08d6ec93e89c5c8/source/guides/dropping-older-python-versions.rst#dealing-with-the-universal-wheels [171]: pydot#171 (comment) [229]: pydot#229 [268]: pydot#268
Specifically for AppVeyor: - Explicitely choose the image to be used (Visual Studio 2019), as the default image (Visual Studio 2015) does not have Python 3.8 *in Miniconda*. There is no image with Python 3.9 in Miniconda available yet. [1] - Add `fast_finish` option [2] to prevent running subsequent jobs if the first job fails. - Normally only test the oldest and the newest Python versions pydot supports, which are currently Python 3.5 (EOL) and 3.9. However, now using 3.6 instead of 3.5, because AppVeyor fails to install pyparsing in 3.5, and using 3.8 instead of 3.9 because 3.9 is not available on AppVeyor yet (see above). - Correct a typo in the `init` that prevented correct printing of environment variables. [1]: https://www.appveyor.com/docs/windows-images-software/#miniconda [2]: https://www.appveyor.com/docs/build-configuration/#failing-strategy
`dot_parser.py` currently has 6 functions that still use `str` as a
parameter name. This will cause conflicts if inside the function body
a reference to Python's built-in [`str` type][1] needs to be made.
Specifically, as part of the clean up of old Python 2 code, the next
commit will introduce direct usage of the built-in `str` in two of
these functions. The concurrent use of `str` as a function parameter
name would then lead to name collisions and errors such as:
File "dot_parser.py", line 349, in push_edge_stmt
elif isinstance(toks[2][0], str):
TypeError: isinstance() arg 2 must be a type or tuple of types
Commit 842173c already renamed the parameter for one particular
function from `str` to `s` in 2008. This commit will now do the same
for the remaining functions.
Further notes:
- None of the affected functions actually use the parameter (`str`, now
`s`) in their function bodies.
- The functions themselves are passed to `pyparsing.setParseAction()`
as callback functions. The docstring of that method also uses the
parameter name `s` in the example callback signature. However, the
actual parameter name is irrelevant for pyparsing (2.4.7), as it uses
positional arguments when actually calling the callback.
- The affected functions contain 3 format strings that use `{s}` as a
replacement field name. Other than perhaps being slightly disturbing
to the human reader, these do not actually collide with the function
parameters named `s`, so leaving them as-is for now. A future change
to f-strings would be a better way to resolve the confusion.
[1]: https://docs.python.org/3/library/stdtypes.html#str
Just a very basic cleanup, made with some help from 2to3. Includes the removal of intermediairy variable `str_type`, which held the string type for either Python 2 or 3, replacing it with the string type for Python 3 `str`. The previous commit prepared for this by removing the conflicting uses of the name `str` as function parameter names.
peternowee
force-pushed
the
feature/drop-py2
branch
from
401787e
to
4d45fff
Compare
|
Rebased to master. 1st commit: Drop Python 2 and 3.4: Update Metadata, ChangeLog This starts a series of commits to drop support for Python 2 and 3.4 as discussed in pydot/pydot#171 and #229.
EOL : End of life, from End of security support on Wikipedia. Without support for Python 2, wheel distributions of pydot can no longer be marked as "universal", so removing that from USER FEEDBACK REQUESTED 2nd commit: Drop Python 2 and 3.4: Update CI configuration Specifically for AppVeyor:
3rd commit: Stop using
Specifically, as part of the clean up of old Python 2 code, the next commit will introduce direct usage of the built-in Commit 842173c already renamed the parameter for one particular function from Further notes:
4th commit: Drop Python 2 and 3.4: Clean up PY2-specific code Just a very basic cleanup, made with some help from 2to3. Includes the removal of intermediairy variable 5th commit: Drop Python 2 and 3.4: Bump black target-version (No further details.) Additional remarks:
|
peternowee
changed the title
UPDATE 2021-06-25: Updated description in my comment of 2021-06-25 below.
Original description (outdated)
1st commit: Drop Python 2 and <=3.4 support, add 3.8 support
Why support for Python 3.5 is not dropped yet:
For further details, see pydot/pydot#171.
2nd commit: Drop Travis CI tests Python 2, 3.4, add Python 3.8
Also removes the workaround for the Python 3.7 test environment added by commit eb7aef1. It is no longer needed by travis-ci.com.
3rd commit: Change AppVeyor tests to Python 3.5 and 3.8
Drop the test for Python 2 now we no longer support that.
Also:
fast_finishoption to prevent running subsequent jobs if the first job fails.initthat prevented correct printing of environment variables.Additional remarks:
fast_finishis off, but both still fail because of issue Inconsistent GraphViz output on AppVeyor/Windows/Anaconda #213.CC: @ankostis