[Python-Dev] Reorganize Python categories (Core, Library, ...)?

[Antoine Pitrou]

On Wed, 4 Oct 2017 11:52:32 +0200
Victor Stinner <victor.stinner at gmail.com> wrote:
> 
> It's also hard to find open bugs of a specific module on
> bugs.python.org, since almost all bugs are in the very generic
> "Library" category. Using full text returns "false positives".
> 
> I would prefer to see more specific categories like:
> 
> * Buildbots: only issues specific to buildbots
> * Networking: socket, asyncio, asyncore, asynchat modules
> * Security: ssl module but also vulnerabilities in any other part of
> CPython -- we already added a Security category in NEWS/blurb
> * Parallelim: multiprocessing and concurrent.futures modules

This is mixing different taxonomies and will make things ambiguous.  If
there's a crash in socket.sendmsg() that affects mainly
multiprocessing, should it be in "Networking", "Security" or
"Parallelism"?  If there's a bug where SSLSocket.recvinto() doesn't
accept some writable buffers, is it "Networking" or "Security"? etc.

I agree with making the "Library" section finer-grained, but then
shouldn't the subsection be simply the top-level module/package name?
(e.g. "collections", "xml", "logging", "asyncio", "concurrent"...)

Also, perhaps the "blurb" tool can suggest a category depending on
which stdlib files were modified, though there must be an easy way for
the committer to override that choice.

> I don't think that we need a distinct categoy for each module. We can
> put many uncommon modules in a generic category.

What is the problem with having a distinct category for each module?
At worse, the logic which generates Docs from blurb files can merge
some categories together if desired.  There's no problem with having a
very fine-grained categorization *on disk*, since the presentation can
be made different.  OTOH if the categorization is coarse-grained on
disk (such is the case currently), the presentation layer can't
recreate the information that was lost when committing.

Regards

Antoine.