python
Idea: mention 3rd party "extended stdlib" modules in developer guide
We have a section in the developer guide specifically on proposing changes to the standard library: http://cpython-devguide.readthedocs.io/en/latest/stdlibchanges.html
One of the alternatives to standard library additions that frequently needs to be brought up on python-ideas is the possibility of adding to one of the "stdlib enhancement" projects that adds assorted general purpose programming utilities that are nevertheless considered sufficiently niche use cases that they don't make the cut for standard library inclusion (or, alternatively, folks want them now, rather than having to wait for a new CPython feature release)
Perhaps it would make sense to specifically mention some of those projects in this part of the developer guide? The main two that come to mind are:
- boltons: https://boltons.readthedocs.io/
- more-itertools: https://pypi.python.org/pypi/more-itertools/
There are probably others, but once we start the list, it's relatively easy to add new entries, but with no list at all, it's unlike anyone (else) would suggest adding one.
Is the goal having a link you can post on python-ideas to avoid redundant discussion?
Folks proposing additions to the stdlib usually want to solve the problem the stdlib doesn't have X, often overlooking all the additional problems that come with adding X. Telling them "use Y instead" doesn't really solve their (perceived) problem, so I think it would be better to shift the focus on explaining why X shouldn't be added, and then offering alternatives such as the ones you proposed. I don't think however we need to start a list -- the wiki might be a better place for that.
I would be fine with adding a section that contains a list of commonly proposed ideas, why they are not good additions, and what alternatives are available. [0] E.g.:
- Adding more itertools: itertools already provides basic building blocks that can be used to build higher-level functions. These functions can be implemented in several different ways depending on the specific use case, and it's easier to do so rather than trying to provide in the stdlib generic functions able to cover all the cases. It is also possible to use 3rd party packages such as more-itertools that provide additional functions.
Note that something similar has been already discussed in https://mail.python.org/pipermail/python-ideas/2013-August/022829.html and https://wiki.python.org/moin/FrequentlyRejectedIdeas (even though these also cover removing and changing existing features).
[0]: this is out of the scope of this issue, but the whole page could 1) tell what additions are acceptable and what are not (with list/examples on both sides); 2) describe the process to add something to the stdlib. As it is, the page is a wall of text where reasons and process are intertwined.
Yeah, it's mainly a matter of explaining that stdlib inclusion comes with significant downsides (such as the increased cognitive burden for future learners, that only being available in future versions creates high barriers to adoption, and that the stdlib imposes an inherently slow iteration cycle for adjusting the API in response to real world usage), and that in many cases using an add-on module that offers a consistent API across different Python versions is going to be a better approach.
I like the structure you suggest for "Adding more itertools". An equivalent for boltons would be "Adding more collection types" (where "an overabundance of choice" is a key design concern)
Are you proposing to include a curated list of third party modules that enhance or replace stdlib modules? I think it would have to be curated, since there may be competing replacements. Would projects like unittest2 and contextlib2 qualify? What about aiosmtpd which is a much better (IMHO :) replacement for smtpd.py?
If the list needs to be curated and maintained, it should probably go to the wiki. Mentioning projects like unittest2 and contextlib2 is a good idea, but it's enough to provide a couple of examples to show that such projects exist -- people can then go look for what they need themselves.
I'm looking for something a bit more authoritative than that - a way for stdlib maintainers to say "If we say no, consider proposing your idea over here instead".
A list on the wiki doesn't provide that to the same degree, since it's then collectively maintained by the community without a defined review and approval process, rather than specifically by the stdlib maintainers. With the devguide on GitHub, anyone is still free to make suggestions for additions to the list, but actually accepting those suggestions would still be a core dev responsibility.
On Feb 24, 2017, at 09:18 PM, Nick Coghlan wrote:
I'm looking for something a bit more authoritative than that - a way for stdlib maintainers to say "If we say no, consider proposing your idea over here instead".
+1