I *definitely* don't think a little tool I wrote in a couple hours last night belongs in the standard library (with most of the heavy lifting actually done by wrapt—which is really well designed, and is also not in the standard library). I also don't think PyMaybe belongs there, even though it's a couple years old.
Now, perhaps, if 'coalescing' is widely used for a year or two. And bugs are fixed. And the API is tweaked based on experience with it's use. And so on... At that point, *maybe* something derived from it might be appropriate. On Tue, Jul 24, 2018, 9:08 AM Rhodri James <rho...@kynesim.co.uk> wrote: > On 24/07/18 14:02, David Mertz wrote: > > On Tue, Jul 24, 2018, 7:38 AM Rhodri James <rho...@kynesim.co.uk> wrote: > >> I'm still of the opinion that both approaches are trying to solve a > >> problem that's too niche to merit them, BTW. > >> > > > > That doesn't make sense to me. You think my little library shouldn't be > > allowed on PyPI? I don't force the couple classes on anyone, but if they > > happen to help someone (or PyMaybe, or some other library, does) they > don't > > change anything about Python itself. Syntax is a very different matter. > > I have no objection to anyone putting anything on PyPI. Putting it (or > an equivalent) in the standard library is much more problematical, and > you were talking about that. I think your little library is a much > richer source of bugs than you think it is, and dealing with messy data > access isn't a good enough reason to put that much temptation in front > of naive users. > > -- > Rhodri James *-* Kynesim Ltd >
_______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
