-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Request For Python 3.x As Primary Python Supported Version #1295
Comments
I'll also pull my reply from #1091: I agree with this. If Python 3.5 is taken as the minimum version (which is really reasonable in my opinion), type hinting can be built directly into the generated code, which would (in my opinion) greatly improve the usability of troposphere in an IDE. |
Thank you for opening this issue and starting the discussion. I've had thoughts about deprecating Python2 support or switching over to using 3to2 (instead of 2to3). I just don't have a good read on the community on how many people are still using Python2. Due to distro needs, I've been limiting language features to even support Python 2.6. Some changes I'm thinking for troposphere 3.0 would be auto-generation of all the objects using the resource specification documents via an augmented gen.py that I'm working on. The current thought is to use yaml files to derive validation overrides for properties and moving the validation code into separate files as well for easy inclusion into the generated code. This would allow for more rapidly releasing new versions based on CF changes (as long as the resource specs are updated) rather than the hand coding or tweaking needed with (the hackish) gen.py. I'd be interested to hear comments on this approach. |
@markpeek I think a lot of it is that Python 2 is getting EOL'ed around this time next year. If people are still on that it's going to be pretty problematic down the road. Also, they might still be on Python 2 simply because Troposphere isn't Python 3 out of the box (the conversion script, while exists, can slightly complicate the process of deploying troposphere). Also happy with anything that can speed up releases, as we depend on troposphere to handle CF template generation since the usual way doesn't scale too well. |
For what it's worth I am one of the people that @cwgem is talking about. The only reason I have Python 2 even installed on my dev box is because of Troposphere. I use Python 3 for everything else I do. |
Per this discussion, you should only need python 2 if you develop code to go into the troposphere code. If you're developing CloudFormation templates with troposphere, you should be able to do that with Python 3 only. Still not sure how many people still use Python 2 for their development but I will be glad to move to Python 3 only when it becomes feasible from a community and/or tooling perspective. |
@markpeek Another issue is that pip gives this warning under Python 2.7:
This means at some point in the EOL future either pip will need to be pinned to the last supported 2.7 version or the inability to pip install will become a hard block. |
This can be closed. Troposphere 3.0 only supports Python 3.6+. |
This is related to #1091 , so I'll pull my comment from there:
Python 2.7 is EOL in January of 2020, giving a year before it's no longer officially supported. There doesn't seem to be any reasonable need to keep things at python 2 any longer. Instead of using a script to generate a python 3 version it feels like master should be converted to python 3 and continue from there.
The text was updated successfully, but these errors were encountered: