> A problem with overloading the Categories field with Python version > compatability information is that it makes for a poor user-interface. On > the release page for a package, I'd rather see a Python Version field > than having to look through a potentially large list of Categories. That's an issue of how the page is rendered. Hence I asked for a full specification. > There is a "Py Version" field for file uploads (which I'd really like to > tweak the UI to read "Python Version") Feel free to submit a patch (or perhaps just a bug report). > maybe if you could specify for > uploads of the "source" type the Python compatability of the source > file? Even without Python 3 it would be nice to upload a source file > and indicate that you've used a Python 2.5 or 2.6ism in your code (or > made use of newer standard library modules). I think that deviates from the subject, which is "3.1 focus", and AMK's request to let people find out whether a package runs on Python 3. > Although this raises the question, what is the recommended practice for > version numbering for distributions attempting to support both Python 2 > and 3? Say I have a distribution that I've made work with Python 2.6 and > can run on Python 3 after running it through 2to3. The source code is > different so that to me suggests different version numbers - but the API > will be the same, so maybe the same version number should be used? That > is should there be? It all depends on how you do the porting. If all it takes to run the program through 2to3 to make it port correctly, I recommend to use the build_py_2to3 build step of distutils in 3.0. Then the same source can be installed for 2.x and 3.x, with no modifications. Regards, Martin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4