[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)
Change by Tom Pohl : -- nosy: -tom.pohl ___ Python tracker <https://bugs.python.org/issue45466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)
Tom Pohl added the comment: Thanks, Terry, for the hint. The idea got some support on python-ideas, so I thought it is worthwhile to do a PR. As a first-time contributor, I now have to wait for approval for the pipeline to run... -- ___ Python tracker <https://bugs.python.org/issue45466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45466] Simple curl/wget-like download functionality in urllib (like http offers server)
New submission from Tom Pohl :
In the context of building Docker images, it is often required to download
stuff. If curl/wget are available, great, but often slim images don't offer
that.
The urllib could provide a very simple download functionality (like http offers
a simple server):
from urllib.request import urlopen
data = urlopen('https://.../install-poetry.py').read()
# print or save data
If there's some interest, I could open a PR.
--
components: Library (Lib)
messages: 403888
nosy: tom.pohl
priority: normal
severity: normal
status: open
title: Simple curl/wget-like download functionality in urllib (like http offers
server)
type: enhancement
___
Python tracker
<https://bugs.python.org/issue45466>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39671] Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task
New submission from Tom Pohl : Currently, the documentation of asyncio.wait gives the impression that using FIRST_COMPLETED guarantees the completion of no more than one task. In reality, the number of completed task after asyncio.wait can be larger than one. While this behavior (exactly one complete task if no error or cancellation occurred) would be ultimately desirable, a sentence describing the current behavior would be helpful for new users of asyncio. -- assignee: docs@python components: Documentation messages: 362181 nosy: docs@python, tom.pohl priority: normal severity: normal status: open title: Mention in docs that asyncio.FIRST_COMPLETED does not guarantee the completion of no more than one task type: enhancement versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue39671> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size
New submission from Tom Pohl: From the ctypes.create_string_buffer docs: If a bytes object is specified as first argument, the buffer is made one item larger than its length so that the last element in the array is a NUL termination character. An integer can be passed as second argument which allows to specify the size of the array if the length of the bytes should not be used. Based on this documentation I would expect a NUL-terminated byte array in any case. However, when I do this for size in range(5, 2, -1): print(size, ctypes.create_string_buffer(b'123', size).raw) 5 b'123\x00\x00' 4 b'123\x00' 3 b'123' I get b'123' for size=3 without a NUL. My expectation would be the same exception as I get for create_string_buffer(b'123', 2). -- components: ctypes messages: 248183 nosy: tom.pohl priority: normal severity: normal status: open title: ctypes.create_string_buffer does not add NUL if len(init) == size type: behavior versions: Python 3.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size
Tom Pohl added the comment: I agree: not every buffer is null-terminated. But the function name suggests that it creates a _string_ buffer which will most likely be used as an input to a C function. There, it can easily trigger a buffer overflow without a null termination which can be considered a severe security risk. -- components: -Documentation versions: -Python 2.7, Python 3.5, Python 3.6 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue24823] ctypes.create_string_buffer does not add NUL if len(init) == size
Tom Pohl added the comment: If one needs to set a general buffer (i.e. not a null-terminated string buffer) one could always use: string = (ctypes.c_char*4)() string.raw = b'abcd' -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue24823 ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: Mark, thanks for explaining the connection of // and %. Finally, I can see why somebody would want to stick to the current behavior of FD. It renders FD useless for all of my use cases, but there are simple alternatives. Thanks for your time, Tom -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: You still get me wrong. Thanks to your explanations and to my personal knowledge about this topic (programming for 28 years now; PhD in CS/numerics/HPC) I now fully understand the technical details about the current implementation of FD. The problem I see is that the average Python user does and should not care about such details. I talked to a bunch of people (n=7) here at the company where I also give Python courses from time to time. I asked them two questions: 1. Is this behavior of FD what you would expect? 2. Given the current behavior of FD, what use cases do you see? The answers were always the same (and I tend to agree): 1. No. 2. No idea. All of you seem to answer the first questions with yes, but what's your answer to the second question? What would you recommend your 10-year-old son or your 62-year-old mother to do with the current FD operator? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: This is a fact-of-life for anyone using binary floating point: x = 0.0 while x != 1.0: print(x); x += 0.1 # so long This is not: 1 // 0.1 = 9.0 because math.floor(1/0.1) is able to come up with the result that is expected from an operator called floor division. Aynway, I'm curios, what's your use case for FD? Since all of you are so strongly in favor of the current behavior you must be using it all the time. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
New submission from Tom Pohl: According to the documentation of the floor division (http://docs.python.org/2/reference/expressions.html#binary-arithmetic-operations), x//y should be equal to math.floor(x/y). However, the result of 1//0.1 is 9.0 (tested on 2.6, 2.7, 3.2). It might be related to the internal representation of floating-point numbers, but for this example I would expect it to come up with the correct values. Cheers, Tom -- components: None messages: 175424 nosy: Tom.Pohl priority: normal severity: normal status: open title: Strange results for floor division (//) with non-integer divisors type: behavior versions: Python 2.6, Python 2.7, Python 3.2 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: Thanks for your comments. From a technical/numerical point of view I agree with you that the computed result is correct given the floating-point limitations. From a user's point of view (and the documentation seems to agree with me) the result is wrong. The documentation (see link in first post) says: [...] the result is that of mathematical division with the ‘floor’ function applied to the result. math.floor(1/0.1) returns the expected 10.0 and the doc says that the floor division should behave the same. If 9.0 for 1//0.1 is the correct result according to your definition of the floor division then I cannot think of a reasonable use case for the floor division. -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: Thanks for all the explanations why Python's floor division (FD) works as specified. And I agree, it does work as specified, but still, I think this is not the behavior that most people would expect and is therefore dangerous to provide/use. What do I expect from FD (x//y): 1. Perform a division (I don't care about the details here). 2. Return an integer value q (even if it's stored in a float). 3. The absolute difference between the mathematical division q'=x/y and the returned result q is less than 1, since it's just a floor operation, right? 1//0.1 = 9.0 violates my personal last expectation and I guess I'm not the only one. My use case: I need to perform a division, but the method only accepts integer values, so what I used to do is FD. Since today I'm using int(x/y) or floor(x/y). -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: Martin: Ok, just as you suggested, I did the calculations on a sheet of paper: floor(1 mathematically-divided-by 0.1) = floor(10) = 10 qed ;-) -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16460] Strange results for floor division (//) with non-integer divisors
Tom Pohl added the comment: Since nobody seems to share my point of view, I give up. :-) Thanks for your support and for working on Python (the best programming language as we all know), Tom -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue16460 ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
