[prev in list] [next in list] [prev in thread] [next in thread]
List: python-dev
Subject: [Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the s
From: Ronald Oussoren via Python-Dev <python-dev () python ! org>
Date: 2022-03-31 10:57:11
Message-ID: 19181446-5A54-471A-8337-9973FCDA37F8 () mac ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
> On 29 Mar 2022, at 19:51, Brett Cannon <brett@python.org> wrote:
>
>
>
> On Tue, Mar 29, 2022 at 8:58 AM Ronald Oussoren <ronaldoussoren@mac.com \
> <mailto:ronaldoussoren@mac.com>> wrote:
>
> > On 29 Mar 2022, at 00:34, Brett Cannon <brett@python.org \
> > <mailto:brett@python.org>> wrote:
> >
> >
> > Once https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/ \
> > <https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/> \
> > is considered resolved, the next part of my "what is the stdlib" plan is to \
> > finally try to suss all of this out and more-or-less write a stdlib policy PEP so \
> > we stop talking about this. My guess it will be more of guidance about what we \
> > want the stdlib to be and thus guide what things belong in it. No ETA on that \
> > work since I also have four other big Python projects on the go right now whose \
> > work I am constantly alternating between.
>
> Having such a policy is a good thing and helps in evolving the stdlib, but I wonder \
> if the lack of such a document is the real problem. IMHO the main problem is that \
> the CPython team is very small and therefore has little bandwidth for maintaining, \
> let alone evolving, large parts of the stdlib. In that it doesn't help that some \
> parts of the stdlib have APIs that make it hard to make modifications (such as \
> distutils where effectively everything is part of the public API). Shrinking the \
> stdlib helps in the maintenance burden, but feels as a partial solution.
> You're right that is the fundamental problem. But for me this somewhat stems from \
> the fact that we don't have a shared understanding of what the stdlib is, and so \
> the stdlib is a bit unbounded in its size and scope. That leads to a stdlib which \
> is hard to maintain.
That (the hard to maintain part) is not necessarily true, if we had enough \
resources…. In theory the stdlib could be split into logical parts with teams that \
feel responsible for those parts (similar to having maintainers sign up for various \
platforms). That doesn't work because of the small team, and partially also due to \
necessarily having very strict rules w.r.t. backward compatibility.
> It's just like dealing with any scarce resource: you try to cut back on your \
> overall use as best as you can and then become more efficient with what you must \
> still consume; I personally think we don't have an answer to the "must consume" \
> part of that sentence that leads us to "cut back" to a size we can actually keep \
> maintained so we don't have 1.6K open PRs \
> <https://github.com/python/cpython/pulls>.
I agree, but this is something to state explicitly when describing what should and \
should not be in scope for the stdlib. I'm a fan of a batteries included stdlib, \
but with our current resources we cannot afford to have some bits in the stdlib that \
would "obviously" be a candidate for a modern batteries included stdlib, such as a \
decent HTTP stack with support for HTTP/1, /2 and /3.
Ronald
—
Twitter / micro.blog: @ronaldoussoren
Blog: https://blog.ronaldoussoren.net/
[Attachment #5 (unknown)]
<html><head><meta http-equiv="Content-Type" content="text/html; \
charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; \
line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote \
type="cite" class=""><div class="">On 29 Mar 2022, at 19:51, Brett Cannon <<a \
href="mailto:brett@python.org" class="">brett@python.org</a>> wrote:</div><br \
class="Apple-interchange-newline"><div class=""><meta charset="UTF-8" class=""><br \
class="Apple-interchange-newline"><br style="caret-color: rgb(0, 0, 0); font-family: \
Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; \
font-weight: 400; letter-spacing: normal; text-align: start; text-indent: 0px; \
text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;" class=""><div \
class="gmail_quote" style="caret-color: rgb(0, 0, 0); font-family: Helvetica; \
font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: 400; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none;"><div dir="ltr" class="gmail_attr">On Tue, Mar 29, 2022 at \
8:58 AM Ronald Oussoren <<a href="mailto:ronaldoussoren@mac.com" \
class="">ronaldoussoren@mac.com</a>> wrote:<br class=""></div><blockquote \
class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; \
border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: \
1ex;"><div style="overflow-wrap: break-word;" class=""><br class=""><div class=""><br \
class=""><blockquote type="cite" class=""><div class="">On 29 Mar 2022, at 00:34, \
Brett Cannon <<a href="mailto:brett@python.org" target="_blank" \
class="">brett@python.org</a>> wrote:</div><br class=""><div class=""><div \
dir="ltr" style="font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; text-decoration: none;" class=""><div class="gmail_quote"><br class=""><div \
class=""><br class=""></div><div class="">Once<span class=""> </span><a \
href="https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/" \
target="_blank" class="">https://mail.python.org/archives/list/python-committers@python.org/thread/5EUZLT5PNA4HT42NGB5WVN5YWW5ASTT5/</a><span \
class=""> </span>is considered resolved, the next part of my "what<span \
class=""> </span><i class="">is</i><span class=""> </span>the stdlib" plan \
is to finally try to suss all of this out and more-or-less write a stdlib policy PEP \
so we stop talking about this. My guess it will be more of guidance about what we \
want the stdlib to be and thus guide what things belong in it. No ETA on that work \
since I also have four other big Python projects on the go right now whose work I am \
constantly alternating between.<br class=""></div></div></div></div></blockquote><div \
class=""><br class=""></div>Having such a policy is a good thing and helps in \
evolving the stdlib, but I wonder if the lack of such a document is the real problem. \
IMHO the main problem is that the CPython team is very small and therefore has \
little bandwidth for maintaining, let alone evolving, large parts of the \
stdlib. In that it doesn't help that some parts of the stdlib have APIs that \
make it hard to make modifications (such as distutils where effectively everything is \
part of the public API). Shrinking the stdlib helps in the maintenance burden, \
but feels as a partial solution. </div></div></blockquote><div class=""><br \
class=""></div><div class="">You're right that is the fundamental problem. But for me \
this somewhat stems from the fact that we don't have a shared understanding of what \
the stdlib<span class="Apple-converted-space"> </span><i class="">is</i>, \
and so the stdlib is a bit unbounded in its size and scope. That leads to a stdlib \
which is hard to maintain. </div></div></div></blockquote><div><br \
class=""></div>That (the hard to maintain part) is not necessarily true, if we had \
enough resources…. In theory the stdlib could be split into logical parts with \
teams that feel responsible for those parts (similar to having maintainers sign up \
for various platforms). That doesn't work because of the small team, and \
partially also due to necessarily having very strict rules w.r.t. backward \
compatibility. <br class=""><div><br class=""></div><br class=""><blockquote \
type="cite" class=""><div class=""><div class="gmail_quote" style="caret-color: \
rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: 400; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div class="">It's just \
like dealing with any scarce resource: you try to cut back on your overall use as \
best as you can and then become more efficient with what you must still consume; I \
personally think we don't have an answer to the "must consume" part of that sentence \
that leads us to "cut back" to a size we can actually keep maintained so we don't \
have<span class="Apple-converted-space"> </span><a \
href="https://github.com/python/cpython/pulls" class="">1.6K open PRs</a>.<br \
class=""></div></div></div></blockquote><div><br class=""></div>I agree, but this is \
something to state explicitly when describing what should and should not be in scope \
for the stdlib. I'm a fan of a batteries included stdlib, but with our current \
resources we cannot afford to have some bits in the stdlib that would "obviously" be \
a candidate for a modern batteries included stdlib, such as a decent HTTP stack with \
support for HTTP/1, /2 and /3. </div><div><br \
class=""></div><div>Ronald</div><br class=""><div class=""> <div dir="auto" \
style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: \
after-white-space;" class=""><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, \
0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: \
normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: \
0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;">—</div><div \
style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); font-family: Helvetica; \
font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; \
letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; \
white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; \
text-decoration: none;"><br class=""></div><div style="caret-color: rgb(0, 0, 0); \
color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; \
font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: \
start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: \
0px; -webkit-text-stroke-width: 0px; text-decoration: none;">Twitter / micro.blog: \
@ronaldoussoren</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0); \
font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: \
normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: \
0px; text-transform: none; white-space: normal; word-spacing: 0px; \
-webkit-text-stroke-width: 0px; text-decoration: none;">Blog: <a \
href="https://blog.ronaldoussoren.net/" \
class="">https://blog.ronaldoussoren.net/</a></div></div> </div>
<br class=""></body></html>
_______________________________________________
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/JS23QUVXW3HZHQFMZBOXUCKT332KGRYS/
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