[Python-Dev] Re: walrus operator and expression

On 2022-03-28 23:59, Chris Angelico wrote: On Tue, 29 Mar 2022 at 09:53, Ethan Furman wrote: In the following bit of code: while s := input.read(MAXBINSIZE): while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): s += ns line =

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Sun, Mar 27, 2022, 11:07 AM Paul Moore wrote: > On Sun, 27 Mar 2022 at 17:11, Christopher Barker > wrote: > > 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

[Python-Dev] Re: Enhancing generic type documentation in the standard library

On Wed, Mar 23, 2022 at 5:01 PM Brett Cannon wrote: > The SC somewhat agrees!  See > https://mail.python.org/archives/list/typing-...@python.org/thread/TVMQJXOJFOYFPDMQDFG6G4B6J3MLRYKB/ > where we have asked for at least the specs to get consolidated into proper > documentation instead of

[Python-Dev] Re: walrus operator and expression

Parenthesize. On Mon, Mar 28, 2022 at 3:50 PM Ethan Furman wrote: > In the following bit of code: > > > while s := input.read(MAXBINSIZE): > while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): > s += ns > line = binascii.b2a_base64(s) >

[Python-Dev] Re: walrus operator and expression

On Tue, 29 Mar 2022 at 09:53, Ethan Furman wrote: > > In the following bit of code: > > > while s := input.read(MAXBINSIZE): > while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): > s += ns > line = binascii.b2a_base64(s) >

[Python-Dev] walrus operator and expression

In the following bit of code: while s := input.read(MAXBINSIZE): while len(s) < MAXBINSIZE and ns := input.read(MAXBINSIZE-len(s)): s += ns line = binascii.b2a_base64(s) output.write(line) I'm getting this error on the second line: cannot use

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, Mar 28, 2022 at 11:52 AM Christopher Barker wrote: > On Mon, Mar 28, 2022 at 11:29 AM Paul Moore wrote: > >> To be honest, I feel like I'm just reiterating stuff I've said before >> here, and I think the same is true of the points I'm responding to > > ... > >> (I'm not *against*

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this proposal may break the next major release of PyTorch. The related project is TorchDynamo, which can be found here: https://github.com/facebookresearch/torchdynamo We will likely move this into the core of PyTorch closer to

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, 28 Mar 2022 at 20:37, Steve Dower wrote: > Please let us know > *publicly* if you want to become the maintainer for a stdlib module and > then we can support them, but if nobody is willing/able/ready to care > for them it's irresponsible for us to keep shipping them to users. I'm sorry

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

