Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue47259>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven D'Aprano added the comment:
It would be nice if the class creation process was documented a bit
better. Here is my experiment to see what is going on:
```
# the global `__name__` is normally the module's name.
__name__ = "something"
class Meta_default_prepare(type):
d
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue47234>
___
___
Python-bugs-list mailing list
Unsubscribe:
Steven D'Aprano added the comment:
Isn't this just a quality of implementation issue?
math.isfinite should return True for all ints, since all ints are finite.
(There are no int infinities or NANs). There is no need to coerce them to float
to know that they are finite.
Likewise
Steven D'Aprano added the comment:
I came here from #47221.
If I am reading this correctly, it concerns me that stack operations (which
should be fast) are apparently slow?
If we can't reduce the number of stack operations, can we speed them up?
--
nosy: +steven.daprano
status
Steven D'Aprano added the comment:
Perhaps what you want is inspect.isroutine ?
https://docs.python.org/3/library/inspect.html#inspect.isroutine
I agree with Dennis that the isfunction test is for **Python** (def or lambda)
functions, not builtins. The docstring for the inspect.is* methods
Steven D'Aprano added the comment:
I'm not sure what the implementation uses to enforce this, but decimal
contexts already seem to reject arbitrary attributes. So a naive
implementation that just setattr()'s the keyword arguments will
automatically fail:
>>> from decimal import g
Steven D'Aprano added the comment:
See this thread on Discuss:
https://discuss.python.org/t/logging-timedrotatingfilehandler-never-rotates-in-certain-cases/14747/1
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue40
Steven D'Aprano added the comment:
Rather than an option for this, it would be cleaner to deprecate the
current output in 3.11, and fix it in 3.12 or 3.13.
Otherwise we have to maintain the old (bad?) output and the new output
both forever
Steven D'Aprano added the comment:
> the programmer may use the variable __name__ for some other purposes
Dunder names like `__name__` are reserved for the use of the interpreter. If
the programmer uses them for "other purposes", the programmer is responsible
for any failures.
New submission from Steven D'Aprano :
Whenever I use decimal and need to change the context temporarily, without fail
I try to write
with decimal.localcontext(prec=10):
...
or similar. Then I get surprised that it fails, and re-write it as
with decimal.localcontext() as ctx
Steven D'Aprano added the comment:
I have no problem with pinging Python-Dev, or any other forum, asking
for interested parties. I just don't think we should be intentionally
spliting the discussion more than it's going to get split organically.
(If this is interesting to people
Steven D'Aprano added the comment:
I don't think this change of behaviour should be accepted without discussion,
and I'm not sure why you think Python-Dev is the right place, rather than here.
Messing around with unittest and docstrings has already caused issues in the
past:
https
New submission from Steven D'Aprano :
OverflowError sometimes (but not always) includes some sort of numeric code:
>>> 1e+300 ** 2
Traceback (most recent call last):
File "", line 1, in
OverflowError: (34, 'Numerical result out of range')
but the meaning of the 34 is not
Steven D'Aprano added the comment:
> We cannot guarantee that NAN never equal to anything, because we can
> create an object equal to it. For example mock.ANY
Sure. I don't expect that mock.ANY or other weird objects should obey
the IEEE-754 rules. But we're talking numeric comparison
Steven D'Aprano added the comment:
Here is another example of a newbie caught by this:
https://discuss.python.org/t/syntax-error-in-python-3-10-when-running-on-terminal/14462
--
___
Python tracker
<https://bugs.python.org/issue45
New submission from Steven D'Aprano :
The IEEE-754 requirement that NANs are never equal to anything, even to
themselves, is a common stumbling block for those new to the consequences of
IEEE-754. See for example #47020.
The documentation for math.nan would be a good place to add a note like
Steven D'Aprano added the comment:
What makes you think you are supposed to be able to import _simple_enum? It is
a name with a leading underscore, so even if it exists, it is private and you
shouldn't touch it.
Unless _simple_enum is documented as something you can use, this is not a bug
Change by Steven D'Aprano :
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46967>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Steven D'Aprano :
I'm reluctant to call this a bug, as small int interning/caching is an
implementation detail and there are no hard guarantees made.
But on the other hand, it seems that the intention is that small ints such as
0, 1 and 2 should be cached. Here are some
Steven D'Aprano added the comment:
The behaviour is technically correct, but confusing and unfortunate, and I
don't think we can fix it.
Unicode does not define names for the ASCII control characters. But it does
define aliases for them, based on the C0 control char standard
Steven D'Aprano added the comment:
> Personally I'd prefer a new exception `StackOverflow` to `MemoryError`
+1 on a new exception (presumably a subclass of MemoryError).
How about using OverflowedStack instead?
The situation is not quite as bad as you suggest. Googling for "stack
Steven D'Aprano added the comment:
Oops, replying by email reopens the ticket. Back to pending you go!
--
status: open -> pending
___
Python tracker
<https://bugs.python.org/issu
Steven D'Aprano added the comment:
> The "spawn" method requires pickling the data and callable passed to
> the child proces, and that's not supported for lambda's.
Ah, today I learned something. Kyle, looks like you were right about it
being due to the lambdas.
--
Steven D'Aprano added the comment:
Note also that this is mentioned here:
https://docs.python.org/3/library/stdtypes.html#boolean-values
"[True and False] are used to represent truth values (although other values can
also be considered false or true)."
although it is perhaps no
Steven D'Aprano added the comment:
See #46883
--
___
Python tracker
<https://bugs.python.org/issue46882>
___
___
Python-bugs-list mailing list
Unsubscribe:
New submission from Steven D'Aprano :
There is a long-standing tradition, going back to Python 1.x days before we had
dedicated True and False values, to use the lowercase "true" and "false" to
mean *any value that duck-types as True* and *any value that duck-types as
Steven D'Aprano added the comment:
> Both arguments `aliased` and `terse` should be boolean instead of integer.
Why should they be strictly True/False booleans? I disagree strongly that they
should be. Any object that duck-types as a true or false value is sufficient.
Trea
Steven D'Aprano added the comment:
Works for me in Python 3.10.0 on Linux.
After running your code, I get shared_dict is a DictProxy:
>>> shared_dict
>>> list(shared_dict.items())
[('number', 0), ('text', 'Hello World')]
and shared_lock an AcquirerProxy object.
P
Change by Steven D'Aprano :
Removed file: https://bugs.python.org/file50635/6.jpeg
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bugs-list mailin
Change by Steven D'Aprano :
--
nosy: -xiaox55066
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bugs-list mailing list
Unsubscribe:
Change by Steven D'Aprano :
--
Removed message: https://bugs.python.org/msg413568
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bug
Change by Steven D'Aprano :
--
Removed message: https://bugs.python.org/msg413567
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bug
Change by Steven D'Aprano :
--
Removed message: https://bugs.python.org/msg413566
___
Python tracker
<https://bugs.python.org/issue46803>
___
___
Python-bug
Steven D'Aprano added the comment:
Replicated on Linux, Python 3.10.
It looks like mousewheel scrolling jumps by the wrong amount as it pages down
(or up), and consequently some lines never appear in the view area.
I ran a slightly modified version of the code that had 16 entries instead
Steven D'Aprano added the comment:
Maybe you expected to do this:
class C:
def __init__(self):
self._value = 999
@property
def bar(self):
return self._value
obj = C()
obj.bar # returns 999
--
___
Python tracker
Steven D'Aprano added the comment:
This is not a bug, Python is working correctly here. The interpreter is doing
exactly what you told it to do, and then raising a RecursionError before you
can crash the system.
You have a property instance.bar which returns instance.bar, which returns
Steven D'Aprano added the comment:
True, but you did say it would be with the io module in your original
suggestion.
--
___
Python tracker
<https://bugs.python.org/issue46
Steven D'Aprano added the comment:
I'm sorry, I don't see why you think this will improve code readability. I also
expect it will be harder to teach than the current code.
open("file.img", "wb") just needs the user to learn about reading and writing
files, and the diffe
Steven D'Aprano added the comment:
If we can't change the default behaviour of copying functions, can we
add a specialised copy_function() function, for when we really need to
make a genuine copy?
--
___
Python tracker
<https://bugs.python.
Steven D'Aprano added the comment:
Decimal is a good question.
Why does floor division not do floor division on Decimal? The
documentation says
The integer division operator // behaves analogously, returning the
integer part of the true quotient (truncating towards zero) rather
Steven D'Aprano added the comment:
I don't understand why math.ceildiv couldn't ducktype. There's no rule that
says it *must* convert arguments to float first, that's just a convention, and
we've broken it before.
>>> math.prod([Fraction(1, 3), 7])
Fraction(7, 3)
Couldn't math.cei
Steven D'Aprano added the comment:
You say: "The documentation says ..." but don't tell us which documentation.
This documentation:
https://docs.python.org/3/reference/simple_stmts.html#augmented-assignment-statements
tells us that augmented assignment is assignment:
&qu
Steven D'Aprano added the comment:
As documented, this is not a bug.
"if two multiples are equally close, rounding is done toward the even choice"
https://docs.python.org/3/library/functions.html#round
This is also called "Banker's Rounding" or "Round half to eve
Steven D'Aprano added the comment:
That's not a bug.
https://docs.python.org/3/library/pydoc.html
"If there is no docstring, pydoc tries to obtain a description from the block
of comment lines just above the definition of the class, function or method in
the source file, or at th
Steven D'Aprano added the comment:
That's not always the case though.
>>> def f():
... return frozenset({1, 2, 3})
...
>>> a = f.__code__.co_consts[1]
>>> a
frozenset({1, 2, 3})
>>> b = f()
>>> assert a == b
>>> a is b
Fa
Steven D'Aprano added the comment:
Proposed on Python-Ideas.
https://mail.python.org/archives/list/python-id...@python.org/message/GRMNMWUQXG67PXXNZ4W7W27AQTCB6UQQ/
--
___
Python tracker
<https://bugs.python.org/issue46
Steven D'Aprano added the comment:
The difficulty is that frozenset may have been shadowed, or builtins
monkey-patched, so we cannot know what frozenset({1, 2, 3}) will return until
runtime.
Should we re-consider a frozenset display literal?
f{1, 2, 3}
works for me.
--
nosy
Steven D'Aprano added the comment:
Please don't reopen this issue.
If you really want to take it to the Python-Ideas mailing list, you can:
https://mail.python.org/mailman3/lists/python-ideas.python.org/
or to Discuss:
https://discuss.python.org/c/ideas/6
--
status: open -> clo
Steven D'Aprano added the comment:
Dennis beat me to it in saying that tuples cannot be replaced by lists.
But I also wanted to say that it is *not true* that removing bracket symbols
would increase readability. Natural language allows parenthetical phrases --
which can be bracketed using
Steven D'Aprano added the comment:
Did you look in setup.py in detect_modules() for the module's name to see what
was missing?
How do you know the curses dependencies have been installed? What dependencies
did you install?
--
nosy: +steven.daprano
Steven D'Aprano added the comment:
Hi mareklachbc,
What makes you think that this is a bug?
Since at least version 3.7, you will have seen this warning:
>>> import collections
>>> collections.Mapping
__main__:1: DeprecationWarning: Using or impor
Steven D'Aprano added the comment:
It is better to raise each issue in its own ticket.
You seem to have three distinct issues here:
- The issue listed in the title, which I don't understand. A demonstration of
the issue would be helpful.
- The unrelated(?) issue of bad \N{} escapes, which
Steven D'Aprano added the comment:
Many docstrings are only 1 line without being "See base class." And many
docstrings are multiple lines while also referring the reader to see the parent
class for further details. So this DWIM heuristic to guess whether or not to
display a pa
Steven D'Aprano added the comment:
Your module token.py "shadowed" the stdlib token.py, and prevented it from
being seen until you changed the name.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
type
Steven D'Aprano added the comment:
Your functions test1 and test2 are irrelevant to the bug report. The driver
code using eval() to pick which function to call is unneeded. The business of
simulating a file is complexity for no purpose.
Those ignore, count, unique functions are also
Steven D'Aprano added the comment:
> it returns IndexError (instead of "u") if used in a list comprehension
Works as expected inside a list comprehension:
>>> var = "u2"
>>> [var.strip()[0] for i in range(2)]
['u', 'u']
>>> ["ok"
Steven D'Aprano added the comment:
Serhiy is correct. The table is correct, \n can be found further down the
table, the first entry is backslash newline, as it says.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -&g
Steven D'Aprano added the comment:
Sure, there will always be some users who will find certain things not
obvious. Sometimes I'm that user myself.
What did this user think print() returned? What precisely was their
question? Perhaps if I saw the conversation in context, I would be more
New submission from Steven D'Aprano :
Do the print docs need to mention something so obvious?
Functions and methods which operate by side-effect typically don't mention that
they return None, see for example the docs for various builtin methods:
https://docs.python.org/3/library
Steven D'Aprano added the comment:
I think the existence of sys.getandroidapilevel is evidence that Android is
somewhat supported, even if it is not supported to the same degree that Linux
and Windows are.
https://docs.python.org/3/library/sys.html#sys.getandroidapilevel
See also:
https
Steven D'Aprano added the comment:
Please try to provide a minimal reproducible example:
https://stackoverflow.com/help/minimal-reproducible-example
http://sscce.org/
At the very least, you need to provide three pieces of information:
1. What you tried.
2. What you expected to happen
Steven D'Aprano added the comment:
> I still can not figure out why the first two elements are inconsistent
from the rest of the dictionary, and why they appear in the first place.
Hi Tobias,
This is a bug tracker for reporting bugs in Python, not a help desk to ask for
explanati
Steven D'Aprano added the comment:
Aside: for what it is worth, the British style with a middle dot is also not
supported: float('1·234') also raises ValueError.
--
___
Python tracker
<https://bugs.python.org/issue46
Steven D'Aprano added the comment:
The behaviour is correct and not a bug. Commas are not supported when
converting strings to float.
The allowed format for floats as strings is described in the docs:
https://docs.python.org/3/library/functions.html#float
By the way, the negative sign
Steven D'Aprano added the comment:
float(x) performs rounding. Only if the value after rounding is out of range is
OverflowError raised.
M + 1, when correctly rounded to the nearest even float, gives
sys.float_info.max. Likewise for M+2, M+3 etc all the way to M+K where K equals
2**960
Steven D'Aprano added the comment:
Just use
if a == b == 1:
Comparisons can be chained arbitrarily.
https://docs.python.org/3/reference/expressions.html#comparisons
--
nosy: +steven.daprano
resolution: -> rejected
stage: -> resolved
status: open -&g
Steven D'Aprano added the comment:
On Thu, Dec 23, 2021 at 05:47:33AM +, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> > That's taken straight out of the documentation.
>
> Yes, but it's still a misleading comparison.
I asked how you would re-word the
Steven D'Aprano added the comment:
On Thu, Dec 23, 2021 at 12:15:29AM +, Eryk Sun wrote:
>
> Eryk Sun added the comment:
>
> > If exec gets two separate objects as globals and locals,
> > the code will be executed as if it were embedded in a
> > cl
Steven D'Aprano added the comment:
"Expected" is a strong word. It took me a lot of careful reading of the
documentation and experimentation to decide that, yes, I expect the
second case to fail when the first case succeeds.
Which reminds me of a common anecdote from mathemati
Steven D'Aprano added the comment:
> I now want to define a closure with exec. I might want to do something like:
> exec("def f(): return a", globals(), locals())
That doesn't create a closure.
> I would expect f() to look for a in the locals().
I'm sorry, but your
Steven D'Aprano added the comment:
Here is the key phrase in the docs:
"If exec gets two separate objects as globals and locals, the code will be
executed as if it were embedded in a class definition."
https://docs.python.org/3/library/functions.html#exec
And sure enough:
&
Steven D'Aprano added the comment:
The function you use in exec is not a closure. The function:
def f():
return a
does not capture the top-level variable "a", it does a normal name lookup for
a. You can check this yourself by looking at f.__closure__ which you will se
Steven D'Aprano added the comment:
> not complied with the PEP-8 formatting.
PEP 8 says:
"Some other good reasons to ignore a particular guideline:
3. Because the code in question predates the introduction of the guideline and
there is no other reason to be modifying that code.&qu
Steven D'Aprano added the comment:
Prompted by Guido's reopening of the ticket, I have given it some more thought,
and have softened my views. Jake if you're still around, perhaps there is more
to what you said than I initially thought, and I just needed fresh eyes to see
it. Sorry
Steven D'Aprano added the comment:
The plot thickens.
I was wrong to say that type() always and only looks at the "real" underlying
type of the instance. type() does look at __class__ as well. But only sometimes.
>>> class A:
... __class__
Steven D'Aprano added the comment:
On Fri, Dec 10, 2021 at 12:03:15AM +, Gabriele N Tornetta wrote:
> class Side(object):
> def __getattribute__(self, name):
> ValueError(name)
You forgot to actually *raise* the exception. That will just instantiate
the ValueError
Steven D'Aprano added the comment:
I agree that the rules regarding type and `__class__` and isinstance are
not clear or well documented.
We have:
https://docs.python.org/3/library/stdtypes.html#instance.__class__
https://docs.python.org/3/library/functions.html#isinstance
but neither
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
the class.&qu
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 :-)
isinstance has
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, musical, or
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://bugs.python.o
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
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/issu
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 want
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 :-)
--
nosy
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/issue45
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 tracker
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 "
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, Python
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 behavior of a re
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 to zero. (What
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 first
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 (most recent c
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-...@python.org
Change by Steven D'Aprano :
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.or
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
resolution: -> not a bug
stage:
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't
feel entirely
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:
https
Change by Steven D'Aprano :
--
stage: -> resolved
___
Python tracker
<https://bugs.python.org/issue45705>
___
___
Python-bugs-list mailing list
Unsubscrib
1 - 100 of 1436 matches
Mail list logo
