Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
Sunsetting Python2
See original GitHub issueI just wrote some code, and got bitten by the fact that it wasn’t supported by python2 (along the lines of a, *b = [1, 2, 3]). The advanced unpacking features in python3 are incredibly useful for code like this, but can’t be used due to the current need to maintain python2 support. Would it be possible to get rid of python2 support soon?
I’d love to force everyone to use python3.6 (released December 2016), but I realize that may be a bit overzealous. However, forcing at least python3.5 (released September 2015) would allow additional unpacking generalizations (e.g. a, *b, c = [1, 2, 3, 4]). Wikipedia has a list of release dates for those interested.
Thoughts?
Issue Analytics
- State:
- Created 5 years ago
- Reactions:1
- Comments:7 (7 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
My $0.02 - I think it’s an okay idea, but cclib should really set out a specific timeframe (e.g., end of 2018) and substantially change the version number (e.g., cclib-2.x will only work with Py3).
While there’s a strong change towards Python3 in the entire science “stack,” the deadline is usually more like 2019-2020: http://python3statement.org
As per dev discussion, we will be dropping Py2 for v1.7 - separately from QCElemental and other changes that could be related.