Python 3.5 "end of life"

[kernc]

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
  

  pdoc/pdoc/__init__.py

  Lines 249 to 250 in 651d1a8

  	vars = {} # type: Dict[str, str]
  	instance_vars = {} # type: Dict[str, str]

Additionally:

• Review version_info checks
  

  pdoc/setup.py

  Lines 5 to 6 in cf08431

  	if sys.version_info < (3, 5):
  	sys.exit('ERROR: pdoc requires Python 3.5+')

  
  

  pdoc/setup.py

  Line 61 in cf08431

  python_requires='>= 3.5',

[tnwei]

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!

[kernc]

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. 😃 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. 👍

[tnwei]

take

[tnwei]

Submitted a PR!

Should there be a code style section added to CONTRIBUTING.md to specify formatting preference to keep things neat moving ahead?

[kernc]

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. 🤷‍♂️

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). 😬

[tnwei]

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!