I am doing an exercise as a part of agile ux data mining
team, and I need to get a list of Python modules:
But this gives only the modules that were compiled into
specific interpreter, and I need a list of modules that are
de-facto included in stdlib standard.
I also need this for all Python versions, and be able to
fetch it as csv, json or html table format over webm so
that result of my work could be validated and experiment
repeated as necessary.
I see the data as the necessary step to organize a work
around "externally evolving standard library", so a way
to query it should be somewhat sustainable and obvious.
It might be possible to generate something from docs, like:
This way you get static information without ability to
version or refresh the info (still good to have anyway to
compare docs and other sources).
Or it may be a dedicated URL:
The result is HTML be default.
?format=csv - result is csv
I need in particular:
- module name
- files that comprise module sources
- os supported
So, basically I need an official support for this:
Because I don't have means to maintain this myself and
feel tired trying to think about how it can be maintained
If I have this mapping, I can make a diagram how many
patches per module are sitting there on the tracker, and
it may open a can of worms for many other fishy stats
that will be attractive for people to work on.
Actually, the code that sorts patches by modules is
already there in that repository. It is also unlicensed
to get it free from restrictions placed by copyright law
over distributed development, so it doesn't require me
or you to sign CLA to further develop it.
So, where is the first class info about the module structure of stdlib?
Where this info should be fetched from if accessed automatically from the web?
How it should be kept up to date for all Python versions?
I'm a potential GSoC participant, and I'm interested in the bug tracker
improvement idea. I had a brief look at what has already been
discussed on the mailing list and liked what I read.
I don't know anything about the code-review tools mentioned (Kallithea
and Phabricator), but I would be up to investigating how they could be
integrated. But I really like the idea of integrating a REST API to
roundup, but I'm not sure if that would be a python-core project or a
distinct roundup project (requireing mentors from the Roundup devs)?
But I'm very interested in doing a project with the python core team, so
if there are any other interesting ideas I'm definalty up to it. I
should perhaps ask around on the python-dev ML?
Since the PSF is looking for ideas and mentors for Google Summer of
Code, I was thinking about proposing and mentoring a project that aims
at further improving our bug tracker.
I'm writing to core-workflow in order to understand what features we
want and which ones have higher priority, so that I can put together a
There are currently two PEPs that are proposing changes to our infrastructure:
* PEP 462 - Core development workflow automation for CPython
* PEP 474 - Creating forge.python.org
These proposals will likely require changes to the bug tracker if we
want to have a solid integration with the new tools and they might
make for a good project, however it might still be too early to know
what we will actually need.
There are other changes that have been proposed in the past, in particular:
* Some features previously discussed on this ML and summarized at
* Some other miscellaneous features listed at
* Better integration with Rietveld (e.g. add messages to roundup
when someone posts a review)
* Smarter branch detection in patches (sometimes patches don't get
the review link)
* Patch analysis (information such as affected files could be
extracted from the files and used by Roundup)
* Reviewing and applying patches submitted on the meta-tracker
* Fix other issues listed on the meta-tracker
These (or a subset of these) might also make for a good project,
albeit less focused.
After discussing with Nick on IRC about this, I also sent an email to
roundup-devel about another possible project to be developed by
Roundup under the umbrella of the PSF: adding a RESTful interface (see
http://issues.roundup-tracker.org/issue2550734). This will also help
us with any future work might want to do to integrate our bug tracker
with other tools.
If you have any feedback let me know.