[Python-ideas] bool.from_config_str()

[Bar Harel]

I do believe something like that, but with a better name should exist.
I have seen countless implementations for the same thing done over and over
again.
The whole point of a good standard library is to prevent repetition.

The funniest thing is that I personally use distutils.util.strtobool.

The fact that the same concept exists twice even in the standard library
and I wouldn't be surprised to see third or fourth implementation somewhere
in there, should be somewhat alarming.

Perhaps a utility function module, much like distutils.util should be
introduced.

distutils.dir_util.mkpath is also something I often use.
Maybe even renaming that forgotten module and raising awareness is the
solution.Another nice example is the itertools recipes. Things that people
just re-implement over and over again.
tl;dr: My suggestion is a utility module containing many implemented recipes
shortening many commonly used patterns. The only question is how to prevent
over-extending it with lots of niche and less-used ones.

On Mon, Jun 13, 2016 at 10:33 PM <jab at math.brown.edu> wrote:

> On Mon, Jun 13, 2016 at 3:19 AM, Łukasz Langa <lukasz at langa.pl> wrote:
> > Previous discussion about the said patch:
> http://bugs.python.org/issue25243
>
> (((
> I would have linked to that, but:
>
> - That's actually a different patch, and an inaccurate discussion of
> it, to boot. For one, in an effort to avoid exactly your bike shedding
> concerns, I specifically didn't include "on"/"off" or "yes"/"no" this
> time (which I wouldn't have included originally, if it weren't for the
> built-in configparser module's using them in getboolean().)
>
> - The mention of the configparser module in that discussion ends up
> being distracting, confusing the issue, and taking away from the
> productive discussion of it I hoped to have here.
>
> - Case in point, Raymond misunderstood the original patch, and then
> never got a chance to respond to my clarifications.
>
> So I was just trying to save people here from wasting time reading an
> out-of-date patch and a confusing and inaccurate discussion of it.
> )))
>
> --
>
> I know this would only save us from each having to rewrite the same
> few-line function. And I know there can be a tradeoff in introducing a
> new API like this. If it's just not possible to narrow the scope of
> this enough to make it worth it (e.g. would just accepting "True" or
> "False", so we offered a round-trip from str(some_bool), settle
> this?), I'll leave it at that. But if anyone has any other ideas or
> feels it's worth discussing further, I'd be happy to.
>
> Thanks for your consideration!
>
> Josh
> _______________________________________________
> 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/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20160613/976af43e/attachment-0001.html>