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 <rep...@bugs.python.org>
<http://bugs.p
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 deal
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 alias when f is (say) a
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 betwe
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. Bu
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. Sure, the number
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:
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 functools
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
nosy: +terry.reedy
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
components: +Windows
nosy: +paul.moore, steve.dower, tim.golden, zach.ware
versions: +Python 3.5
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Steven D'Aprano added the comment:
See #28366
--
nosy: +steven.daprano
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28365>
___
___
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,
including those who
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
versions: +Python 3.7 -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
versions: -Python 3.6
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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.7 -Python
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 realistica
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, but obvio
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
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 them
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. I'm a little e
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/wiki/Five-numbe
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 use
here.
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 tracker <rep...@bugs.pyth
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.:
'\n
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 k
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. If the pre
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
getopt (enhanced) 1.
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 <rep...@bugs.python.org&
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 t
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 compiler is too
old
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/cpython/Include
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 assertEqual
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 wrote:
"I
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> a =
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
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 spurious
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 to con
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
--
messages
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:
py>
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 <rep...@bugs.python.org>
<http://bugs.python.org/i
Steven D'Aprano added the comment:
This behaviour is expected. The factorial function calls itself, it doesn't
call "f", but it is "f" which has the cache. So the call to f() goes through
the cache, misses, and then calls factorial(), which has no cache.
In effect, w
New submission from Steven D'Aprano:
hashlib digests should have a nicer interface to allow conversion to ints.
Currently we write int(x.hexdigest(), 16) which is less than obvious and easy
to get wrong. It would be nice to be able to just say int(x) (that's my strong
preference) or x.as_int
Steven D'Aprano added the comment:
> I do think that the documentation could be a lot clearer.
Which specific documentation are you referring to? The "What's New" document
from 3.0? That's a historical document, a snapshot of the past.
If you have a concern about the current
Steven D'Aprano added the comment:
This has been really eye-opening, and I just wanted to drop you a note
that I am watching this thread carefully. My first priority is to get
the tests all passing before beta 1 on 2016-09-12, even if (as seems
likely) that means weakening the tests
Steven D'Aprano added the comment:
Just in case anyone else thinks this is a good idea, here's a patch.
--
keywords: +patch
Added file: https://bugs.python.org/file44218/identity.patch
___
Python tracker <rep...@bugs.python.org>
Steven D'Aprano added the comment:
I had a work mate make this exact same point literally yesterday. He asked me
if Python had an identity function, and when I suggested just using `lambda x:
x` he grouched that this wasn't sufficiently obvious enough as "identity" is
self-e
Steven D'Aprano added the comment:
Terry J. Reedy added the comment:
> Steven: "You should use `__builtin__` in Python 2 and `builtins` in
> Python 3." I presume this is for import statements.
My understanding is that __builtins__ is intended to be for the private
us
Steven D'Aprano added the comment:
On Thu, Aug 18, 2016 at 12:26:56PM +, Armin Rigo wrote:
> ...ah, upon closer inspection, we don't use the ``interact()`` method
> anyway. We already copied and tweaked this method: one problem was
> that it gives no way to run without printing
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
assignee: docs@python -> steven.daprano
nosy: +steven.daprano
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pyt
Steven D'Aprano added the comment:
At the risk of muddying the waters even further, I'd like to make _normalize a
public parameter in Python 3.7. There's an interesting operation you can do
with fractions, the mediant:
https://en.wikipedia.org/wiki/Mediant_%28mathematics%29
http
Steven D'Aprano added the comment:
For future reference, don't post screen shots. Copy and paste the text of your
code and its output. You don't program with Photoshop, you program with a text
editor.
Screen shots make it impossible to copy the code, search for the text, and make
Steven D'Aprano added the comment:
On Thu, Aug 18, 2016 at 08:19:25AM +, Armin Rigo wrote:
> Can we make the exit message optional?
Sure. What API do you prefer? I'm thinking to just give interact() an
optional "exitmsg" argument, similar to banner:
def interact(banner=None,
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
--
resolution: -> fixed
stage: -> resolved
status: open -> closed
___
Python tracker <rep...@bugs.python.org>
<http://bu
Steven D'Aprano added the comment:
Still to do (coming soon):
- make the 0.2s time configurable;
- have `timeit` and `repeat` methods (and functions) fall back
on `autorange` if the number is set to 0 or None.
--
assignee: -> steven.dapr
Steven D'Aprano added the comment:
On Sun, Aug 14, 2016 at 12:05:37PM +, Mark Dickinson wrote:
> But I don't think there's a real problem here so long as you don't
> have an expectation of getting super-accurate (e.g., correctly rounded
> or faithfully rounded) results
Steven D'Aprano added the comment:
On Sun, Aug 14, 2016 at 10:52:42AM +, Mark Dickinson wrote:
> Same deal here: those aren't the actual errors; they're approximations
> to the errors, since the computations of the epsilons depends on (a)
> the usual floating-point rounding,
Steven D'Aprano added the comment:
On Sun, Aug 14, 2016 at 08:29:39AM +, Mark Dickinson wrote:
> Steven: can you explain why you think your code *should* be giving
> exact results for exact powers? Do you have an error analysis that
> says that should be the case?
No error analy
Steven D'Aprano added the comment:
I've created a new issue to track the loss of accuracy on PowerPC:
http://bugs.python.org/issue27761
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Steven D'Aprano added the comment:
Tests fail on a Power PC buildbot:
http://buildbot.python.org/all/builders/PPC64LE%20Fedora%203.x/builds/1476/steps/test/logs/stdio
==
FAIL: testExactPowers (test.test_statistics.Test_Nth_Root
New submission from Steven D'Aprano:
First reported by Martin Panter here:
http://bugs.python.org/issue27181#msg272488
I'm afraid I don't know enough about PowerPC to suggest a fix other than
weakening the test on that platform.
--
assignee: steven.daprano
messages: 272638
nosy
Steven D'Aprano added the comment:
Correction: `importlib.import_module` is also available in Python 2.7.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Steven D'Aprano added the comment:
That is not a bug, it is a feature. `eval` only evaluates *expressions*, not
statements, and `import` is a statement. Neither of those is going to change.
Starting in Python 3.1, you could use `import_module`:
https://docs.python.org/3/library/importlib.html
Steven D'Aprano added the comment:
I thought about special-casing n=2 to math.sqrt, but as that's an
implementation detail I can make that change at any time. According
to my testing, math.pow(x, 0.5) is no worse than sqrt, so I'm not
sure if there's any advantage to having yet another branch
Steven D'Aprano added the comment:
If this is added, should this signum function be the two value version that
returns 1 for zero, or the three value version that returns 0? Should it
distinguish between signed zeroes +0.0 and -0.0? What should it do for NANs
(raise, return a NAN, copy
Steven D'Aprano added the comment:
On Tue, Aug 09, 2016 at 06:44:22AM +, Ram Rachum wrote:
> For `geometric_mean`, maybe I'd add one sentence that describes
> how the geometric mean is calculated.
What do you mean? As in, the mathematical definition of geometric mean?
Or do you mean
Steven D'Aprano added the comment:
> Converting n to an int
Oops. Obviously I meant converting n *from* an int *to* a float.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.or
Steven D'Aprano added the comment:
Your description is hard to understand, and doesn't give enough detail, but I
*think* I can guess what you might be referring to.
If you start with a really big integer, and divide, you get a float. But really
big floats cannot represent every number exactly
Steven D'Aprano added the comment:
Nick gave a +1 to my auto-range patch with callback on 2016-05-13, and there's
been no negative feedback since. Should I go ahead and check it in for 3.6?
--
___
Python tracker <rep...@bugs.python.org>
Steven D'Aprano added the comment:
On Tue, Jul 26, 2016 at 03:27:29PM +, R. David Murray wrote:
[...]
> getopt is explicitly emulating the C getopt
There are lots of differences between the C getopt and the Python
version, and the Python version is described as offering an API
"
Steven D'Aprano added the comment:
Serhiy Storchaka added the comment:
> It makes Python getopt behave less like the C getopt.
Exactly! If C getopt allows whitespace in long options, it's a GOOD
thing to avoid such a poor design. Who would want a option --foo (note
the trailing sp
Steven D'Aprano added the comment:
I expect that ESC should always cancel, and RETURN/ENTER should always accepts
(OK or Save or whatever the "main" button is) regardless of where the focus is.
If you want a keyboard shortcut to push the button with focus, use SPACE,
Steven D'Aprano added the comment:
On Tue, Jul 26, 2016 at 04:50:33AM +, Serhiy Storchaka wrote:
> My answer: if you don't want a space in your long_option, don't put a
> space in there. There is no a bug in Python,
That's why I listed it as an enhancement, not a bug.
> and
Steven D'Aprano added the comment:
Thanks for the quick review, I've fixed the issues you mentioned.
--
Added file: http://bugs.python.org/file43886/getopt.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
New submission from Steven D'Aprano:
As reported here:
https://mail.python.org/pipermail/python-list/2016-July/711333.html
there's a possible annoyance with getopt when you accidentally leave whitespace
on a long option. On my Centos system, getopt ignores leading and trailing
whitespace
Steven D'Aprano added the comment:
I'm reluctant to call this a behaviour bug, because I'm reluctant to guarantee
the *precise* behaviour when the classes are different.
I haven't checked the source of dict.__contains__, but by experimentation it
seems that:
needle in {key: value}
calls
Steven D'Aprano added the comment:
This time, with a patch that includes updated tests.
--
Added file: http://bugs.python.org/file43793/code.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Changes by Steven D'Aprano <steve+pyt...@pearwood.info>:
Removed file: http://bugs.python.org/file43791/code.patch
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
New submission from Steven D'Aprano:
Way too often I've lost track of whether I'm in the code.interact() REPL or the
original REPL, or hit Ctrl-D once too often, and accidentally quit the real
REPL. It is easy to lose track, since the real and imitation REPL both use the
same prompts
Steven D'Aprano added the comment:
Raymond, that was a fantastic explanation. Would you be willing to turn it into
a FAQ? Or if you don't have the time, to allow somebody to steal your
description and use it?
--
nosy: +steven.daprano
___
Python
Steven D'Aprano added the comment:
Does anyone have any strong feeling about the name for these functions?
gmean and hmean;
geometric_mean and harmonic_mean
And "subcontrary_mean" is not an option :-)
--
___
Python tracker <rep...@bu
Steven D'Aprano added the comment:
The behaviour of both are correct: the binary float nearest to 4.4 is just a
smidgen *bigger* than the exact decimal 4.4, so 44//4.4 truncates to 9.0. But
floor(44/4.4) evaluates 44/4.4 first, and that rounds rather than truncating,
giving 10.0, which
Steven D'Aprano added the comment:
I haven't studied your code in detail (I won't be qualified to judge it) but I
notice this comment:
/* Hit the faster unicode_concatenate method if and only if
all the following conditions are true:
1. The left operand is a unicode type
2
Steven D'Aprano added the comment:
Hi Zhihan Chen, I see this issue is closed, but for future reference please
don't post screenshots to report issues unless they are really needed. For text
output, just copy the text from your terminal and paste it into your bug
report. Making a screen shot
Steven D'Aprano added the comment:
I know this issue is closed, but for future reference, ShubhamSingh.er, if you
submit any further bug reports, please don't submit screen shots unless
necessary. Just copy and paste the text from your terminal into the issue
tracker. A screen shot is more
Steven D'Aprano added the comment:
On Sat, Jul 02, 2016 at 11:40:48AM +, Utkan Gezer wrote:
>
> New submission from Utkan Gezer:
>
> An issue of enhancement by the introduction of a built-in product()
> function for the multiplication operation, functions similar to
Steven D'Aprano added the comment:
On Mon, Jun 20, 2016 at 09:02:09PM +, Tim Peters wrote:
> Note that the very popular TI graphics calculators have had a distinct
> nth-root function at least since the TI-83. It's a minor convenience
> there.
Likewise HP calculator
Steven D'Aprano added the comment:
For starters, dunder names like __json__ are reserved for Python's own use, so
you would have to get the core developers to officially bless this use.
But... I'm not really sure that "the responsibility of determining how an
object should be repres
Steven D'Aprano added the comment:
I suggested on python-ideas that the math module be given a pure-Python front
end. Guido wasn't too keen on that idea, so I won't push for it.
He did agree that having nroot in math was a reasonable idea. If I attach a
pure Python implementation and tests
New submission from Steven D'Aprano:
For Issue27181 (add geometric mean to statistics module), I need a function to
calculate nth roots that is more accurate than pow(x, 1/n). E.g. math.pow(1000,
1/3) returns 9.998 instead of 10.0.
I have a pure-Python implementation of nroot
New submission from Steven D'Aprano:
The docs for locals() warn not to write to the dict returned, as it may not
have the intended effect of modifying the actual variables seen by the
interpreter.
https://docs.python.org/3/library/functions.html#locals
But as I understanding it, using locals
Steven D'Aprano added the comment:
Thanks Julio,
I hope to get to this over the next week. Please feel free to prod me if
you see no action by then.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/i
Steven D'Aprano added the comment:
Relevant: issue #27293
(I've taken the liberty of subscribing those on this issues nosy list to the
new issue, I hope that's okay)
--
nosy: +steven.daprano
___
Python tracker <rep...@bugs.python.org>
New submission from Steven D'Aprano:
Write some documentation for the ``secrets`` module summarizing the issues
relating to /dev/[u]random, getrandom, etc. There's a lot of confusion about
these issues, and the web contains a lot of misinformation, so being able to
point to the secrets docs
Steven D'Aprano added the comment:
I don't want to start another huge thread on python-dev unless really
necessary. What should happen to random.SystemRandom?
(1) nothing, it stays as it is, and if ``secrets`` needs better, it can
subclass it;
(2) it changes to use ``os.getrandom
Steven D'Aprano added the comment:
On Thu, Jun 09, 2016 at 09:24:04AM +, Mark Dickinson wrote:
> On the other hand, apparently `exp(mean(log(...)))` is good enough for SciPy:
Hmm, well, I don't have SciPy installed, but I've found that despite
their (well-deserved) reputation, nu
Steven D'Aprano added the comment:
Yes, it is intended. Commas create tuples, not parentheses. (With the exception
of the empty tuple.) The parens are just for grouping and precedence. `1,` is a
tuple, regardless of whether you use parens around it or not.
--
nosy: +steven.daprano
Steven D'Aprano added the comment:
"file://a" is a valid relative file path, for a directory called "file:" and a
file called "a", so normpath should return "file:/a".
--
nosy: +steven.daprano
___
Pytho
1101 - 1200 of 1436 matches
Mail list logo
