[Python-ideas] Proposing additions to the standard library

[Jonathan Crall]

@Steve, this is just the sort of feedback I was looking for. Small and
conservative additions make sense. I definitely think that some functions
do fit into existing stdlib modules. For instance, AutoDict might go in
collections.

Sorry, some of these aren't descriptive enough, and if you're trying to
> make a pitch for these features.

...

My advice is to collate the functions you want to add into groups of
> related functionality.


Makes sense. I figured that my original list had too may entries to do that
for, or else the email would explode. Separating each small group into its
own thread will allow me to describe the specific function without writing
a novel.

Sometimes there's a good, useful function than doesn't get added because
> there's no reasonable place to put it. For example, a "flatten" function
> has been talked about since Python 1.x days, and we still don't have a
> standard solution for it, because (1) it isn't clear *precisely* what it
> should do, and (2) it isn't clear where it should go.


The flatten example is good to know about. Is there a link to this
discussion or a summary of it? I would think flatten could go in itertools,
but clearly there must some reason why its not there. I imagine the
duplication with it.chain.from_iter + "There should be one-- and preferably
only one --obvious way to do it."? As for what it should do, I'm guessing
the controversy was over flattening one level vs all levels? That makes
sense and is good to know. I guess I won't pick `flatten` as one of my
first functions to pick for a writeup. On a similar note, do you (or anyone
else) have an intuition for which of these functions --- judging by name
only (so you don't have to click any links) --- might be the least
controversial? I'm not very good at judging controversy, which is one of
the main reasons for this initial email.

Maybe `expandpath` to os.path? Or perhaps start with ub.modname_to_modpath
and
ub.modpath_to_modname to importlib? Maybe some of the dict-methods? Perhaps
I'm overestimating the clear usefulness of any of these functions to the
stdlib?

On Sat, Nov 10, 2018 at 9:14 PM Steven D'Aprano <steve at pearwood.info> wrote:

> On Sat, Nov 10, 2018 at 08:36:52PM -0500, Jonathan Crall wrote:
> > I'm interested in proposing several additions to the Python standard
> > library, and I would like more information on the procedure for doing so.
> > Are all additions done via a PEP?
>
> Not necessarily. Small, obvious enhancements can go straight to the
> bug tracker. The tricky part is deciding what is "obvious".
>
> Sometimes there's a good, useful function than doesn't get added because
> there's no reasonable place to put it. For example, a "flatten" function
> has been talked about since Python 1.x days, and we still don't have a
> standard solution for it, because (1) it isn't clear *precisely* what it
> should do, and (2) it isn't clear where it should go.
>
> Given that once something gets added to the std lib, it is hard to
> remove it or even rename it, its better to be conservative about adding
> things and leave it to third party libraries to cover the gaps.
>
>
> > If not what is the procedure. If so, I've
> > read that the first step was to email this board and get feedback.
>
> That's a good idea. If the enhancement request isn't both small and
> obvious, or is the least bit controversial, you'll usually be sent back
> here.
>
>
> > I have a library called `ubelt` that contains several tools that I think
> > might be worthy of adding to the standard library.
>
> Generally speaking, we don't typically add grab-bags of random utility
> functions. There is no "utilities" or "toolbox" module in the std lib.
>
>
> [...]
> > Here is a tentative list of interesting functions. Hopefully the names
> are
> > descriptive (if not, see docstrings: https://github.com/Erotemic/ubelt)
>
> Sorry, some of these aren't descriptive enough, and if you're trying to
> make a pitch for these features, you ought to give at least a
> one-sentence explanation of them here in the email. You will lose half
> your audience as soon as you ask them to click through to a link, and
> even if they do, that risks splitting the discussion across two places.
>
> My advice is to collate the functions you want to add into groups of
> related functionality, find the class or module in the std lib where you
> think they belong, and begin a new thread for each group. E.g. "New dict
> methods", "New importlib functions".
>
>
> --
> Steve
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>


-- 
-Jon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20181110/4c9b04e3/attachment.html>