Drop Python 2 and 3.4 support #229

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.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Drop Python 2 and 3.4 support #229

Drop Python 2 and 3.4 support #229

Commits on Jun 25, 2021