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

Antoine Pitrou solipsis at pitrou.net
Wed Oct 4 08:36:32 EDT 2017

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.

More information about the Python-Dev mailing list