Steven D'Aprano added the comment:
In case it isn't obvious, my example is meant to be pseudo-code, not the exact
implementation used.
--
___
Python tracker
<http://bugs.python.o
Steven D'Aprano added the comment:
Can confirm the expected behaviour (printing True) in Python 2.4 through 2.7,
3.3, Jython 2.5, and even venerable old Python 1.5 (where it prints 1).
But *not* IronPython 2.6, where it prints False.
In 3.6, the difference seems to be here:
New submission from Steven D'Aprano:
An occasionally requested feature is for a shuffled() function, related to the
in-place random.shuffle() as sorted() is to list.sort().
See the latest example:
https://mail.python.org/pipermail/python-ideas/2016-September/042096.html
--
mes
New submission from Steven D'Aprano:
Currently, math.isnan(n) and math.isinf(n) for n an int may raise OverflowError
if n is too big to convert to a float, e.g.:
py> math.isnan(10**1)
Traceback (most recent call last):
File "", line 1, in
OverflowError: int too large t
Steven D'Aprano added the comment:
As a convenience for whom? Certainly not the poor user, who thinks that
math.isnan(x) should return False if the number x is not a NAN. Since
neither 10**1 nor 10**10 are NANs, why should one return correctly
and the other raise a completely spu
Steven D'Aprano added the comment:
On Tue, Sep 06, 2016 at 05:59:08PM +, Mark Dickinson wrote:
> Why do you single out `int` for special treatment,
Mostly as a demonstration for what could be done, not necessarily as
what should be done. Secondly as a potential optimization. Why g
Steven D'Aprano added the comment:
That is because of floating point rounding.
When you calculate a/23, the result is the approximate float
2.659090889061502e+18 instead of the exact integer result 2659090889061502012.
Converting to an int gives you a result which is too small:
py>
Steven D'Aprano added the comment:
As discussed with Ned by email, I'm currently unable to build 3.6 and won't
have time to work on this before b1. As discussed on #27761 my tests here are
too strict and should be loosened, e.g. from assertEqual to assertAlmostEqual.
Ned wrot
Steven D'Aprano added the comment:
As discussed with Ned via email, this issue shouldn't affect the public
geometric_function and the failing tests (currently skipped) are too strict.
The existing tests demand an unrealistic precision which should be loosened,
e.g. from asse
New submission from Steven D'Aprano:
On Centos 5.11, building fails with:
Python/dtrace_stubs.o: In function `PyDTrace_LINE':
/home/steve/python/python-dev/cpython/Include/pydtrace.h:28: multiple
definition of `PyDTrace_LINE'
Python/ceval.o:/home/steve/python/python-dev/
Steven D'Aprano added the comment:
Ned, I know my system is old so I understand if 3.6 no longer supports
gcc 4.1. Tell me what minimum version I should use (4.8?) and I'll find
a way to upgrade or use another system.
Shouldn't the build system explicitly report that the compi
New submission from Steven D'Aprano:
>>> statistics.geometric_mean([0.7 for _ in range(5000)])
Traceback (most recent call last):
File "/Users/mdickinson/Python/cpython-git/Lib/statistics.py", line 362, in
float_nroot
isinfinity = math.isinf(x)
OverflowError: int
Steven D'Aprano added the comment:
On Mon, Sep 12, 2016 at 03:35:14PM +, Mark Dickinson wrote:
> statistics.geometric_mean(0.7 for _ in range(5000))
I've raised a new ticket #28111
--
___
Python tracker
<http://bugs.pytho
Steven D'Aprano added the comment:
> Surely this isn't intended behavior (?)
It is indeed. That's standard behaviour for GNU getopt, which the Python module
is modelled after:
[steve@ando ~]$ getopt --version
getopt (enhanced) 1.1.4
[steve@ando ~]$ getopt --versi
getop
Steven D'Aprano added the comment:
> How is silently failing to resolve input errors okay ?
You haven't demonstrated that it fails to resolve input errors. You have
demonstrated a *feature*, not a bug: getopt will accept prefixes if they
unambiguously match ONE long option only.
Steven D'Aprano added the comment:
> argparse here I come!
https://docs.python.org/2/library/argparse.html#argument-abbreviations-prefix-matching
Prefix matching is a standard feature of all command line option parsers
that I
New submission from Steven D'Aprano:
It is moderately common to want to join a sequence of substrings with a
delimiter rather than a separator, e.g. when joining a sequence of lines into a
single string, you usually want a trailing newline as well as newlines between
the lines. E.g.:
Steven D'Aprano added the comment:
> lines = ''.join(substring + '\n' for substring in substrings)
Huh. There were three of us looking at this at work yesterday, and none
of us thought of that.
--
___
Python trac
Steven D'Aprano added the comment:
> * Display the average, rather than the minimum, of the timings *and*
> display the standard deviation. It should help a little bit to get
> more reproductible results.
I'm still not convinced that the average is the right statistic to
Steven D'Aprano added the comment:
> I'd suggest to display all values and base the findings on
> all available values, rather than just one:
> min, max, avg, median, stddev.
If we're going to go down that path, I suggest using something like:
https://en.wikipedia.org/
Steven D'Aprano added the comment:
> Looking again at the comments for the other respondents, I think this
> should just be closed. It doesn't make sense to disturb a long
> standing API or the break the join/split symmetry.
For what it's worth, in hindsight I agree.
Steven D'Aprano added the comment:
Unfortunately I'm in a pickle at the moment, I cannot build 3.6 on any
of the machines I have available (three), and no time to upgrade them to
something that will build 3.6. But I can provide some tests, if
somebody is willing to review and check
Steven D'Aprano added the comment:
Looks good for me.
Thanks for catching this: I knew it was a bug, but then I ran into the issue
that I could no longer build 3.6 before I could fix it, and between that and
various issues in the real world I never got back to
Steven D'Aprano added the comment:
> The newly-added statistics.geometric_mean function appears to have no
> tests at all
That's weird and unfortunate. I certainly wrote tests, and I have a
backup of them. I have no idea what happened.
Attached is a patch that adds the tests,
Steven D'Aprano added the comment:
> Steve, I really think we should postpone to 3.7. [...]
If these fixes have to be in by the next beta (10th Oct), I fear that
you are right. I can build up to changeset 103135:8b74e5528f35, but not
beyond. I will be able to rectify that, but reali
Steven D'Aprano added the comment:
I'm sorry to say that due to technical difficulties, geometric mean is not
going to be in a fit state for beta 2 of 3.6, and so is going to be removed and
delayed until 3.7.
--
priority: release blocker ->
versions: +Python 3.
Changes by Steven D'Aprano :
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/issue28351>
___
___
Python-bugs-list mailing list
Unsubscr
Changes by Steven D'Aprano :
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/issue28328>
___
___
Python-bugs-list mailing list
Unsubscr
Changes by Steven D'Aprano :
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/issue28327>
___
___
Python-bugs-list mailing list
Unsubscr
Changes by Steven D'Aprano :
--
versions: -Python 3.6
___
Python tracker
<http://bugs.python.org/issue28111>
___
___
Python-bugs-list mailing list
Unsubscr
Changes by Steven D'Aprano :
--
versions: +Python 3.7 -Python 3.6
___
Python tracker
<http://bugs.python.org/issue27761>
___
___
Python-bugs-list m
New submission from Steven D'Aprano:
Did you take a picture of the screen with your iPhone? Why didn't you take a
screenshot? Or better still, since this is a text-based medium not a graphics
error, copy and paste the text involved? That's easier for people to work with,
incl
Steven D'Aprano added the comment:
See #28366
--
nosy: +steven.daprano
___
Python tracker
<http://bugs.python.org/issue28365>
___
___
Python-bugs-list m
Changes by Steven D'Aprano :
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.5
___
Python tracker
<http://bugs.python.org/is
Changes by Steven D'Aprano :
--
nosy: +terry.reedy
___
Python tracker
<http://bugs.python.org/issue28365>
___
___
Python-bugs-list mailing list
Unsubscr
Steven D'Aprano added the comment:
This was discussed on Python-Ideas back in July:
https://mail.python.org/pipermail/python-ideas/2016-July/041153.html
I don't recall any opposition, although Nick suggested that possibly a better
idea was to resurrect the `apply` built-in into
Steven D'Aprano added the comment:
There seems to be consensus that this should be treated as a bug fix, not a new
feature. Could this still make it into 3.6 even though it missed the first beta?
--
nosy: +steven.daprano
___
Python tracker
Steven D'Aprano added the comment:
To be clear, let's look at the first failed assertion:
AssertionError: 32.78 != 32.775 within 2 places
It sure *looks* like 32.775 ought to round to 32.78. And indeed it would, if it
actually was 32.775. But despite appearances, it isn't. S
Steven D'Aprano added the comment:
On Sat, Nov 12, 2016 at 08:23:45AM +, Raymond Hettinger wrote:
> I can't even dream up any scenarios where
> ``operator.subscript[3:7:2]`` would be better than
> ``slice(3, 7, 2)``.
For that specific example, I completely agree.
Steven D'Aprano added the comment:
I disagree that "aliasing" is more accurate.
We have a perfectly good name for symbols in Python: "name". A value (and that
includes functions) can have multiple names. It seems to me that if we're to
start distinguishing b
Steven D'Aprano added the comment:
> And this is aliasing:
> g = f
Is it only aliasing if you know that f is a function? I don't mean that
as a rhetorical question -- I'm asking if we're comfortable with the
idea of saying that g is an ali
Steven D'Aprano added the comment:
Please don't post screen shots of text. Copy and paste the text into the bug
report. Some people (those who are blind, visually impaired or using a
screen-reader for some other reason) cannot see the screen shot, and even those
who can prefer to
Steven D'Aprano added the comment:
If you're quoting from the docs, its a good idea to give the URL to *which*
documentation you are reading, not just a copy of the text.
--
___
Python tracker
<http://bugs.python.o
1401 - 1443 of 1443 matches
Mail list logo