> What happens when the new maintainer puts malware in the next release of > a package in sumo.txt? > Will core devs be blamed for listing it? > As a user, how do I determine if I can trust the packages there? (This > is easily the hardest part of finding and installing a package from > PyPI,

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 3/28/2022 7:26 PM, Paul Moore wrote: To be honest, I feel like I'm just reiterating stuff I've said before here, and I think the same is true of the points I'm responding to. Is there actually any new development here, or is it just a repeat of the same positions people have expressed in the

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, Mar 28, 2022 at 11:29 AM Paul Moore wrote: > To be honest, I feel like I'm just reiterating stuff I've said before > here, and I think the same is true of the points I'm responding to ... > (I'm not *against* going over the debate again, > it helps make sure people haven't changed

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Sun, Mar 27, 2022 at 11:04 AM Paul Moore wrote: > > 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

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Mon, 28 Mar 2022 at 17:45, Steve Dower wrote: > > I think to most people "batteries included" doesn't necessarily mean > "standard library," with all that implies. It just means "it came with > the first thing that I installed" (or alternatively, "at no additional > charge"). I think that for

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

> If urllib is removed, I would very much like to preserve at least the functionality of urlparse /somewhere/. Given every alternative library to urllib relies on urllib.parse (and some rely on urllib.request), as well as popular libraries like pip, in this hypothetical it would definitely need

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

"Coyot Linden (Glenn Glazer)" writes: > P.S. There are uses for urllib outside of standard web programming. I > recently needed to handle strings in query parameter format > (`?...&...&...`) and found urllib parse() the easiest way of doing > that even though I wasn't taking them in as a

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

I think to most people "batteries included" doesn't necessarily mean "standard library," with all that implies. It just means "it came with the first thing that I installed" (or alternatively, "at no additional charge"). Given there are *plenty* of existing distros out there that install more

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 28. 03. 22 17:34, Skip Montanaro wrote: Barry writes (in part): We could still distribute “sumo” releases which include all the batteries, but develop and maintain them outside the cpython repo, and even release them separately on PyPI. It’s *possible* but I don’t know if it’s *practical*.

[Python-Dev] Re: import * and __future__ imports

On Mon, Mar 28, 2022 at 8:52 AM Irit Katriel wrote: > > > On Mon, Mar 28, 2022 at 4:44 PM Guido van Rossum wrote: > >> >> "Future" imports are special to the parser, and they may also set a flag >> for the runtime to alter its behavior, but they are intentionally not >> treated specially by

[Python-Dev] Re: import * and __future__ imports

On Mon, Mar 28, 2022 at 4:44 PM Guido van Rossum wrote: > > "Future" imports are special to the parser, and they may also set a flag > for the runtime to alter its behavior, but they are intentionally not > treated specially by code generation, so they are still properly imported. > However the

[Python-Dev] Re: is __self__ an implementation detail

It's documented in stdtypes.rst, so I think it's part of the standard library. I think it's unnecessarily obfuscated though. On Mon, Mar 28, 2022 at 8:44 AM Robin Becker wrote: > A gentoo developer reported a symlink loop problem in reportlab's setup.py > where we search for specific headers.

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On Sun, Mar 27, 2022 at 3:08 AM Paul Moore p.f.mo...@gmail.com wrote: ... exactly - let's say someone needs to write some JSON for the first time. With the json package included, all they need to do is `import json`. If that wasn't there,

[Python-Dev] Re: import * and __future__ imports

On Mon, Mar 28, 2022 at 6:29 AM Irit Katriel via Python-Dev < python-dev@python.org> wrote: > If you have a __future__ import in a script, and you import * from it in > another script, the object for this future appears in the dir() of the > other script, even though the __future__ import has no

[Python-Dev] is __self__ an implementation detail

A gentoo developer reported a symlink loop problem in reportlab's setup.py where we search for specific headers. The 'fixed' function looks like this def findFile(root, wanted, followlinks=True): visited = set() for p, D, F in os.walk(root,followlinks=followlinks): #scan

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

Barry writes (in part): > We could still distribute “sumo” releases which include all the > batteries, but develop and maintain them outside the cpython repo, > and even release them separately on PyPI. It’s *possible* but I > don’t know if it’s *practical*. to which Stephen responds (in part):

[Python-Dev] Re: import * and __future__ imports

On 28. 03. 22 15:25, Irit Katriel via Python-Dev wrote: If you have a __future__ import in a script, and you import * from it in another script, the object for this future appears in the dir() of the other script, even though the __future__ import has no effect there. % cat x.py from

[Python-Dev] import * and __future__ imports

If you have a __future__ import in a script, and you import * from it in another script, the object for this future appears in the dir() of the other script, even though the __future__ import has no effect there. % cat x.py from __future__ import annotations % cat y.py from x import *

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On 24. 03. 22 20:06, Fabio Zadrozny wrote: Em qui., 24 de mar. de 2022 às 15:39, Fabio Zadrozny > escreveu: PEP 523 API added more private functions for code objects: * _PyEval_RequestCodeExtraIndex() * _PyCode_GetExtra() *

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

Barry Warsaw writes: > While I don’t underestimate the work and complexity, we can do > both. I.e. separate the stdlib development cycle from the > interpreter (for all but a handful of required packages perhaps). > We could still distribute “sumo” releases which include all the >