[prev in list] [next in list] [prev in thread] [next in thread] 

List:       python-dev
Subject:    [Python-Dev] Fwd: Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate 
From:       Sasha Kacanski <skacanski () gmail ! com>
Date:       2022-03-30 18:08:34
Message-ID: CAFWiikqp1Hi1EgEtrhdxbxU4eeKUhsHo2K8ZAskUTzJx9HPhOw () mail ! gmail ! com
[Download RAW message or body]

[Attachment #2 (multipart/alternative)]


---------- Forwarded message ---------
From: Sasha Kacanski <skacanski@gmail.com>
Date: Wed, Mar 30, 2022, 2:55 PM
Subject: Re: [Python-Dev] Re: Are "Batteries Included" still a Good Thing?
[was: It's now time to deprecate the stdlib urllib module]
To: Paul Moore <p.f.moore@gmail.com>
Cc: Christopher Barker <pythonchb@gmail.com>, Ethan Furman <
ethan@stoneleaf.us>, Python Dev <python-dev@python.org>


Agree with Paul,
Best of python always was, you can do almost everything with standard libs,
but then novice becomes better developer and starts exploring libs and
tools that wrap stuff or perform better or has functionality that stdlib
does not support right of the bet they start using variety of libs that
suits their needs.
Regards,
Sasha


On Sun, Mar 27, 2022, 8:06 PM Paul Moore <p.f.moore@gmail.com> wrote:

> On Sun, 27 Mar 2022 at 17:11, Christopher Barker <pythonchb@gmail.com>
> wrote:
> >
> > With the json package included, all they need to do is `import json`. If
> that wasn't there, they's look in PyPi for a JSON implementation, and find
> an absolutely astonishing number of options. I just did a search for "JSON"
> >  on PYPI, and it's HUGE -- most of them are for specialized JSON-using
> protocols of some sort. I was actually really surprised that couple I know
> about of the top of my head (ujson, orjson) are actually hard to find.
> >
> > "You can just pip install it" is really not a good solution.
> >
> > In fact, this is an example, I think, of where we should put some effort
> into making the included batteries better -- it's great to have a JSON lib
> built in, but it's too bad that it's not best-of-bread by pretty much any
> definition (speed, memory performance, flexibility) -- there are quite a
> few feature requests open for it -- it would be nice to actually implement
> some of those. (but yes, that's a lot of work that someone(s) would have to
> do)
> >
> > Back to the topic at hand, rather than remove urllib, maybe it could be
> made better -- an as-easy-to-use-as-requests package in the stdlib would be
> really great.
>
> I think that's where the mistake happens, though. Someone who needs
> "best of breed" is motivated (and likely knowledgeable enough) to make
> informed decisions about what's on PyPI. But someone who just wants to
> get the job done probably doesn't - and that's the audience for the
> stdlib. A stdlib module needs to be a good, reliable set of basic
> functionality that non-experts can use successfully. There can be
> better libraries on PyPI, but that doesn't mean the stdlib module is
> unnecessary, nor does it mean that the stdlib has to match the PyPI
> library feature for feature.
>
> So here, specifically, I'd rather see urlllib be the best urlllib it
> can be, and not demand that it turn into requests. Requests is there
> if people need/want it (as is httpx, and urllib3, and aiohttp). But
> urllib is for people who want to get a file from the web, and *not*
> have to deal with dependencies, 3rd party libraries, etc.
>
> The "batteries included" standard library and PyPI complement each
> other. Neither is redundant, and neither implies the other is
> unnecessary.
>
> Paul
> _______________________________________________
> Python-Dev mailing list -- python-dev@python.org
> To unsubscribe send an email to python-dev-leave@python.org
> https://mail.python.org/mailman3/lists/python-dev.python.org/
> Message archived at
> https://mail.python.org/archives/list/python-dev@python.org/message/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/
> Code of Conduct: http://python.org/psf/codeofconduct/
>

[Attachment #5 (text/html)]

<div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" \
class="gmail_attr">---------- Forwarded message ---------<br>From: <strong \
class="gmail_sendername" dir="auto">Sasha Kacanski</strong> <span dir="auto">&lt;<a \
href="mailto:skacanski@gmail.com">skacanski@gmail.com</a>&gt;</span><br>Date: Wed, \
Mar 30, 2022, 2:55 PM<br>Subject: Re: [Python-Dev] Re: Are &quot;Batteries \
Included&quot; still a Good Thing? [was: It&#39;s now time to deprecate the stdlib \
urllib module]<br>To: Paul Moore &lt;<a \
href="mailto:p.f.moore@gmail.com">p.f.moore@gmail.com</a>&gt;<br>Cc: Christopher \
Barker &lt;<a href="mailto:pythonchb@gmail.com">pythonchb@gmail.com</a>&gt;, Ethan \
Furman &lt;<a href="mailto:ethan@stoneleaf.us">ethan@stoneleaf.us</a>&gt;, Python Dev \
&lt;<a href="mailto:python-dev@python.org">python-dev@python.org</a>&gt;<br></div><br><br><div \
dir="auto">Agree with Paul,  <div dir="auto">Best of python always was, you can do \
almost everything with standard libs, but then novice becomes better developer and \
starts exploring libs and tools that wrap stuff or perform better or has \
functionality that stdlib does not support right of the bet they start using variety \
of libs that suits their needs.</div><div dir="auto">Regards,</div><div \
dir="auto">Sasha</div><div dir="auto"><br></div></div><br><div \
class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, Mar 27, 2022, 8:06 PM \
Paul Moore &lt;<a href="mailto:p.f.moore@gmail.com" target="_blank" \
rel="noreferrer">p.f.moore@gmail.com</a>&gt; wrote:<br></div><blockquote \
class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc \
solid;padding-left:1ex">On Sun, 27 Mar 2022 at 17:11, Christopher Barker &lt;<a \
href="mailto:pythonchb@gmail.com" rel="noreferrer noreferrer" \
target="_blank">pythonchb@gmail.com</a>&gt; wrote:<br> &gt;<br>
&gt; With the json package included, all they need to do is `import json`. If that \
wasn&#39;t there, they&#39;s look in PyPi for a JSON implementation, and find an \
absolutely astonishing number of options. I just did a search for \
&quot;JSON&quot;<br> &gt;   on PYPI, and it&#39;s HUGE -- most of them are for \
specialized JSON-using protocols of some sort. I was actually really surprised that \
couple I know about of the top of my head (ujson, orjson) are actually hard to \
find.<br> &gt;<br>
&gt; &quot;You can just pip install it&quot; is really not a good solution.<br>
&gt;<br>
&gt; In fact, this is an example, I think, of where we should put some effort into \
making the included batteries better -- it&#39;s great to have a JSON lib built in, \
but it&#39;s too bad that it&#39;s not best-of-bread by pretty much any definition \
(speed, memory performance, flexibility) -- there are quite a few feature requests \
open for it -- it would be nice to actually implement some of those. (but yes, \
that&#39;s a lot of work that someone(s) would have to do)<br> &gt;<br>
&gt; Back to the topic at hand, rather than remove urllib, maybe it could be made \
better -- an as-easy-to-use-as-requests package in the stdlib would be really \
great.<br> <br>
I think that&#39;s where the mistake happens, though. Someone who needs<br>
&quot;best of breed&quot; is motivated (and likely knowledgeable enough) to make<br>
informed decisions about what&#39;s on PyPI. But someone who just wants to<br>
get the job done probably doesn&#39;t - and that&#39;s the audience for the<br>
stdlib. A stdlib module needs to be a good, reliable set of basic<br>
functionality that non-experts can use successfully. There can be<br>
better libraries on PyPI, but that doesn&#39;t mean the stdlib module is<br>
unnecessary, nor does it mean that the stdlib has to match the PyPI<br>
library feature for feature.<br>
<br>
So here, specifically, I&#39;d rather see urlllib be the best urlllib it<br>
can be, and not demand that it turn into requests. Requests is there<br>
if people need/want it (as is httpx, and urllib3, and aiohttp). But<br>
urllib is for people who want to get a file from the web, and *not*<br>
have to deal with dependencies, 3rd party libraries, etc.<br>
<br>
The &quot;batteries included&quot; standard library and PyPI complement each<br>
other. Neither is redundant, and neither implies the other is<br>
unnecessary.<br>
<br>
Paul<br>
_______________________________________________<br>
Python-Dev mailing list -- <a href="mailto:python-dev@python.org" rel="noreferrer \
noreferrer" target="_blank">python-dev@python.org</a><br> To unsubscribe send an \
email to <a href="mailto:python-dev-leave@python.org" rel="noreferrer noreferrer" \
target="_blank">python-dev-leave@python.org</a><br> <a \
href="https://mail.python.org/mailman3/lists/python-dev.python.org/" rel="noreferrer \
noreferrer noreferrer" \
target="_blank">https://mail.python.org/mailman3/lists/python-dev.python.org/</a><br> \
Message archived at <a \
href="https://mail.python.org/archives/list/python-dev@python.org/message/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/" \
rel="noreferrer noreferrer noreferrer" \
target="_blank">https://mail.python.org/archives/list/python-dev@python.org/message/E2FGXTYOEYLC6GSJGMWBQKHOO62LZPHQ/</a><br>
 Code of Conduct: <a href="http://python.org/psf/codeofconduct/" rel="noreferrer \
noreferrer noreferrer" target="_blank">http://python.org/psf/codeofconduct/</a><br> \
</blockquote></div> </div>



_______________________________________________
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-leave@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/3LOIPKKY73KDH526SKLXJX4FGBCEQMLH/
 Code of Conduct: http://python.org/psf/codeofconduct/



[prev in list] [next in list] [prev in thread] [next in thread] 

Configure | About | News | Add a list | Sponsored by KoreLogic