Change by Tom Pohl :
--
nosy: -tom.pohl
___
Python tracker
<https://bugs.python.org/issue45466>
___
___
Python-bugs-list mailing list
Unsubscribe:
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
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 s
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
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
<ht
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
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
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
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 "
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
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
<http://bugs.python.org/issue16
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
<http://bugs.python.org/issue16
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
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
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
15 matches
Mail list logo
