[Python-ideas] Re: Implementing string unary operators
Steven D'Aprano writes: > Ironically, Ricky's in-fun suggestion that we use the tilde operator for > swapcase was the only suggestion in these two threads that actually met > the invariant for an inverse that ~~x == x. You forgot about Turkish, I think it is, that has three cases (the third is called "title case". Just another Joke that Broke because Unicode! ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/MWD2OEJQOCELHBDUCRV2OPY4MREQW26I/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Wed, Oct 20, 2021 at 12:02 PM <2qdxy4rzwzuui...@potatochowder.com> wrote: > > On 2021-10-20 at 11:48:30 +1100, > Chris Angelico wrote: > > > TBH swapcase is a bit of a minefield if you don't know what language > > you're working with. > > [...] > > > The most logical "negation" of a string would be reversing it, which > > WOULD be... well, reversible. But that doesn't need an operator, since > > it already has slice notation. > > Slice notation is also a minefield; [some] explosives are combining > characters. True, but since all of Python's indexing, slicing, etc, is defined by codepoints, what that really means is that slicing/reversing a string can cause peculiar behaviours. But that's true of many other types of characters too; if you mix LTR and RTL text, with some directionless text in between, you'll see some very peculiar behaviour when you reverse it (try getting an English word, some ASCII digits, and an Arabic word - the digits are the same ones that both languages use). So I don't think combining characters are unique here. "Reversing" text means many different things depending on context. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VPFBG3M4FNB7QMRW3TO6M5JT4QT2PMYG/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On 2021-10-20 at 11:48:30 +1100, Chris Angelico wrote: > TBH swapcase is a bit of a minefield if you don't know what language > you're working with. [...] > The most logical "negation" of a string would be reversing it, which > WOULD be... well, reversible. But that doesn't need an operator, since > it already has slice notation. Slice notation is also a minefield; [some] explosives are combining characters. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/W4P7XRM5C4DFSZUUSWEZAEA7HAC7ODEI/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Wed, Oct 20, 2021 at 11:35 AM Steven D'Aprano wrote: > > On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote: > > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano > > wrote: > > > Ironically, Ricky's in-fun suggestion that we use the tilde operator for > > > swapcase was the only suggestion in these two threads that actually met > > > the invariant for an inverse that ~~x == x. > > > > > > > >>> x = "ß" > > > > :) Okay, so it's *mostly* an invariant. > > Hah, well spotted! > > Ironically, there is an uppercase eszett, 'ẞ', although font support for > it may still be limited. (Come on font designers, it has only been > official in Unicode since 2008 and in German orthography in 2017). > Yes (and it shows up fine in both my web browser and my terminals), but that only makes swapcase worse. >>> s = "ẞ" >>> print(s := s.swapcase()) ß >>> print(s := s.swapcase()) SS >>> print(s := s.swapcase()) ss Fortunately, you can always rely on casefold to make things consistent: >>> "ẞ".casefold() == "ß".casefold() == "SS".casefold() == "ss".casefold() True TBH swapcase is a bit of a minefield if you don't know what language you're working with. >>> "Iİıi".swapcase() 'ii̇II' I'm not sure I've ever used it in production. Normally it's just upper(), lower(), or title() for conversions, and casefold() for comparisons. The most logical "negation" of a string would be reversing it, which WOULD be... well, reversible. But that doesn't need an operator, since it already has slice notation. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/CKIDS5D2IUAW7P4GWZNFGTVYJIZY6WHP/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
I'm here all week. Tip your wait staff. Also, genuine apologies if mine was perceived as mean-sarcastic. It was definitely sarcastic but I hoped it was fun enough in tone not to seem mean-spirited. I apologize sincerely and without reservation and I would do it better next time. :) On Tue, Oct 19, 2021, 8:35 PM Steven D'Aprano wrote: > On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote: > > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano > wrote: > > > Ironically, Ricky's in-fun suggestion that we use the tilde operator > for > > > swapcase was the only suggestion in these two threads that actually met > > > the invariant for an inverse that ~~x == x. > > > > > > > >>> x = "ß" > > > > :) Okay, so it's *mostly* an invariant. > > Hah, well spotted! > > Ironically, there is an uppercase eszett, 'ẞ', although font support for > it may still be limited. (Come on font designers, it has only been > official in Unicode since 2008 and in German orthography in 2017). > > -- > Steve > ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BSSSU5FWJDGWIJBCWQK7VMVAG5O2SJ7Q/ > Code of Conduct: http://python.org/psf/codeofconduct/ > ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/5XYGJNATVNV2VCUE66ODQL5OY7PBDVYX/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Tue, Oct 12, 2021 at 05:30:13PM -0700, Guido van Rossum wrote: > I would also like to remind various other posters that sarcasm is *not* a > good way to welcome newbies. The name of the list is python-ideas, not > python-ideas-to-shoot-down-sarcastically. Guido, it isn't fair of you to jump into this thread and start scolding us for being sarcastic. Jelle's accusation that we "mostly" replied to Jerimiah with sarcasm was inaccurate. The regulars here (especially Chris) spent a lot of time and effort trying to get Jerimiah to understand the need to justify the association between ord(), or some other arbitrary function, with the unary plus operator (or any other arbitrary operator). It is not nice to dismiss that effort as sarcastically shooting the idea down. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/QAT3HVWQEUJWMY33MQ47X2AIR5XVK6DY/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Wed, Oct 20, 2021 at 11:10:52AM +1100, Chris Angelico wrote: > On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano wrote: > > Ironically, Ricky's in-fun suggestion that we use the tilde operator for > > swapcase was the only suggestion in these two threads that actually met > > the invariant for an inverse that ~~x == x. > > > > >>> x = "ß" > > :) Okay, so it's *mostly* an invariant. Hah, well spotted! Ironically, there is an uppercase eszett, 'ẞ', although font support for it may still be limited. (Come on font designers, it has only been official in Unicode since 2008 and in German orthography in 2017). -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/BSSSU5FWJDGWIJBCWQK7VMVAG5O2SJ7Q/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Wed, Oct 20, 2021 at 11:02 AM Steven D'Aprano wrote: > Ironically, Ricky's in-fun suggestion that we use the tilde operator for > swapcase was the only suggestion in these two threads that actually met > the invariant for an inverse that ~~x == x. > >>> x = "ß" :) Okay, so it's *mostly* an invariant. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4V4J4K6CIDWW2BIBCHOVUHCCHMV6R3P2/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Unpacking in tuple/list/set/dict comprehensions
On Sun, Oct 17, 2021 at 05:02:23PM -0700, Guido van Rossum wrote: > On Sun, Oct 17, 2021 at 4:38 PM Steven D'Aprano wrote: > > > Right-o, the old "heterogeneous tuples versus homogeneous lists" > > distinction, I remember that from the old 1.5 days. I haven't heard it > > mentioned for a long time! > > > > You must not have looked at type annotations then. :-) Not closely enough to draw the connection unprompted, no. Thanks for the reminder. > Type annotations > legitimize this, by favoring the syntax list[int] for a homogeneous list > versus tuple[int, str, bool] for a heterogeneous tuple. (There's a syntax > for a homogeneous tuple too, but it's intentionally slightly longer.) This makes sense. > So this rule of thumb is definitely not dead (as you seemed to imply). What I actually said: "That certainly remains a reasonable guideline to make, albeit less so today" (and then gave reasons why less so). I explicitly agreed that it still is a good distinction to make. It is a particularly egregiously unfair misrepresentation to say I "seemed to imply" otherwise. That's not cool. Another factor in favour of the heterogeneous vs homogeneous distinction is the practical difficulty in working with complex data structures made from tuples, due to their immutability. I've just spent some time using an API that represents data as nested tuples, and due to their immutability they can be a pain to assemble. Nested lists are much easier. It's okay if you know your data up front and can write it as a nested tuple display, but if you need to assemble it dynamically, it is not fun. Would not recommend. Fortunately it's my own API and so I can take a flame thrower to it and replace it with something better :-) -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/M4DRP2WMNXMSOJXE72IOHV452LQSJ7WM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Implementing string unary operators
On Tue, Oct 12, 2021 at 05:10:45PM -0700, Jelle Zijlstra wrote: > Your other post mostly attracted sarcastic replies, so I'll be more direct: > It's highly unlikely that this will go anywhere. Jelle, the second part of your sentence may be true, but the first part is not. It is unfair and inaccurate to say that the other post "mostly" attracted sarcastic replies. There was exactly one post that used sarcasm, by Ricky, and that was not biting or aggressive sarcasm, but just a bit of humour: that using unary operators for swapcase and titlecase could save a lot of typing. Ironically, Ricky's in-fun suggestion that we use the tilde operator for swapcase was the only suggestion in these two threads that actually met the invariant for an inverse that ~~x == x. -- Steve ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/NXYGINOLJUGGUSXAZA5T3HN4MIVB6DTH/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Type-hinting dictionaries for an arbitrary number of arbitrary key/value pairs? Counterpart to PEP 589?
Hi all,
thanks for all the feedback.
> But this is probably off-topic. I'm not 100% sure what the OP's
> proposal was, but as far as I can tell it seems to me that "dict[str,
> Number] is the correct usage for static typing" is the answer,
> regardless of mypy's ability to process it.
Let me explain the rational. Albeit type annotations in Python are
usually viewed as a tool for static code analysis, I really started to
like them for run-time checks and testing. I am hammering my code with
pytest, hypothesis and typeguard. It is this very combination that
allows me to find the kind of odd cases that I am looking for. The cool
thing is that, once the code is tested, I can turn the run-time checks
(i.e. typeguard) off simply by setting `PYTHONOPTIMIZE` to `1` or by
running CPython with the `-o` flag for production use. It kills the
`assert` statements *and* the run-time type checks without touching the
code.
Now, what PEP 589 *theoretically* allows is something as follows:
```python
from typing import TypedDict
from typeguard import typechecked
@typechecked
class Movie(TypedDict):
name: str
year: int
a = Movie(name = 'a', year = 1984) # ok
a['height'] = 2.0 # fail
b = Movie(something = 1.0) # fail
```
I am aware that typeguard does not support this at the moment, but based
on its design, it could be implemented (I think). A simple decorator on
top of a class with type annotations - done. Every instance of `Movie`
could be automatically type-checked. For this approach to work, it is
key that `Movie` is a class (which can be decorated).
In contrast, something like `dict[str, Number]` is perfectly fine for
static type checking and/or if there is type interference. Consider the
following example:
```python
Data = dict[str, Number]
c: Data = {}
c[3.0] = b'foo' # how to catch this at runtime?
```
In this case, `c` is just a "regular" instance of `dict`. I am not sure
how a run-time checker could catch any subsequent errors as shown above
(unless the dict is passed into or returned from a function/method). The
type checker would need to dig into the `dict` class itself and/or deep
into the interpreter. Correct me if I am wrong here - I'd be happy to
learn something new. Now my potentially stupid idea is to have a
counterpart to PEP 589's `TypedDict` classes which allows to subclass
and decorate the result, e.g. something elegant like this:
```python
@typechecked
class Data(YetAnotherTypedDictThing):
keys: str
values: Number
```
At the end of the day, a variation of Steven's and Alex's solutions
should do for me for the time being:
```python
from numbers import Number
from collections import UserDict
@typechecked
class Data(UserDict[str, Number]):
def __setitem__(self, key: str, value: Number):
super().__setitem__(key, value)
```
It is ok, it works, but it still looks and feels a little awkward:
(1) I need to override a dunder method.
(2) I need to subclass from something that already wraps `dict`.
(3) I need to specify the types in two separate places (redundancy) if I
am going for a generic solution - unless I am introducing type variables.
Last but not least, typeguard is looking for a new maintainer at the
moment, yes. I can not stress enough how useful this tool is for
testing. Maybe it is of interest and relevance to someone around here.
Thanks,
Sebastian
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/GJ4EP7WPSF5GQ5M2HB3PNDJJTJJTBZUX/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
Thanks, finally a +1! \o/ It's funny that "entry point" triggered your reaction, because I think it's not the correct technical term. What I'm proposing is very similar to http.server: https://github.com/python/cpython/blob/3.10/Lib/http/server.py#L1257 Just like "python -m http.server" you could then use "python -m urllib.request.download ". ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VWAAKI2UHI3NMKNPUZV3BUOEYGTP7AY4/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
On Tue, Oct 19, 2021 at 7:32 AM Tom Pohl wrote: > You are absolutely right, the functionality is there, but the idea is to > make it easily available from the command line. > > With the proposed functionality, the urllib could provide a download entry > point which would make the line look like this: > > RUN python -m urrlib.download "https://.../install-poetry.py"; | python > I don't know about the others, but I missed that you were talking about an entry point in your initial post. I think that's a great idea -- and we could add a modest set of command line options as well. Folks are always resistant to adding new things, but once written, this would provide a nice feature, and not be difficult to maintain nor disruptive in any way. +1 for sure! -CHB ___ > Python-ideas mailing list -- python-ideas@python.org > To unsubscribe send an email to python-ideas-le...@python.org > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > Message archived at > https://mail.python.org/archives/list/python-ideas@python.org/message/BHSDIRVN4GATW3KO374FPFDTNG7L6ENN/ > Code of Conduct: http://python.org/psf/codeofconduct/ > -- Christopher Barker, PhD (Chris) Python Language Consulting - Teaching - Scientific Software Development - Desktop GUI and Web Development - wxPython, numpy, scipy, Cython ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/3EJLYTA6YGFCJ6LUEGBSNJDKJZKUOOWL/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
On Wed, Oct 20, 2021 at 1:23 AM Christian Heimes wrote: > > On 19/10/2021 00.06, Chris Angelico wrote: > > On Tue, Oct 19, 2021 at 9:00 AM Cameron Simpson wrote: > >> The problem with a "download()" method is that it is almost never what > >> you need. There are too many ways to want to do it, and one almost > >> _never_ wants to suck the download itself into memory as you do above > >> with read() because downloads are often large, sometimes very large. > >> > >> You also don't always want to put it into a file. > >> > > > > OTOH, if you *do* want to put it into a file, it should be possible to > > take advantage of zero-copy APIs to reduce unnecessary transfers. I'm > > not sure if there's a way to do that with requests. Ideally, what you > > want is os.sendfile() but it'd need to be cleanly wrapped by the > > library itself. > > Splicing APIs like sendfile() require a Kernel socket. You cannot do > sendfile() with userspace sockets like OpenSSL socket for e.g. HTTPS. > > Latest Linux Kernel and OpenSSL 3.0.0 have a new feature called kTLS. > Kernel TLS uses OpenSSL to establish the TLS connection and then handles > payload transfer in Kernel to for zero-copy sendfile(). > Ah, of course, forgot about that. But obviously other people have seen the same problem, and come up with a solution. In any case, it cements the need for an actual API for "download this into a file", despite the limitations of it. Obviously you also need the API of "give me the next lot of bytes as a string", but being able to download directly to a file *is* of significant value. ChrisA ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/RAD2GKYFZP5TWM52TA62AMV6VDUHQ3SU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
You are absolutely right, the functionality is there, but the idea is to make
it easily available from the command line.
Here is a line (with shortened URL) from a Dockerfile which installs poetry as
suggested in the docs:
RUN python -c "from urllib.request import urlopen;
print(urlopen('https://.../install-poetry.py').read().decode())" | python
With the proposed functionality, the urllib could provide a download entry
point which would make the line look like this:
RUN python -m urrlib.download "https://.../install-poetry.py"; | python
This is less error-prone, would also work for rather large downloads and
wouldn't be much effort to implement/test/maintain.
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/BHSDIRVN4GATW3KO374FPFDTNG7L6ENN/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
On 19/10/2021 00.06, Chris Angelico wrote: On Tue, Oct 19, 2021 at 9:00 AM Cameron Simpson wrote: The problem with a "download()" method is that it is almost never what you need. There are too many ways to want to do it, and one almost _never_ wants to suck the download itself into memory as you do above with read() because downloads are often large, sometimes very large. You also don't always want to put it into a file. OTOH, if you *do* want to put it into a file, it should be possible to take advantage of zero-copy APIs to reduce unnecessary transfers. I'm not sure if there's a way to do that with requests. Ideally, what you want is os.sendfile() but it'd need to be cleanly wrapped by the library itself. Splicing APIs like sendfile() require a Kernel socket. You cannot do sendfile() with userspace sockets like OpenSSL socket for e.g. HTTPS. Latest Linux Kernel and OpenSSL 3.0.0 have a new feature called kTLS. Kernel TLS uses OpenSSL to establish the TLS connection and then handles payload transfer in Kernel to for zero-copy sendfile(). Christian ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/4IWZOPHWKQKKGAZPHYFH3D667W64VSCV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
On Tue, Oct 19, 2021 at 12:31 AM Tom Pohl wrote: > I am aware of requests (or httpx, ...), but the idea is to do all that > with the > standard library. If I have to install stuff, I could just install > wget/curl and be done. > I believe what you are looking for is already in the stdlib, see urllib.request.urlretrieve. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/ZAFRC7CSE2FVDX25LO44532RLJPPKI7B/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Real Positional Arguments or OO Currying
> Seems like the docs should cover that (or even `help()`) -- and if not, then > the parameter names could be better. It should, and normally does as do the parameters, but the best documentation should be the code itself, right? So the idea here would be to make it harder to not know the order than to forget, i.e. so you would check the docs for the more nuanced behaviour around kwargs or something of that nature. ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/KYBVRLWBCWP3WCZLRFH7RM44X7G2KXMU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
Performance is not an issue in the use case I envision. This is about downloading small installation scripts (i.e for install poetry in a container) or a few megabytes of data. I just tested the improved script (with just 1MB of read buffer) and it could easily saturate my 100 Mbit/s connection while downloading a 1.9 GB file in under three minutes (other clients where using the same connection). Tom ___ Python-ideas mailing list -- python-ideas@python.org To unsubscribe send an email to python-ideas-le...@python.org https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/python-ideas@python.org/message/VDFT347S2EWDNZVULA7RPHAGBISLHEZO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-ideas] Re: Fwd: Simple curl/wget-like download functionality in urllib (like http offers server)
I am aware of requests (or httpx, ...), but the idea is to do all that with the
standard library. If I have to install stuff, I could just install wget/curl
and be done.
Feature creep is an issue here, but just like http.server one could be really
strict about just
covering 90% of the use cases (download stuff and print or save it) and not
trying to handle
any corner cases.
The first code snippet was not supposed to be production-ready. Here's an
improved version
which only downloads 1MB a time and prints it. The only parameter could be the
URL:
from urllib.request import urlopen
from sys import stdout
with urlopen("https://coherentminds.de/";) as response:
while data := response.read(1024 * 1024):
stdout.buffer.write(data)
The user of this function could still decide to divert stdout into a file, so
both use cases
printing and saving would be covered.
IMHO, the benefit-cost ratio is quite good:
* can be a lifesaver (just like http.server) every once in a while in
particular in a container or testing context
* low implementation effort
* easy to test and to maintain
Tom
___
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/LV53MUS27TPYMJ3RZQCF5LPYJNPMGCL2/
Code of Conduct: http://python.org/psf/codeofconduct/
