Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue36259>
___
___
Python-bugs-list mailing list
Unsubscr
Steven D'Aprano added the comment:
I'm closing this issue in favour of Raymond's #35892, thank you to everyone
even if your PRs didn't get used, I appreciate your efforts.
--
resolution: -> rejected
stage: patch review -> resol
Steven D'Aprano added the comment:
I've done some spot checks of NormDist.pdf and .cdf and compared the results to
those returned by my TI Nspire calculator.
So far, the PDF has matched that of the Nspire to 12 decimal places (the limit
the calculator will show), but the CDF dif
Steven D'Aprano added the comment:
Looks good to me, I'm happy to accept it.
Thank you for your efforts Raymond, can I trouble you to do the merge yourself
please, I'm still having issues using the Github website.
--
___
Python
Steven D'Aprano added the comment:
> I'm assuming you meant 5.374 rather than 5.372 in the first Nspire result.
Yes, that was a typo, sorry.
Thanks for checking into the results.
--
___
Python tracker
<https://bugs.pytho
Steven D'Aprano added the comment:
> The footnote about why eval/exec cannot be used for arbitrary code
Which footnote? I see nothing here:
https://docs.python.org/3/library/functions.html#eval
> On that point, I still don't understand why PyObject_GetIte
Steven D'Aprano added the comment:
Prakhar, for future reference, please don't submit unnecessary screenshots to
report bugs. Screen shots are hostile to the blind or visually impaired, who
may be reading this with a screen-reader, and they make it impossible for us to
copy your c
Steven D'Aprano added the comment:
Looks good to me.
Later I will do some spot checks against the results returned by the Nspire
calculator, but in the meantime I think this can go in. Thanks for your efforts
Raymond, I think this NormalDist is shaping up to be a great add
Steven D'Aprano added the comment:
On Tue, Mar 19, 2019 at 01:06:45AM +0000, Steven D'Aprano wrote:
> Later I will do some spot checks against the results returned by the Nspire
> calculator
Looks good to me, they agree to 6 decimal places in my tests. Following
Mark's
Steven D'Aprano added the comment:
> Were you working on the additional functionality that you mentioned in
> msg272704 or would that be open for someone else to do? Thanks!
Please consider it open. I don't expect it to be difficult, it's just
finding the Round Tuits.
Steven D'Aprano added the comment:
> In the spirit of "perfect is the enemy of good", would it be
> reasonable to start with a simple, fast implementation using
> exp-mean-log? Then if someone wants to make it more accurate later,
> they can do so.
I think th
Steven D'Aprano added the comment:
You are one person, who has used this feature for what, a month elapsed
time? 300 person-hours actual experience with it? Allowing top-level
unparenthisized walrus expressions will affect hundreds of thousands of
people, for collectively millions of
Steven D'Aprano added the comment:
Python is a programming language, and we're probably not going to care too much
about compliance with ZFC set theory unless there is good *practical* and not
theoretical reason to care. That's not to say that we want to break ZFC, only
that
Steven D'Aprano added the comment:
(Aside: that's interesting, normally if I try to post a comment to an issue,
and somebody else edits it in the meantime, the message doesn't get posted and
I get a error message saying that the page has been edited. This
Steven D'Aprano added the comment:
I see this has been rejected for the math module, but I wonder whether it
should be considered for Decimal? I recall Mark Dickinson demonstrating this
lovely little bit of behaviour:
py> from decimal import getcontext, Decimal
py> getcontext().
New submission from Steven D'Aprano :
str.capitalize appears to uppercase the first character of the string, which is
okay for ASCII but not for non-English letters.
For example, the letter NJ in Croatian appears as Nj at the start of words when
the first character is capitalized:
Nje
Steven D'Aprano added the comment:
I think adding quantiles (sometimes called fractiles) is a good feature to add.
I especially have some use-cases for quartiles. I especially like that it
delegates to the inv_cdf() method when available, and I'm happy with the API
you suggested
Steven D'Aprano added the comment:
The file you have attached doesn't seem to be a Python script, it seems to be
some sort of Windows batch file or similar.
Please supply an actual Python file. (Hint: remove the "del code.py" line from
your batch file.) Also, copy and
Steven D'Aprano added the comment:
The error message is correct. The bug is in your code. Also, the code you tell
us that you are running is not the same as the code you are actually running.
You should not call __init__ directly as you do:
# this is wrong
Person.__init__(
Steven D'Aprano added the comment:
Sorry, I don't understand your demonstration. What's the mystery ``parser``
object with an ``expr`` method? What is it doing?
Your comment says "all binary/unary number ops work" but I don't know what you
mean by "work&q
Steven D'Aprano added the comment:
Please don't post screen shots of text, copy and paste the text as text.
Screen shots are hostile to the blind and visually impaired as screen-readers
don't work with them. They make it impossible for us to copy your code to run
it ourselv
Steven D'Aprano added the comment:
Thanks Ryan.
> PermissionError: [WinError 5] 拒绝访问。: 'L:\\Temp'
Can you translate the error message into English for us please?
--
___
Python tracker
<https://bugs.
Steven D'Aprano added the comment:
Hi PushkarVaity, and welcome!
I hope that Matthew's suggestion fixes your code for you, but please remember
that this is a bug tracker for bugs in the Python language and standard
library, not a help desk.
As a beginner, 99.9% of the times you
Steven D'Aprano added the comment:
Hi Maakvol,
Please remember that this is a bug tracker for bugs in the Python language and
standard library, not a help desk.
As a beginner, 99.9% of the times you think that you have found a bug in
Python, you haven't, it will be a bug in you
New submission from Steven D'Aprano :
(Apologies if this is the wrong place for reporting website bugs.)
The website is not rendering doctest directives or comments, either that or the
comments have been stripped from the examples.
On the doctest page itself, all the comments are mi
Steven D'Aprano added the comment:
Hi Raymond,
Thanks for working on this, I'm really keen to see this happen and I
appreciate your efforts so far.
Your arguments have also convinced me that the default calculation
type you chose (PERCENTILE.EXC or R type=6) is suitable.
Bu
Steven D'Aprano added the comment:
> Not all console configurations can correctly render smart quotes in
> help() text. See the "Æ" in "superclass's" below.
That suggests to me a mismatch in encodings, rather than inability to
render curly quotes at all. I
Steven D'Aprano added the comment:
On Thu, May 02, 2019 at 11:40:45AM +, Eric V. Smith wrote:
>
> New submission from Eric V. Smith :
>
> I originally propsed this here:
> https://mail.python.org/pipermail/python-ideas/2018-October/053956.html, and
> there has al
Steven D'Aprano added the comment:
I doubt this is important enough to go into builtins, the only practical
use-case I know of for this function is with numbers, so this could go in the
math module.
But putting that aside, there are some other problems:
- it isn't clear that
Steven D'Aprano added the comment:
> Steven: We shouldn't block this immediately useful feature from going
> in for f-strings on waiting for some much broader first class access
> to expressions feature. !d would be practical today.
I hear you, and after giving it much m
Steven D'Aprano added the comment:
David, I'm pretty sure that SilentGhost is correct. You are misreading the
error message: it has nothing to do with the negative index.
The problem is that your `insert_value` function returns None, not the list. I
believe that what you have done
Steven D'Aprano added the comment:
In my experience, beginners have enough trouble getting packages right without
complicating the tutorial with a rarely-used advanced feature like namespace
packages.
I don't think this needs more than perhaps a footnote, if that.
-
Steven D'Aprano added the comment:
Yes please for this!
The two usual versions are isqrt and nsqrt:
isqrt(n) = largest integer ≤ √n
nsqrt(n) = closest integer to √n
although to be honest I'm not sure what use cases there are for nsqrt.
--
nosy: +stev
Steven D'Aprano added the comment:
+1
There's a long thread on something similar here:
https://mail.python.org/pipermail/python-ideas/2018-March/049564.html
Carrying over into the following month:
https://mail.python.org/pipermail/python-ideas/2018-April/049582.html
Here'
Steven D'Aprano added the comment:
For the record, I just came across this proposed feature for Java:
https://openjdk.java.net/jeps/8222530
Add text blocks to the Java language. A text block is a multi-line
string literal that avoids the need for most escape sequ
Steven D'Aprano added the comment:
> Doctest directives in code examples should be suppressed everywhere
> *except* in the doctest.html examples showing how to use directives.
> The patch only exposes them for doctest.html and not for ctypes or
> anywhere else.
Thanks f
Steven D'Aprano added the comment:
That does look at first glance like a bug in // to me. 0.9/0.1 is correctly
rounded to 9.0 exactly, so flooring it should return 9 (as it does):
# Python 3.5 on Linux
py> 0.9/0.1 == 9
True
py> math.floor(0.9/0.1)
9
So I too would expect that 0.9/
Steven D'Aprano added the comment:
What sort of statistics, and why do you think they are going to be meaningful?
Measurement errors in the timings aren't two-sided, they are only one-sided,
which means calculating the mean and standard deviation isn't appropriate. This
is do
Steven D'Aprano added the comment:
> What sort of statistics...?
I answered my own question... I see that in your PR, you return a dict with the
mean, median, *population* variance and standard deviation, and total.
Why the population variance/stdev rather than the sample? Th
Steven D'Aprano added the comment:
Oh I can just imagine the bike-shedding on this one :-)
I'm not really convinced this is needed, but for what it's worth I think that
given the intended use-case (checking function parameters) ValueError would be
a more appropriate default
Steven D'Aprano added the comment:
Since this is intended for argument checking, i.e. testing preconditions, the
Eiffel term "require" seems more appropriate.
https://www.eiffel.org/doc/eiffel/ET:%20Design%20by%20Contract%20(tm),%20Assertions%20and%20Exception
Steven D'Aprano added the comment:
I agree with Cheryl that it would be a good idea to mention this change in the
re docs, since regexes are especially likely to run into this issue.
--
nosy: +steven.daprano
___
Python tracker
&
Steven D'Aprano added the comment:
On Fri, Jan 19, 2018 at 11:48:46PM +, STINNER Victor wrote:
> The timeit module of the stdlib computes 5 values by default... I'm
> not sure that it's revelant to compute the standard deviation only on
> 5 values.
I made the sam
Steven D'Aprano added the comment:
This looks like a broken or incorrectly configured Django installation.
What happens when you run this from your operating system shell?
python3.6 -E -S
If you are on Windows, you might need to use this instead:
py -E -S
--
nosy: +steven.da
Steven D'Aprano added the comment:
This is not a bug, it is a FAQ to do with the properties of binary floating
point numbers.
https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate
--
nosy: +steven.daprano
resolution: -> not a b
Steven D'Aprano added the comment:
Hi Kenny, and thanks, but I'm not sure what your point is. Are you claiming
this is a bug in the code or the documentation?
For what it is worth... mutable defaults *are* a "gotcha", so the documentation
isn't wrong. And mutable d
Steven D'Aprano added the comment:
On Thu, Jan 25, 2018 at 02:28:17PM +, R. David Murray wrote:
> obviously I missed that mutation of the value
> in the code review of the patch that added those lines :(
The docstring for send_message does say
If the sender or any of th
Steven D'Aprano added the comment:
Dan, I don't understand what you think the code snippet shows: you're calling
isclass on an object which *actually is a class* and show that it returns True.
What did you expect it to return? How does the code snippet you give
demonstrate
Change by Steven D'Aprano :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue32778>
___
___
Python-bugs-
Steven D'Aprano added the comment:
Thanks for the link to the Stackoverflow discussion. Currently there are three
answers: two (correctly) answer that the constant as given is the most accurate
value for IEEE-754 floats.
Tim Peters has answered that: https://stackoverflow.com/a/486
Steven D'Aprano added the comment:
+1
Please also support using a one-element tuple:
`for y in (f(x),)`
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/is
Steven D'Aprano added the comment:
What makes the minimum mode better than the maximum?
--
___
Python tracker
<https://bugs.python.org/issue28956>
___
___
Steven D'Aprano added the comment:
The stdlib HTML parser requires correct HTML.
To parse broken HTML, as you find in the real world, you need a third-party
library like BeautifulSoup. BeautifulSoup is much more complex (about 7-8 times
as many LOC) but can handle nearly anything a br
Steven D'Aprano added the comment:
Hi, this is for tracking bugs in the Python interpreter and standard library,
not asking for help debugging your own code. There's no reason (yet) to believe
this error is a bug in Python, you need to debug it first to ensure it is not a
bug i
Steven D'Aprano added the comment:
Its not a superfluous blank line. It is standard convention for Unix tools to
end text files (of which ini files are a kind of text file) with a final
newline \n. There are various reasons for this, but it doesn't matter what
those reason
Steven D'Aprano added the comment:
Oh, I forgot... even if it is decided that this trim_final_blankline parameter
was desirable, the patch isn't sufficient to be accepted. You would need to
also supply documentation and tests.
--
Steven D'Aprano added the comment:
This is a truly awful name, there's nothing unsafe about the hash
parameter. We rightly hesitate to label *actual* unsafe functions, like
eval and exec, with that name. Are we committed to this name?
--
nosy: +stev
Steven D'Aprano added the comment:
I think the difficulty here is that your perspective is backwards. It isn't
that sorting a generator is *slower*, it is that sorting a list is *faster*,
because there is more information available with a list and so the interpreter
can take a
Steven D'Aprano added the comment:
On Sat, Mar 10, 2018 at 06:37:28AM +, TitanSnow wrote:
>
> TitanSnow added the comment:
>
> If we treat the original behavior as a bug,
> it’s much easier to write a patch
> that just changes the default behavior
> and never
Steven D'Aprano added the comment:
On Fri, Mar 16, 2018 at 02:32:36PM +, Mark Dickinson wrote:
> For what it's worth, NumPy gives a result of NaN for the median of an array
> that contains NaNs:
By default, R gives the median of a list containing either NaN or NA
Steven D'Aprano added the comment:
This was requested once before, but rejected. I would like to see that decision
re-considered.
https://bugs.python.org/issue1880
Some months ago, there was a very brief discussion started by Lawrence
D’Oliveiro about this on the comp.lang.python news
Steven D'Aprano added the comment:
The obvious work-around of calling hypot multiple times is not only tedious,
but it loses precision. For example, the body diagonal through a 1x1x1 cube
should be √3 exactly:
py> from math import hypot, sqrt
py> hypot(hypot(1, 1), 1) == sqrt(3
Steven D'Aprano added the comment:
Ah wait, I appear to have misunderstood Raymond's request. Sorry Raymond!
(I've been spending too much time teaching Pythagoras' theorem and my mind was
primed to go directly from Euclidean distance to hypotenuse.)
Not withstanding my
Steven D'Aprano added the comment:
It has never been the case that upper() or lower() are guaranteed to preserve
string length in Unicode. For example, some characters decompose into a base
plus combining characters. Ligatures are another example. See here for more
details:
Steven D'Aprano added the comment:
In addition to Xiang Zhang's comments, this is neither a feature nor a bug, but
a misunderstanding. This has nothing to do with strings or underscores:
py> L = [1, 2, 3, 4, 5]
py> for item in L:
... L.remove(item)
...
py> L
[2, 4]
Steven D'Aprano added the comment:
Alexey, I'm afraid I can't make heads or tails of your bug report. You've gone
into a detailed description of the "bad results" you have, but you haven't
explained *why* they're bad, or what you were expecting.
I&
Steven D'Aprano added the comment:
I started to add this comment to #33218 but Raymond closed that ticket while I
was editing it.
In 3.6, dicts preserving insertion order remains an implementation detail that
cannot be relied on. It only becomes a guarantee in 3.7.
Even in 3.7, I think
Steven D'Aprano added the comment:
(Previously posted on Python-Dev.)
I think the documentation note is a good idea.
But I disagree with deprecating "cmd" unless it is actively falling
apart and no longer working, not just languishing with no feature
improvements. Just in the
Steven D'Aprano added the comment:
Possibly you may not be familiar with interval notation?
https://www.mathsisfun.com/sets/intervals.html
Since this is Python and not maths, maybe we should rethink the wording.
--
___
Python tracker
&
Steven D'Aprano added the comment:
This is not a bug, it is intentional.
In Python 2, numbers with a leading zero are interpreted as octal, leading to
surprising results:
py> 015
13
In Python 3, we use 0o15 to get octal, and 015 becomes a syntax error.
--
nosy: +steven
New submission from Steven D'Aprano :
The Python 2.x syntax for octal integers is a syntax error in 3.x, but the
error message is very uninformative:
SyntaxError: invalid token
Can this be improved? Perhaps to something like:
invalid token, use 0o prefix for octal integers
(see
Change by Steven D'Aprano :
--
type: behavior -> enhancement
___
Python tracker
<https://bugs.python.org/issue33305>
___
___
Python-bugs-list mailing li
Steven D'Aprano added the comment:
I've opened an issue to improve the error message: #33305
--
___
Python tracker
<https://bugs.python.org/issue33304>
___
__
Steven D'Aprano added the comment:
In Python 2, you have to override __getslice__ as well as __getitem__.
Try this instead:
class MyTuple(tuple):
def __getitem__(self, pos):
print "get item {}".format(pos)
return super(MyTuple, self).__getitem__(pos)
d
Steven D'Aprano added the comment:
the argument to string.strip (also lstrip and rstrip) is not an exact substring
to remove, but a set of characters to remove:
py> 'zyxzz1234'.strip('xyz')
'1234'
--
nosy: +steven.daprano
resolution: -> n
Steven D'Aprano added the comment:
I agree with Tim that this is likely to be the difference between Python 2
truncating division and Python 3 division.
For the record, I get the following results:
9997809507L Python 2.7
9997809307.0 Python 3.5
9997809307 R
9997809307 Javascript (
Steven D'Aprano added the comment:
> Even Ruby gets the right answer (9997809507) for that :-)
Oops, I forgot to say... Ruby 1.8 also does truncating division like Python 2.
--
___
Python tracker
<https://bugs.python.org
Steven D'Aprano added the comment:
Ah sheesh I copied and pasted the wrong bits. After the division terms go to
zero, you get
-590072-200112-18-18-18-18-18-18-18-18+9998599835
which goes to 9997809507 as calculated by Ruby and Python 2, and I promise
that's the end of me replying
Steven D'Aprano added the comment:
Precedence issues when dealing with units is unavoidable, I think. The units
program on Linux/Unix has similar issues, and they write their own parser and
choose their own precedence.
https://www.gnu.org/software/units/manual/html_node/Operators.htm
Steven D'Aprano added the comment:
Strings in Python 3 are already unicode.
Looking at the patch, I see a lot of fractions which display as the missing
glyph white square. For example, instead of seeing 1/9, which displays
perfectly everywhere, I see a mysterious box similar to □.
Even
Steven D'Aprano added the comment:
Hi Braiden, and welcome!
I see that the ticket has already been closed, but another note for the future:
please don't paste screenshots of your code, copy and paste the relevant source
code. We don't edit code with Photoshop, and posting
Steven D'Aprano added the comment:
Hello Quentin, and welcome.
Please don't post screen shots of text. We don't edit our code with Photoshop,
and using a screenshot makes it difficult to copy your code for testing, to
verify the bug report, and prevents the blind and visuall
Steven D'Aprano added the comment:
Joe, we have no idea what you think is the bug.
It is intentional that the second argument for range is excluded. This is
called an "half-open" range, and it helps avoid off-by-one and signpost errors.
Your comments about break, continue and
Steven D'Aprano added the comment:
I've always expected that documentation for a module can assume that the module
itself, and/or the function being described, has been imported.
On the other hand, I have no objection to making this explicit, especially in
the recipes section wher
Steven D'Aprano added the comment:
How does the performance change with this patch?
Quick-select is a nice idea in theory, but unless it is written in C, it is
unlikely to beat sorting the list unless you have HUGE data sets. Its been
nearly four years since I last did some benchmarks
New submission from Steven D'Aprano :
As mentioned on the Python-List:
https://mail.python.org/pipermail/python-list/2018-May/733061.html
random.choices() silently returns the wrong values when cumulative weights are
not given, i.e. if the user misreads the documentation and provides
Steven D'Aprano added the comment:
On Mon, May 14, 2018 at 11:54:32AM +, Paul Moore wrote:
> Requiring a pre-check on cum_weights (for example, the obvious check
> that the sequence is nondecreasing) would add an O(n) step, and so
> significantly impact performance for t
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue33501>
___
___
Python-bugs-list mailing list
Unsubscr
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue31757>
___
___
Python-bugs-list mailing list
Unsubscr
Steven D'Aprano added the comment:
What are you claiming is the bug? I don't understand what you think the problem
is.
Don't dump a large script in our laps and expect us to get a Google API key to
run it. Forget that, it isn't going to happen. Simplify your code t
Steven D'Aprano added the comment:
Oops, accidentally messed up the status. Fixing now.
Francesco, if you simplify your code and come back with a detailed description
of what you think the bug is, then we will investigate.
--
nosy: +eric.smith
resolution: -> not a b
Steven D'Aprano added the comment:
Python 2.7 is in feature freeze, so 3.7 is the absolute earliest this could be
introduced. Given how close we are to 3.7 feature freeze, 3.8 is more likely.
I don't think we would have any objections to supporting hijri calendar, in
principle
Steven D'Aprano added the comment:
Thank you for taking the time to report what you thought was a bug, but your
example is way too complicated for a bug report. We shouldn't have to study
your entire program to understand what the problem is.
I can see at least one bug in
Change by Steven D'Aprano :
--
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue31915>
___
___
Python-bugs-
Steven D'Aprano added the comment:
Thank you for the bug report Ronan, but I'm afraid that I have no idea what you
think the problematic behaviour is. I'm not going to spend the time installing
the third-party hypothesis module, and learning how to use it, just to decipher
yo
Steven D'Aprano added the comment:
I don't have Python 3.7 available to me, but in 3.5 the behaviour of
u.startswith(v) with an empty v seems consistent to me:
py> "alpha".startswith("", 20, 30)
True
py> "alpha"[20:30].startswith(""
Steven D'Aprano added the comment:
I don't understand why you think they are the wrong values. What values were
you expecting?
You have a byte array, you set the value to the byte b's', which is 115, and
you get 115. You have a (byte) character array, you set the va
New submission from Steven D'Aprano :
multiprocessing.Array slice assignment claims to require a single character
even if it requires more than one:
py> arr = multiprocessing.Array('c', 3)
py> arr[:] = b'xyz' # works
py> arr[:] = 'xyz'
Traceback (m
Change by Steven D'Aprano :
--
title: mutliprocessing.Array misleading error message in slice assignment ->
multiprocessing.Array misleading error message in slice assignment
___
Python tracker
<https://bugs.python.org
New submission from Steven D'Aprano :
multiprocessing.Array is documented as taking the same character codes as
array.array, but it also takes 'c' which is not documented.
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.Array
https://docs.python.org/3/lib
901 - 1000 of 1443 matches
Mail list logo