Steven D'Aprano added the comment:
Its not a bug, it's deliberately designed that way. is not ambiguous: it's
just zero, in any base. 0012 is ambiguous.
There's a recent thread about it here:
https://mail.python.org/archives/list/python-id...@python.org/message
Steven D'Aprano added the comment:
On Fri, Feb 07, 2020 at 12:33:45PM +, Serhiy Storchaka wrote:
>
> Serhiy Storchaka added the comment:
>
> See a discussion on Python-Dev:
> https://mail.python.org/archives/list/python-...@python.org/message/YMIGWRUERUG66CKRJXDXNPCIDHR
Steven D'Aprano added the comment:
Eric: sure, I'm happy with your modification.
Alas, I'm currently having technology issues which prevents me from
doing a PR. Would you care to do the honours?
--
___
Python tracker
<https://bugs.python.
Steven D'Aprano added the comment:
The docs are correct, you are just misinterpreting them. Which could, I guess,
suggest the docs could do with improvement.
With *one* argument, `str(obj)` returns a string via `object.__str__(obj)` or
`repr(obj)`, whichever is defined. That includes
Steven D'Aprano added the comment:
Ammar: it is definitely a feature that default values are created only once,
when the function is created, not over and over again every time the function
is called. (These are sometimes called "early binding" and "late binding"
respec
Steven D'Aprano added the comment:
> [Steven]
> > ... Try it on numbers like this:
> > ...
> > Q = P*(313*(P-1)+1)*(353*(P-1)+1)
> >
> > Q is a 397 digit Carmichael Number. Its smallest factor is P,
> > which has 131 digits.
[Tim]
>
Steven D'Aprano added the comment:
On Fri, Jan 31, 2020 at 12:15:37PM +, Vedran Čačić wrote:
>
> Vedran Čačić added the comment:
>
> is_prime that's always correct is probably not the right thing to go into
> math. Besides, now we have isqrt, it's just
>
> n&
Steven D'Aprano added the comment:
> Is there a bug here?
How about if you tell us what behaviour you expected, why you expected it, and
what you got instead, then we can tell you if your expectation was correct and
whether or not there is a bug.
You have seven results printed. I h
Steven D'Aprano added the comment:
math.remainder performs *floating point* remainder. That means it has to
convert the arguments to floats first, and there is no float capable of
representing either of those two numbers exactly:
py> '%f' % float(12345678901234567
Steven D'Aprano added the comment:
Marco, this is no more of a defect than `x*-y` or `a&~b`. It is a binary
operator followed by an unary operator, just like `x--y`, `x/-y`,
`x+-y`, `x**-y` etc. Python has at least three unary operators and at
least 17 binary operators so in t
Steven D'Aprano added the comment:
This is not a bug, as you have pointed out yourself you are using a binary plus
and a unary plus operator in the same expression.
This has been part of Python since version 1, and with operator overloading
`obj + +thing` could mean whatever the objects
Steven D'Aprano added the comment:
Please remember that not all Python programmers come from a C background
where `++n` is a pre-increment operator. Then may have a OOP background
where the unary `+` and `-` operators can do anything they like.
Making `--obj` or `++obj` a syntax error
Steven D'Aprano added the comment:
Oh come on now, this is such a trivialisation of the CoC that I cannot believe
that it is a good-faith bug report and not a troll. I'm surprised you didn't
toss in the words "triggered" and "micro-aggression" while you're at it.
The
Steven D'Aprano added the comment:
Uses for lcm are common enough that it is provided by Excel and the C++ boost.
You can use it for working out problems like:
- if event A happens every 14 days, and event B happens every 6 days, then A
and B will occur together even lcm(14, 6) days
Steven D'Aprano added the comment:
Reporting a better error message than just "Unknown error -1" is a good idea.
Stating "an error occurred..." is hardly any better.
The correct error is, I think, "permission denied". Trying to diagnose the
*specific* iss
Steven D'Aprano added the comment:
The "num" variable is not a number, it *is* a string. Just because you call it
"num" doesn't magically turn it into a number. The `input` function returns a
string.
You might be thinking of Python 2.7 where `input` automatically e
Steven D'Aprano added the comment:
There are some serious problems with the PR.
You state that these two phrases are from the runpy documentation:
* "run from the module namespace"
* "run from the file system"
but neither of those phrases appear in the runpy docume
Steven D'Aprano added the comment:
I don't think that any change is needed here. Adding "their default" to
insertion order doesn't really help: if the reader knows dicts are now ordered,
adding "default" is redundant; if the reader doesn't know, they'll still be
con
Steven D'Aprano added the comment:
Further to what Matthew said, this is not just a Python oddity. It applies to
just about all programming languages, including C, C++, Java, Javascript, Ruby,
etc. Some of them have even less precision by default.
Floats are not the same as the real numbers
Steven D'Aprano added the comment:
Attached is a script I used to test:
* that str.isspace() currently matches the definition given in the docs;
* that string.whitespace contains all whitespace characters, and nothing but
whitespace;
* that str.strip() strips off all whitespace characters
Steven D'Aprano added the comment:
There's a discrepancy between the string.whitespace constant and actual
whitespace as tested by the str.isspace() method.
I've found five ASCII whitespace characters (as reported by isspace) which
aren't in the string.whitespace constant, and 18 non-ASCII
Steven D'Aprano added the comment:
This is a new feature, not a bug, so it will apply only to 3.9. All older
versions are in feature freeze.
> there's no way to programatically acquire what characters are considered
> whitespace
https://docs.python.org/3/library/stdtypes.html#str.i
Steven D'Aprano added the comment:
I hear what you are saying, but "ulp" is the standard term of art. Sure
it is non-obvious until you learn it, just like other technical terms
like "mro", "abc" or "ast".
Mathematics and numeric programming are rif
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue29282>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven D'Aprano added the comment:
Thank you Victor!
Any chance you could look at fma too? #29282
(The reward for a job well done is to be given more jobs :-)
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue39
Steven D'Aprano added the comment:
Oops, I meant Lib/test/string_tests.py not "test_string.py".
--
___
Python tracker
<https://bugs.python.o
Steven D'Aprano added the comment:
Sorry, I disagree that this is a mere implementation detail. The term
"implementation detail" normally implies behaviour which occurs *by accident*
due to the specific implementation, rather than being intentionally chosen.
A good example is earl
Steven D'Aprano added the comment:
This behaviour that goes all the way back to Python 1.5, if not older, before
strings even had methods:
[steve@ando ~]$ python1.5
Python 1.5.2 (#1, Aug 27 2012, 09:09:18) [GCC 4.1.2 20080704
(Red Hat 4.1.2-52)] on linux2
Copyright 1991
Steven D'Aprano added the comment:
I agree, "nextafter" is so widely used it's probably pointless to fight against
the name :-)
Mark: "IEEE 754, on the other hand, requires instead nextUp and nextDown".
I know Wikipedia isn't a primary source, but it says IEEE 754 recomm
Steven D'Aprano added the comment:
> If all we're going to do is
> switch [0-9] to \d (which won't work for the places where it's
> actually [1-9], mind you)
Ah, that's a good point.
[...]
> we're better off resolving the
> inconsistency by requiring ASCII digits and consid
Steven D'Aprano added the comment:
> > ISO 8601 specifies dozens of ways to represent the same datetime
>
> Yes, but not within the same format. If someone were to choose the
> format '2014-04-10T24:00:00', they would have a reasonable expectation
> that there is only
Steven D'Aprano added the comment:
> If user code were to check for uniqueness of a datetime by comparing it as a
> string, this is where an attacker could fool this logic, by using a non-Ascii
> digit.
To me, this seems like a pretty thin justification for calling this a
Steven D'Aprano added the comment:
I'm sorry, but perhaps I may have missed something here. The behaviour you show
is what I would expect. In fact, I would expect that any two runs of your code
will likely produce different output, even on the same machine using the same
OS. I just ran
Steven D'Aprano added the comment:
On Sun, Jan 05, 2020 at 10:32:26PM +, Ram Rachum wrote:
[...]
> TypeError: __init__() takes 2 positional arguments but 3 were given
>
> As you can see, it's pretty simple to get this exception text, so I'm not
> sure why you didn't g
Steven D'Aprano added the comment:
> I think it would be a mistake to make the stdlib use this for most
> notions of what a "character" is, as I said this notion is also
> inaccurate. Having an iterator library somewhere that you can use and
> compose is great,
Steven D'Aprano added the comment:
Nice analysis and bug report, thank you! That's pretty strange behaviour for
float32, but I guess we're stuck with it.
I wonder if the type assertion has outlived its usefulness? I.e. drop the `T ==
U` part and change the assertion to `assert count
Steven D'Aprano added the comment:
On Sun, Jan 05, 2020 at 02:19:49AM +, Tim Peters wrote:
> Since, best I can recall, nobody has asked about this before
See discussion here:
https://mail.python.org/archives/list/python-...@python.org/message/5AQMG6ADD6RGPLI3VTILB2MKXMBFTIGU/
wh
Steven D'Aprano added the comment:
> builtins.TypeError: __init__() takes 1 positional argument but 2 were given
How did you get the fully qualified exception? I just get "TypeError". (Also
the error message is different in 3.8.)
> It was annoying that I didn't know which `
Steven D'Aprano added the comment:
The `<` comparison uses `__lt__` dunder if it exists, otherwise it falls back
on `__gt__`.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issu
Steven D'Aprano added the comment:
"should dict preemptively make sure it doesn't accept a sequence of sets"
No. The person on StackOverflow made a mistake in their code: they used an
unordered data structure (set) instead of an ordered data structure (tuple):
dict({i,
Steven D'Aprano added the comment:
Whether this proposed change is worth a PEP is a value judgement, but
whether it will need a PEP is, I think, a fact. It is a backwards
incompatible change (it will change the inheritance order of classes)
potentially breaking people's code. Its
Steven D'Aprano added the comment:
Have you read the description of how the MRO is calculated? It's a standard
algorithm. So long as the result matches the C3 linearisation algorithm, then
it's not a bug.
https://en.wikipedia.org/wiki/C3_linearization
https://www.python.org/download
Change by Steven D'Aprano :
--
title: Misleading documentation -> Misleading documentation for NotImplemented
___
Python tracker
<https://bugs.python.org/issu
Steven D'Aprano added the comment:
The behaviour is correct: `==` should not raise, even if both objects' `__eq__`
method returns NotImplemented.
I agree that the documentation needs improvement. Looking at the current
version:
https://docs.python.org/3/library/constants.html
Steven D'Aprano added the comment:
Can you give an example? Something simple, showing what you tried, what you
expected, and what happened instead.
This may help: http://sscce.org/
Your bug.py file doesn't ever use the result of calling list(), so how do you
know it changes the value
Steven D'Aprano added the comment:
I agree with Raymond's comments, except that because I'm sometimes a bit
of a pedant, I have to make one minor correction: max and min can be
descriptive statistics.
The sample minimum is the 1st order statistic, and the sample maximum is
the N-th order
Steven D'Aprano added the comment:
TL;DR: I'm not likely to accept this feature request without at least one of
(1) a practical use-case, (2) prior art in other statistics software, or (3) a
strong mathematical justification for why this is meaningful and useful.
I'm not categorically
Steven D'Aprano added the comment:
Looking at your first example, you calculate:
>>> 63945173192649609/13
4918859476357662.0
which is correct when using floats (64-bit C doubles). 64 bits are not enough
to be any more precise, and you would get the same result in C or
Steven D'Aprano added the comment:
Please don't post unnecessary screen shots of text. They are impossible for us
to copy your code, we have to re-type it from scratch, and retyping 17-digit
numbers is prone to typos. Screenshots make it difficult or impossible for the
blind and visually
Steven D'Aprano added the comment:
I am unable to reproduce this.
Can you double check that this occurs in the plain Python interpreter or IDLE,
and provide a minimum reproducible example? (No third-party IDEs or
interpreters, such as Jupyter.)
These guidelines may help:
https
Steven D'Aprano added the comment:
You've spent a lot of time demonstrating behaviour, but have not given us any
reason why you think the results given are wrong.
As far as I can tell, every single example you show is correct. You have even
quoted one of the relevant sections from the docs
Steven D'Aprano added the comment:
What you mean by "center_char" is not clear to me.
How is "bc" a character? It looks like two characters to me.
How is "1" the center char of "12345"? It looks like the leftmost character to
me.
Once you have expl
Steven D'Aprano added the comment:
I don't know, why *can't* you execute that code? It works fine for me. Although
I'm not using the exact same version of 3.8 that you are using.
Could you copy and paste (not a screen shot or photo!) the text of your
interactive session, including the error
Steven D'Aprano added the comment:
I tried sending this message earlier, but it seems to have disappeared
into the void, so I'm trying again. Apologies if it turns up twice.
* * *
> There are almost 500 occurrences of "is true".
We can worry about them if and when somebod
Steven D'Aprano added the comment:
You can read more here:
https://docs.python.org/3/tutorial/floatingpoint.html
https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate
--
___
Python tracker
<ht
Steven D'Aprano added the comment:
Hi Riccardo,
In the future, would you mind not posting screenshots of code or errors?
Rather, copy and paste the text. That makes it easier for others to replicate
the error, and also allows visually impaired and blind people using screen
leaders
Steven D'Aprano added the comment:
This is expected behaviour. You read from the position of the file pointer, not
the beginning of the file, so after writing to to the file, you have to use the
seek() method to return to the beginning if you want to read what you just
wrote.
https
Steven D'Aprano added the comment:
Although it often gets called "integer division", that's not actually what //
does, it is actually *floor* division, as documented here:
https://docs.python.org/3/library/stdtypes.html#numeric-types-int-float-complex
So the behaviour as given
Steven D'Aprano added the comment:
Hi Sebastian,
It will help if you do some minimal debugging before reporting what you think
is a bug. Also, you should report what version you are upgrading from, not just
the version you have upgraded to.
It may help you to provide better bug reports
Steven D'Aprano added the comment:
> My confusion stems from the fact that I expected the unpacking of a
> set to return the same output as that obtained from the unpacking of a
> list.
Why did you expect that?
Sets aren't lists. Lists are ordered, so they hold their items in a
Steven D'Aprano added the comment:
I'm sorry, I don't understand what part of the documentation you think is
violated here. The docs say that sets are unordered, but of course when
printing the elements have to be given in *some* order.
The given output seems unordered to me: -1 is smaller
Steven D'Aprano added the comment:
Please try your script in the vanilla Python interpreter. If it behaves
correctly, you should report this issue to Spyder and/or IPython.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.
Steven D'Aprano added the comment:
I'm pretty sure you should be reporting this to Anaconda. Its a crash involving
a third-party distribution of Python and third-party applications like numba
and cython.
--
nosy: +steven.daprano
___
Python
Steven D'Aprano added the comment:
I can see that making generators unhashable would have found your bug earlier,
but it is otherwise unjustified: generators are just objects that are compared
by identity. It would break other people's code, which is a very invasive
change to make just so
Steven D'Aprano added the comment:
Anthony, can you please explain what you mean when you describe generators as
"mutable"? I don't understand what you mean.
To *me*, the value of a generator, in so far as comparisons goes, is its
identity, not its invisible internal state. Yo
Steven D'Aprano added the comment:
Marco: there's no need for these to be "slowly" introduced. If the features are
worth having in the default REPL, they're worth having as soon as possible,
without us artificially slowing the process down. It will be hard enough to get
somebo
Steven D'Aprano added the comment:
Terry, I think you were extremely over-eager, almost aggressively so, to close
this feature request, especially since your reasons given are rather bogus:
IPython isn't based on a GUI, it works in a text mode console too, including on
Windows.
https
Steven D'Aprano added the comment:
This seems to be the difference between Universal Newlines or not. In Python 2,
you have to set it explicitly with a U in the open mode:
$ python2.7 -c 'import sys; print("Linecount=", sum(1 for x in
open(sys.argv[1], "Ur")))
Steven D'Aprano added the comment:
I have tried sending this message by email twice, and both times it seems to
have disappeared. So I'm commenting via the web, and my apologies in advance if
the message shows up later.
*
> There are almost 500 occurrences of "is true".
Steven D'Aprano added the comment:
Since error messages aren't part of the API and backwards-compatibility doesn't
apply to them, this could still go into 3.8.
--
stage: resolved ->
versions: +Python 3.8 -Python 3.9
___
Python tracker
<
Steven D'Aprano added the comment:
I'm reopening this as an enhancement, because I think Mikeli is onto something
here. I'd like to propose making the messages:
"False is not a truthy value."
"True is not a falsey value."
to make it explicit
Steven D'Aprano added the comment:
Possibly even easier than using Decimal:
py> '%.17f' % 0.95
'0.94996'
BTW, this is a FAQ:
https://docs.python.org/3/faq/design.html#why-are-floating-point-calculations-so-inaccurate
--
nosy: +steven.dapr
Steven D'Aprano added the comment:
> Also, if some new Python coders saw `[]` or `{}` being used as default
> values in the standard library, they might think “I’ll do it too since
> the standard library does it”.
Great! Having Python coders learn good progamming skills from the
Steven D'Aprano added the comment:
I agree with Serhiy that using mutable defaults is not automatically a bad
idea. This is unnecessary code churn that fixes no bugs and adds no new
functionality and doesn't make the code "better".
The PR removes one harmless use of a mutab
Steven D'Aprano added the comment:
Have you read the rest of the thread? There is a compelling reason to
support harmonic mean including zero (resistors in parallel) but not yet
any compelling reason to support negative values.
If you have a good use-case for harmonic mean of negative
Steven D'Aprano added the comment:
Thank you for your comments, but accepting non-floats like Decimal and
Fraction (and int, of course!) is a hard requirement for the statistics
module. fmean will naturally convert any data to float for speed, but
the other means will attempt to keep
Steven D'Aprano added the comment:
Please explain the bug here on the bug tracker, people shouldn't have to drill
down into the PR to find out what it means.
Before fixing the bug, you should find out whether or not it actually is a bug.
In my testing, the comment is approximately correct
Steven D'Aprano added the comment:
Its also documented here:
https://docs.python.org/3/reference/lexical_analysis.html#identifiers
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bug
Steven D'Aprano added the comment:
This is an intentional feature: identifiers are normalised using NFKC
normalization.
py> from dis import dis
py> dis(compile('ϕ=1', '', 'single'))
1 0 LOAD_CONST 0 (1)
3 STORE_NAME
Steven D'Aprano added the comment:
Also, next time I suggest that you try running the code at least once before
submitting it, as your code contains a syntax error that prevents it from
running.
--
nosy: +steven.daprano
___
Python tracker
<ht
Change by Steven D'Aprano :
--
components: +Interpreter Core
type: enhancement -> behavior
___
Python tracker
<https://bugs.python.org/issue38556>
___
___
Py
Steven D'Aprano added the comment:
We're not mind-readers, how do you expect us to know what you tried if you
don't tell us?
The walrus operator works for me:
>>> [spam for c in "hello world" if (spam:=c.upper()) in 'AEIOU']
['E', 'O', 'O']
>>>
Steven D'Aprano added the comment:
The documentation doesn't mention ``__set_name__``, but it does say that
cached_property is useful for properties which are "effectively immutable".
The ``__set_name__`` error message is pretty cryptic, that seems to have
something to do wit
Change by Steven D'Aprano :
--
title: Provide Class' end line in readmodule module -> Provide Class' end line
in pyclbr module
___
Python tracker
<https://bugs.python.org/issu
Steven D'Aprano added the comment:
Why would they give the same result when the code is different?
#1 assign c, d, e and everything left over goes into b
*b, c, d, e, = [1, 2, 3, 4]
#2 assign c, d and everything left over goes into b
*b, c, d, = [1, 2, 3, 4]
#3 assign c
Steven D'Aprano added the comment:
What is this a screen shot of?
What error occurs? The picture doesn't show any errors that I can see.
Please COPY and PASTE the code you are running, as text, and the FULL EXCEPTION
(the traceback and error message), if there is one. We cannot guess what
Steven D'Aprano added the comment:
I believe that the interpreter only requires that each block is consistent, not
that all blocks in a module are consistent.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue38
Steven D'Aprano added the comment:
I can't speak for other countries, but in Australia, secondary school
mathematics teaches correlation coefficient and linear regression from
Year 11 onwards (typically ages 16 or 17). Covariance is not itself
taught, and as far as I can tell neither the TI
Steven D'Aprano added the comment:
Define "malfunction". Are we supposed to know what your code is meant to do, as
well as what it actually does?
Please don't use the bug tracker as a help desk for your own scripts. There are
many forums where you can ask for help, such as the mai
Change by Steven D'Aprano :
--
nosy: +pablogsal
___
Python tracker
<https://bugs.python.org/issue38458>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven D'Aprano added the comment:
This is not a bug, it is part of the design of the language. Assignment in
Python does not make a copy of lists, or any other object. In your sample code,
p and l are two names for the same list, like "Devor Blake Daniels" and
"dev40573
Steven D'Aprano added the comment:
Oh, I forgot to mention that this is discussed in one of the FAQs:
https://docs.python.org/3/faq/programming.html#why-are-default-values-shared-between-objects
--
___
Python tracker
<https://bugs.python.
Steven D'Aprano added the comment:
This is not a bug, this is the design of function default arguments.
Default arguments in Python use *early binding*, which means they are
calculated once, when the function is declared, rather than *late binding*,
which means they are calculated each time
Steven D'Aprano added the comment:
All versions below 3.9 are in feature freeze, so they cannot get new features.
This requested feature is already supported by subclassing ``dict`` and giving
it a ``__missing__`` method. See issue #38315
--
nosy: +steven.daprano
resolution
Steven D'Aprano added the comment:
Importing the second and subsequent times reloads the module from the system
cache. Instead, you can:
- run ``del sys.modules['hexdump']`` and then ``import hexdump``;
- call ``importlib.reload(hexdump)``; or
- restart the REPL.
Remember that reloading
Steven D'Aprano added the comment:
Thanks Warren, the resistance example is excellent, would you like to write up
a PR to add it to the docs?
In the original design, I prohibited negative numbers because that seems to be
what everyone says you should do, but as far as I can tell
Steven D'Aprano added the comment:
I agree with Ned closing this issue, but just glancing at the logs, it looks to
me like buildozer has shadowed your Python's ctypes with a broken ctypes in
/home/yzw/Desktop/Test/.buildozer/android/platform/build/build/other_builds/hostpython3/desktop
Steven D'Aprano added the comment:
False alarm, see Stephen Tucker's message here
https://bugs.python.org/issue38365#msg353854
File name has a trailing space which is why it wasn't found.
--
nosy: +steven.daprano
resolution: -> works for me
stage: -> resolved
status
Steven D'Aprano added the comment:
Please don't create a *second* bug report to say that your previous bug report
was erroneous. Just go and close the first one.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -&g
Steven D'Aprano added the comment:
This is nothing to do with platform.system. You can see the same behaviour with
any string comparison, or ints.
The `is` operator is not a cute way of spelling `==`, it tests for object
identity, not equality. It tests whether the two arguments
501 - 600 of 1436 matches
Mail list logo
