You can read the documentation on how to use caniusepython3 from its PyPI page. A web interface is also available.

On PyPI each project can specify various trove classifiers (typically in a project's setup.py through a classifier argument to setup()). There are various classifiers related to what version of Python a project can run on. E.g.:

Programming Language :: Python :: 3
Programming Language :: Python :: 3.0
Programming Language :: Python :: 3.1
Programming Language :: Python :: 3.2
Programming Language :: Python :: 3.3
Programming Language :: Python :: 3.4

As long as a trove classifier for some version of Python 3 is specified then the project is considered to support Python 3 (project owners: it is preferred you at least specify Programming Language :: Python :: 3 as that is how you end up listed on the Python 3 Packages list on PyPI; you can represent Python 2 support with Programming Language :: Python).

The other way is through a manual override in caniusepython3 itself. Projects ends up on this list because:

• They are now part of Python's standard library in some release of Python 3
• Their Python 3 port is under a different name
• They are missing a Python 3 trove classifier but have actually been ported

If any of these various requirements are met, then a project is considered to support Python 3 and thus will be added to the manual overrides list. You can see the list of overrides when you use caniusepython3's CLI with verbose output turned on.

If a project has Python 3 support in a release on PyPI but they have not added the proper trove classifier, then either submit a pull request or file an issue with the name of the project and a link to some proof that a release available on PyPI has indeed been ported (e.g. PyPI page stating the support, tox.ini file showing tests being run against Python 3, etc.). Projects that have Python 3 support in their version control system but not yet available on PyPI will not be considered for inclusion in the overrides file.

Typically projects which have not switched to Python 3 yet are waiting for:

• A dependency to be ported to Python 3
• Someone to volunteer to put in the time and effort to do the port

Since caniusepython3 will tell you what dependencies are blocking a project that you depend on from being ported, you can try to port a project farther down your dependency graph to help a more direct dependency make the transition.

Which brings up the second point: volunteering to do a port. Most projects happily accept help, they just have not done the port yet because they have not had the time ("volunteering" can also take the form of paying someone to do the port on your behalf). Some projects are simply waiting for people to ask for it, so even speaking up politely and requesting a port can get the process started.

If you are looking for help to port a project, you can always search online for various sources of help. If you want a specific starting point there are HOWTOs in the Python documentation on porting pure Python modules and extension modules.

• Dropped Python 2.6 and 3.2 support

• Fix a failing test due to the assumed unported project being ported =)
• Work around distlib 0.2.0 bug (patch by @rawrgulmuffins)
• Usual override updates

• Log more details when running under -v (patch by @msabramo)
• Print a 🎉 -- it's a party popper in case you have mojibake for it -- when the terminal supports it and there are no blocking dependencies (patch by @msabramo)
• Fix compatibility with pip 6.1.0 (patch by @msabramo)
• Fix warning of missing logger when using setup.py integration (issue #80; patch by @msabramo)
• Remove checkers for filter, map, range, and zip as they have been improved upon and merged upstream in Pylint
• Updated outdated documentation
• Usual override updates

• Introduce caniusepython3.pylint_checker which extends pylint --py3k with very strict porting checks
• Work around a bug in distlib
• Compatibility fix for pip 6.0 (issue #72)
• Usual override updates

• Suppress an xmlrpclib.Fault exception under Python 2.6 when trying to close an XML-RPC connection (can't close a connection under Python 2.6 anyway and the exception has only been seen on Travis)
• Move to unittest2 as a developer dependency
• Move mock to a developer dependency
• Usual override tweaks

• Avoid infinite recursion when there is a circular dependency (issue #60)
• Usual overrides tweaks

• Normalize the names of direct dependencies for proper Python 3 compatibility checking (issue #55)
• Properly set the logging details when executed from the entry point
• Usual overrides tweaks

• Verbose output will print what manual overrides are used and why (when available)
• Fix logging to only be configured when running as a script as well as fix a format bug
• Usual override updates

• Fixed setup.py caniusepython3 to work with extras_require properly
• Fix various errors triggered from the moving of the just_name() function to a new module in 2.0.0 (patch by Vaibhav Sagar w/ input from Jannis Leidel)
• Usual overrides tweaks (thanks to CyrilRoelandteNovance for contributing)

• Fix lack of unicode usage in a test
• Make Python 2.6 happy again due to its distate of empty XML-RPC results

• Fix syntax error

• Tweak overrides
• -r, -m, and -p now take 1+ arguments instead of a single comma-separated list
• Unrecognized projects are considered ported to prevent the lack of info on the unrecognized project perpetually suggesting that it's never been ported
• Introduced icanusepython3.check()

• Fix -v to actually do something again
• Tweaked overrides

• -r accepts a comma-separated list of file paths

• Setuptools command support
• Various fixes

Initial release.