pdoc
pdoc copied to clipboard
pdoc3
Python 3.5 "end of life"
With Python 3.5.x having reached its end of life/support, we can begin to use "advanced" features from Python 3.6:
- f-strings
- variable annotations over type comments https://github.com/pdoc3/pdoc/blob/651d1a8d7bf0c8964839dd1997227ab11f57df24/pdoc/init.py#L249-L250
Additionally:
- Review
version_infochecks https://github.com/pdoc3/pdoc/blob/cf084313bdfa6c9fa24a0f28893a77b3209a8816/setup.py#L5-L6 https://github.com/pdoc3/pdoc/blob/cf084313bdfa6c9fa24a0f28893a77b3209a8816/setup.py#L61
Personally, f-strings is the only thing that comes to mind as the significant feature added in Python 3.6 that is relevant to pdoc. From going through the project codebase, I've noticed multiple methods for string formatting is being used (single quotes, double quotes, %s substitution, .format), so moving to f-strings is definitely a great opportunity to standardize that.
Just want to throw the question though, how will moving the supported base version of Python from 3.5+ to 3.6+ impact pdoc's users? Updating all docs to use f-strings would be more of a formatting change rather than a feature added that augments fuctionality. Genuine question as I'm not familiar w/ the user base.
If we do move ahead w/ bumping to Python 3.6+ and standardizing string formatting to using f-strings, I would gladly submit a PR for that!
Just want to throw the question though, how will moving the supported base version of Python from 3.5+ to 3.6+ impact
pdoc's users? Updating all docs to use f-strings would be more of a formatting change rather than a feature added that augments functionality. Genuine question as I'm not familiar w/ the user base.
Neither am I, really. :smiley: Debian Buster with Python 3.7 was released over a year ago, and Python 3.6 was already in Ubuntu 18.04 LTS. CI platforms such as Travis and GH Actions take Python version as a parameter, regardless of distro. So even as far as stable and late environments go, few users should be affected IMO. F-strings and related changes would just count as refactoring towards an improved and future-compatible codebase. The first version to feature those changes would then mark a point of incompatibility with <Py3.6, with Py3.5 users happily (:crossed_fingers:) stuck on whatever version released by then (say, 9.2 or so). If it later turns out there are some grave fixes to cater to a large important group of excluded users, we can run a backport branch, but I really don't count on it.
PR welcome. :+1:
Submitted a PR!
Should there be a code style section added to CONTRIBUTING.md to specify formatting preference to keep things neat moving ahead?
Should there be a code style section added to CONTRIBUTING.md to specify formatting preference to keep things neat moving ahead?
Rather still I'd have it covered in CI like code style currently is, but flake8 is missing anything appropriate. :man_shrugging:
Did you, perchance, take this for Hacktoberfest? Asking to mark it accepted, because I might take a further couple more days before it gets merged (and you might see some conflicts to resolve). :grimacing:
Did you, perchance, take this for Hacktoberfest? Asking to mark it accepted, because I might take a further couple more days before it gets merged (and you might see some conflicts to resolve). 😬
Yes indeed I arrived here from Hacktoberfest. If you can add the hacktoberfest-accepted label to the PR, that will be great!