Steven D'Aprano added the comment:
If you are working in the interactive interpreter, you may be running into a
conflict with the "magic" variable `_` which the interactive interpreter
creates to hold the result of the last evaluated statement.
So when you evaluate `x`, and t
Steven D'Aprano added the comment:
It is a bit tricky to find the documentation for the magic single underscore,
but it is here:
https://docs.python.org/3/reference/lexical_analysis.html#reserved-classes-of-identifiers
--
___
Python tr
Steven D'Aprano added the comment:
Serhiy is correct. Please see the documentation.
https://docs.python.org/3/library/stdtypes.html#str.strip
If you are using version 3.9 or better, you can use removeprefix instead:
https://docs.python.org/3/library/stdtypes.html#str.removep
New submission from Steven D'Aprano :
Why do you say that the FAQ is misleading?
If it is misleading, it should be replaced with a more correct answer, not just
deleted.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.py
Steven D'Aprano added the comment:
Jeff makes an excellent point about the docs failing to distinguish
between language guarantees, implementation guarantees, and things which
are merely true sometimes.
On the other hand, we only need document what is true *now*, not what
may be tr
Steven D'Aprano added the comment:
This is not a bug, "pass" is not an operator, it is not an expression, it is a
statement and is only allowed in places where statements are allowed.
The if expression requires all three operands to be expressions.
Even if "pass"
Steven D'Aprano added the comment:
If you want pass to become an expression, what should these do?
x = pass
print(pass)
mydict[pass] = 1
type(pass)
There is nothing special about the ternary if operator. It is just an
operator like plus, minus and more. The
Steven D'Aprano added the comment:
See also the FAQs:
https://docs.python.org/3/faq/programming.html#why-do-lambdas-defined-in-a-loop-with-different-values-all-return-the-same-result
--
nosy: +steven.daprano
___
Python tracker
&
Steven D'Aprano added the comment:
> Why is it still not automatically inside python 3.11.0a1?
Probably because this is the .0a1 version, and making it mandatory just hasn't
been done yet. The developers are only human and can't do everything instantly.
--
nos
Steven D'Aprano added the comment:
Duplicate: #38605
--
___
Python tracker
<https://bugs.python.org/issue45499>
___
___
Python-bugs-list mailing list
Change by Steven D'Aprano :
--
resolution: -> duplicate
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
Steven D'Aprano added the comment:
Now that we're in 3.11, people are starting to notice that stringy annotations
are not the default (see #45499 for example).
What can we do to get PEP 649 moving forward?
--
nosy: +steven.daprano
Steven D'Aprano added the comment:
This may be an example of the problem:
https://discuss.python.org/t/why-does-venv-not-work-on-my-windows-system/11167
The poster there hasn't responded yet, so it isn't clear what is the actual
issue is. But it looks suspiciously like a fai
Steven D'Aprano added the comment:
You need to give us some steps to reproduce this error, or we cannot even begin
to try to fix it.
What are the minimum steps needed to reproduce the error?
--
nosy: +steven.daprano
___
Python tracker
&
Steven D'Aprano added the comment:
Please read:
https://stackoverflow.com/help/minimal-reproducible-example
http://www.sscce.org/
--
___
Python tracker
<https://bugs.python.org/is
Steven D'Aprano added the comment:
See issue #45642
--
___
Python tracker
<https://bugs.python.org/issue45641>
___
___
Python-bugs-list mailing list
Steven D'Aprano added the comment:
See issue #45641
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue45642>
___
___
Python-bugs-l
Steven D'Aprano added the comment:
What is wrong with addressing the reader as "you"?
Avoiding an affirmative tone goes directly against the style-guide you linked
to, which recommends an affirmative (positive) tone:
"The documentation focuses on affirmatively stating wh
Change by Steven D'Aprano :
--
stage: -> resolved
___
Python tracker
<https://bugs.python.org/issue45705>
___
___
Python-bugs-list mailing list
Unsub
New submission from Steven D'Aprano :
A frequent newbie mistake is to call shell commands from inside the interactive
interpreter. Most common is to call Python itself.
Here is an example where a Python instructor was allegedly unable to diagnose
the issue for their students:
Steven D'Aprano added the comment:
Hi Raymond,
I'm conflicted by this. Regression through the origin is clearly a thing which
is often desired. In that sense, I'm happy to see it added, and thank you.
But on the other hand, this may open a can of worms that I personally don&#
Steven D'Aprano added the comment:
The behaviour is correct. You have tripped over the ASCII representation of
bytes. In ASCII, 119 (or in hex, 0x77) is displayed as 'w'.
>>> b'\x77\x00\x00\x00'
b'w\x00\x00\x00'
--
nosy: +steven.daprano
r
Change by Steven D'Aprano :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.pyth
New submission from Steven D'Aprano :
Currently invisible control characters aside from whitespace (tabs, newlines,
formfeeds, carriage returns) are prohibited outside of comments and string
literals. As discussed in this thread:
https://mail.python.org/archives/list/python-...@pytho
New submission from Steven D'Aprano :
Invisible control characters (aside from white space) are not permitted in
source code, but the syntax error we get is confusing and lacks information:
>>> s = 'print\x17("Hello")'
>>> eval(s)
Traceback (mo
Steven D'Aprano added the comment:
At a quick glance, I am 95% sure the problem lies in these two snippets of your
code, not unittest:
class My_Time:
months = [31, 28, 31, 30, 31, 30, 31, 31, 30, 31, 30, 31]
if is_leapyr(year):
my_time.months[1] = 29
The
Steven D'Aprano added the comment:
Hi Raymond,
I'm satisfied that this should be approved. The code looks good to me
and in my tests it matches the results from other software.
I don't think there is any need to verify that plain OLS regression
produces an intercept close
Steven D'Aprano added the comment:
Hi Joran,
I'm not sure why you think that /s should agree between ASCII and Unicode. That
seems like an unjustified assumption to me.
You say: "The expectation would be that the re.A (or re.ASCII) flag should not
impact the matching behavi
Steven D'Aprano added the comment:
In any case, any change to this would have to be limited to Python 3.11. It is
not clearly a bug, so this would be an enhancement.
--
type: behavior -> enhancement
versions: -Python 3.10, Python 3.8, Py
Steven D'Aprano added the comment:
Hi noobie1000,
This is not a general forum for asking questions about Python's design or
language, this is for reporting bugs.
There are many forums where you can ask "Why" questions and ask for the
community to "shed som
Steven D'Aprano added the comment:
Raymond, Mark, Tim,
I have been reading this whole thread. Thank you all. I am in awe and a little
bit intimidated by how much I still have to learn about floating point
arithmetic.
--
___
Python tr
Steven D'Aprano added the comment:
https://docs.python.org/3/faq/design.html#why-am-i-getting-strange-results-with-simple-arithmetic-operations
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/is
Steven D'Aprano added the comment:
This is not a performance issue. Why did you flag it as performance?
Python 2.2 and 2.1 are so out of date that I'm just going to close this and not
even ask why you are bothering to write and publish code for Python 2.2 :-)
-
Steven D'Aprano added the comment:
The code makes perfect sense. If you want to find the maximum key in a dict,
you write:
max(collective_signals)
If you want to find the maximum key according to some key function, you write:
max(collective_signals, key=function)
If you wa
Change by Steven D'Aprano :
--
title: Getting key of max value of dict really dose not sense -> Add new
function or method to return the dict key with the maximum value
___
Python tracker
<https://bugs.python.org
Steven D'Aprano added the comment:
It was decided long ago that % formatting would not be enhanced with new
features. I think that it is supposed to match the standard C formatting codes,
and nothing else.
So this is unlikely to be approved for % formatting.
It *might* be approved fo
Steven D'Aprano added the comment:
Sorry John, I don't understand your comment about "treating %-formatting
specifically". Isn't the point here not to change %-formatting at all?
--
___
Python tracker
<https:
Steven D'Aprano added the comment:
What difference do you believe there is between skits and sketches?
Definition 1 of skit: "A short comic performance."
https://en.wiktionary.org/wiki/skit#English
Definition 4 of sketch: "A brief, light, or unfinished dramatic, musica
Steven D'Aprano added the comment:
I'd be inclined to see this as a bug in your code, if you are causing
side-effects from `__getattribute__`. If you don't want attribute access to
cause side-effects, then don't put code in `__getattribute__` that causes
side-effects :-
Steven D'Aprano added the comment:
If you don't want to customise attribute access, don't overload
`__getattribute__`. The documentation for `__getattribute__` is clear
about what it does:
"Called unconditionally to implement attribute accesses for instances of
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
Windo
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
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
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 ma
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
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.py
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
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 i
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 repor
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
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.
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
le
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
&
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 so
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,
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
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 fro
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:
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 an
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
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 no
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
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 th
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/cons
Change by Steven D'Aprano :
--
title: Misleading documentation -> Misleading documentation for NotImplemented
___
Python tracker
<https://bugs.python.org
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.pyth
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.
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):
d
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
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 kn
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
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 t
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 g
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 w
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 j
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 t
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 the
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 req
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
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
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
Steven D'Aprano added the comment:
Oops, I meant Lib/test/string_tests.py not "test_string.py".
--
___
Python tracker
<https://bugs.pyt
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/is
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue29282>
___
___
Python-bugs-list mailing list
Unsubscr
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 ar
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.
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 consta
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 chara
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 nu
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, t
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 d
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` automati
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* i
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:
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&#x
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:
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 ob
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 total
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(12
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
301 - 400 of 1443 matches
Mail list logo
