You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In reference to #11, our team has been discussing Python 2.7 support, in addition to the Python 3.6 support that the code is currently written to. We certainly appreciate the contributions, but go back and forth on whether it makes sense to walk back code to support 2.7.
Our main concerns with supporting 2.7 are:
Soon to be deprecated.
Python 2.7 will no longer be supported by the community after January 1, 2020
Ability to take advantage of Python 3.x enhancements:
Undoing enhancements that are specific to Python 3. It seems counter intuitive to roll back Python 3 specific items to support a version of Python that will soon be deprecated.
Ability to use f and r strings make core more efficient and easier to read.
We've been looking at implementing type hinting. We'd like be able to take advantage of enforcing hints. In Python 2.7, we'd be limited to comment based type hinting, which would limit our ability to enforce hints.
Given this, we'd like to be able to support the community. We'd like to propose some options:
Continue supporting Python 3 only support out of the box.
Commit to supporting Python 2.7 and Python 3 until Jun 1, 2019. At which time, hier_config would likely be converted to Python 3 only. However, Python 2.7 versions would remain on pypi and the last release supporting Python 2.7 would be preserved in a python2 branch.
Create a fork of hier_config to specifically support Python 2.7.
The text was updated successfully, but these errors were encountered:
The reality is the infrastructure we work on is what the client says it is. Knowing enterprises, I would not expect it broad py3 support until after the next rhel release. I would hate to see forking so early in the process.
I think we can build a mutually beneficial relationship, e.g. we have already identified 2 issues, and have plans to extend the library. I appreciate the pain of it all, but it comes down to fstrings being the only thing you mentioned that is not supported in 2.7 (raw string is fine for 2.x, I just removed it, thinking it was another issue.) Additionally, the library scope is much broader if it does support 2.7.
I feel a bit dirty for saying so but I vote for option 2 and add that we consider mirroring the official Py2.7 deprecation date when that time approaches :-)
Okay. We'll include Python 2.7 support until the Python community ends support on January 1, 2020. The first release to support Python 2.7 will be 1.2.0, which we'll tag for release when #11 is merged.
In reference to #11, our team has been discussing Python 2.7 support, in addition to the Python 3.6 support that the code is currently written to. We certainly appreciate the contributions, but go back and forth on whether it makes sense to walk back code to support 2.7.
Our main concerns with supporting 2.7 are:
Soon to be deprecated.
Ability to take advantage of Python 3.x enhancements:
f
andr
strings make core more efficient and easier to read.Given this, we'd like to be able to support the community. We'd like to propose some options:
hier_config
would likely be converted to Python 3 only. However, Python 2.7 versions would remain on pypi and the last release supporting Python 2.7 would be preserved in apython2
branch.hier_config
to specifically support Python 2.7.The text was updated successfully, but these errors were encountered: