[issue47259] string sorting often incorrect
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47259> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] The variable __module__ in the class body getting an undesirable value from __prepare__ of the metaclass
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):
def __new__(meta, name, bases, ns):
print("ns for", name, "\n ", ns)
return super().__new__(meta, name, bases, ns)
class Meta_custom_prepare(Meta_default_prepare):
def __prepare__(meta, *args):
return {'__name__': 'another_name'}
class Spam(metaclass=Meta_default_prepare):
pass
class Eggs(metaclass=Meta_custom_prepare):
pass
print("Spam module and name:", Spam.__module__, Spam.__name__)
print("Eggs module and name:", Eggs.__module__, Eggs.__name__)
```
And the output in Python 3.10 is:
```
ns for Spam
{'__module__': 'something', '__qualname__': 'Spam'}
ns for Eggs
{'__name__': 'another_name', '__module__': 'another_name', '__qualname__':
'Eggs'}
Spam module and name: something Spam
Eggs module and name: another_name Eggs
```
My take on this is that if the key __name__ is not present, the value of
the class __module__ is taken from the global variable. So far so good.
But if '__name__' is a key in the mapping returned by __prepare__, it
gets left in the class dict, and gets used to set the class __module__
as well.
But in neither case does it get used to set the class __name__.
I cannot decide whether or not this makes sense to me.
--
___
Python tracker
<https://bugs.python.org/issue47136>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47234] PEP-484 "numeric tower" approach makes it hard/impossible to specify contracts in documentation
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47121] math.isfinite() can raise exception when called on a number
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 for Fractions. If they overflow, that could be caught and True returned. Decimal infinities convert to float infinities, so the only way you can get an overflow error is if the Decimal is finite but too big to convert. So again, isfinite could (should?) catch the overflow error and return True. Any numeric type that has an infinity which does not coerce to float infinity, but overflows instead, is buggy, and its not isfinite's responsibility to protect against that. So here is my suggestion: isfinite() should return True for all ints, without needing to coerce them to float. For other numeric types, it should try to coerce them to float, and catch OverflowError and raise True. This should be documented, so that other numeric types know what contract they are required to follow (infinity coerces to float infinity). I'm going to change this to an enhancement for 3.11 (or 3.12). -- nosy: +steven.daprano type: -> enhancement versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue47121> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45542] Using multiple comparison operators can cause performance issues
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: pending -> open ___ Python tracker <https://bugs.python.org/issue45542> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47214] builtin_function_or_method is also either a function or a method
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 make promises about what attributes an object will have: def isbuiltin(object): """Return true if the object is a built-in function or method. Built-in functions and methods provide these attributes: __doc__ documentation string __name__original name of this function or method __self__instance to which a method is bound, or None""" def isfunction(object): """Return true if the object is a user-defined function. Function objects provide these attributes: __doc__ documentation string __name__name with which this function was defined __code__code object containing compiled function bytecode __defaults__tuple of any default values for arguments __globals__ global namespace in which this function was defined __annotations__ dict of parameter annotations __kwdefaults__ dict of keyword only parameters with defaults""" def (and lambda) functions have a different API from builtin_function_or_method objects. They should be kept separate. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47214> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
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 getcontext >>> ctx = getcontext() >>> setattr(ctx, 'precision', 10) Traceback (most recent call last): File "", line 1, in AttributeError: 'decimal.Context' object has no attribute 'precision' But you are absolutely correct that however we enforce it, we should avoid allowing typos to silently fail. -- ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40469] TimedRotatingFileHandler rotating on use not time
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/issue40469> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
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. -- ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47136] Wrong value assigned automatically to the variable __module__ in the class body.
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. You wouldn't write: class MyList(list): __len__ = "Hello world!" and then be surprised that MyList is broken. You shouldn't be surprised if setting `__name__` to an invalid value breaks things either. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47136> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47135] Allow decimal.localcontext to accept keyword arguments to set context attributes
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: ctx.prec = 10 ... Let's make the first version work. localcontext should accept keyword arguments corresponding to the same arguments accepted by Context, and set them on the context given. A proof-of-concept wrapper function: def localcontext(ctx=None, **kwargs): if ctx is None: ctx = decimal.getcontext().copy() for key, value in kwargs.items(): setattr(ctx, key, value) return decimal.localcontext(ctx) I think this would be a valuable, and useful, improvement to the decimal API. -- components: Library (Lib) messages: 416114 nosy: steven.daprano priority: normal severity: normal status: open title: Allow decimal.localcontext to accept keyword arguments to set context attributes versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue47135> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
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, they will discuss it on other forums no matter what we say or do.) Aside from the conservative position "If it ain't broke, don't break it", also known as "Chesterton's Fence": https://matt-rickard.com/chestertons-fence/ I'm not specifically opposed to this change. Nor am I in favour. Why do we print the first line of the doctests in the output of failing tests? If we understood the rationale for why we do that, it might give some insight into the consequences of removing it. If we don't know why it was shown in the first place, maybe we shouldn't remove it until we have some idea. I am -1 on another option flag unless there is no other choice. Each boolean flag option doubles the number of tests of unitttest itself needed for full coverage. Another option might be to leave the docstring line alone, and just *add* the 'ERROR' to the method name line: # current output test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR # enhancement test_broken_doc (mathlib.testing.test_utils.TestMinmax) ERROR This is a docstring ... ERROR That seems to me to be less risky than trying to cram them all on one line. test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR By the way, I presume we do the same thing for FAIL lines, which have the same behaviour as ERROR lines: test_fail_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... FAIL test_fail_nodoc (mathlib.testing.test_utils.TestMinmax) ... FAIL -- ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47133] enhance unittest to show test name and docstring on one line
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://docs.python.org/3/library/unittest.html#unittest.TestCase.shortDescription so perhaps we shouldn't break what's not broken? And frankly, I don't see why the current behaviour is a problem, although maybe that's because the way I use unittest is different from the way you use it. Grepping the output for errors? Why run verbose mode if you aren't going to read the whole output? Seems very odd. Ethan says: "the test name is easily missed by anyone who isn't aware of that" Surely the solution to that is education, not changing unittest? Now you are aware of it, and the test name is no longer "easily missed". If it ever was. To me, it is plain as day. Here is some typical output: [steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring ... ERROR test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR test_empty_iterable (mathlib.testing.test_utils.TestMinmax) ... ok [additional passing tests ommitted for brevity] == ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax) This is a docstring -- Traceback (most recent call last): File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 20, in test_broken_doc self.assertEqual(1, x) NameError: name 'x' is not defined == ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) -- Traceback (most recent call last): File "/home/steve/Desktop/mathlib/testing/test_utils.py", line 24, in test_broken_nodoc self.assertEqual(1, x) NameError: name 'x' is not defined -- Ran 10 tests in 0.004s FAILED (errors=2) Errors are listed twice, once in the summary, and the second time in the details section showing the traceback. Note that if you just grep for ERROR you get the result you want: [steve ~]$ python3.10 -m unittest -v mathlib/testing/test_utils.py |& grep ERROR This is a docstring ... ERROR test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) ... ERROR ERROR: test_broken_doc (mathlib.testing.test_utils.TestMinmax) ERROR: test_broken_nodoc (mathlib.testing.test_utils.TestMinmax) So I am having trouble seeing what the problem here is. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue47133> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47134] Document the meaning of the number in OverflowError
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 documented: https://docs.python.org/3/library/exceptions.html#OverflowError help(OverflowError) is no more insightful, saying only: __init__(self, /, *args, **kwargs) Initialize self. See help(type(self)) for accurate signature. Other OverflowError exceptions do not include the numeric code: >>> math.exp(1) Traceback (most recent call last): File "", line 1, in OverflowError: math range error Is it an error code from C? Something to do with the number of digits of precision? An easter-egg to do with The Count Of Monte Cristo? -- assignee: docs@python components: Documentation messages: 416093 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Document the meaning of the number in OverflowError type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue47134> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47031] math.nan should note that NANs do not compare equal to anything
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 comparisons here, not arbitrary objects which may do arbitrary things in their `__eq__` method. The documentation for the math module assumes we're talking about sensible, standard numeric values that don't play strange tricks on the caller. Look at the first function documented: math.ceil(x) Return the ceiling of x, the smallest integer greater than or equal to x. If x is not a float, delegates to x.__ceil__(), which should return an Integral value. class MyWeirdFloat(float): def __ceil__(self): return -1 math.ceil(MyWeirdFloat(25.9)) # Returns -1 instead of the ceiling. Does the documentation really need to cover every imaginable weird class? I don't think so. Let's keep it simple. NANs compared unequal with all numeric values which directly or indirectly obey IEEE-754, which includes floats. -- ___ Python tracker <https://bugs.python.org/issue47031> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45297] Improve the IDLE shell save command
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/issue45297> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47031] math.nan should note that NANs do not compare equal to anything
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
"Due to the requirements of the `IEEE-754 standard
<https://en.wikipedia.org/wiki/IEEE_754>`_, math.nan and float('nan') are never
equal to any other value, including themselves. Use math.isnan to test for
NANs."
https://docs.python.org/3.8/library/math.html#math.nan
--
assignee: docs@python
components: Documentation
keywords: easy
messages: 415302
nosy: docs@python, steven.daprano
priority: normal
severity: normal
status: open
title: math.nan should note that NANs do not compare equal to anything
type: enhancement
versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue47031>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue47018] ImportError: cannot import name '_simple_enum' from 'enum'
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 and there is nothing to fix. I don't see "_simple_enum" listed anywhere in the enum documentation, so why do you think you should be able to import it? https://docs.python.org/3/library/enum.html By the way, "reinstall Python" is almost never the solution to problems. Why do you think you need to "fix the install"? -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue47018> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46967] Type union for except
Change by Steven D'Aprano : -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46961] Caching/interning of small ints sometimes fails
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 examples where they are not. Intentional or a bug? >>> x = 1 >>> y = pow(2, 31, 2**31-1) >>> y == x True >>> y is x False >>> x = 2 >>> y = pow(2, 31, 2**31-2) >>> y == x True >>> y is x False It also affects values which are presumably constant-folded at compile time: >>> x = 1 >>> y = 2**31 % (2**31 - 1) >>> z = 2**31 % (2**31 - 1) >>> x == y == z True >>> x is y False >>> y is z False >>> x is z False But if you run the code in exec, the value is interned: >>> code = """ ... x = 1 ... y = 2**31 % (2**31-1) ... """ >>> dis(code) 2 0 LOAD_CONST 0 (1) 2 STORE_NAME 0 (x) 3 4 LOAD_CONST 0 (1) 6 STORE_NAME 1 (y) 8 LOAD_CONST 1 (None) 10 RETURN_VALUE >>> exec(code) >>> x is y True Also affects zero: >>> x = 0 >>> y = 2**29 % (2**29) >>> x is y True >>> y = 2**30 % (2**30) >>> x is y False First noted here: https://discuss.python.org/t/cached-integer-id-on-high-calculations/14128/1 >>> sys.version '3.10.0 (default, Oct 28 2021, 20:43:43) [GCC 8.3.1 20190223 (Red Hat 8.3.1-2)]' -- components: Interpreter Core messages: 414762 nosy: steven.daprano priority: normal severity: normal status: open title: Caching/interning of small ints sometimes fails type: behavior versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue46961> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46947] unicodedata.name gives ValueError for control characters
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.
unicodedata.lookup() looks for aliases as well as names (since version 3.3).
https://www.unicode.org/Public/UNIDATA/UnicodeData.txt
https://www.unicode.org/Public/UNIDATA/NameAliases.txt
It is unfortunate that we have only a single function for looking up a unicode
code point by name, alias, alias-abbreviation, and named-sequence. That keeps
the API simple, but in corner cases like this it leads to confusion.
The obvious "fix" is to make name() return the alias if there is no official
name to return, but that is a change in behaviour. I have code that assumes
that C0 and C1 control characters have no name, and relies on name() raising an
exception for them.
Even if we changed the behaviour to return the alias, which alias should be
returned, the full alias or the abbreviation?
This doesn't fix the problem that name() and lookup() aren't inverses of each
other:
lookup('NUL') -> '\0 # using the abbreviated alias
name('\0') -> 'NULL' # returns the full alias (or vice versa)
It gets worse with named sequences:
>>> c = lookup('LATIN CAPITAL LETTER A WITH MACRON AND GRAVE')
>>> name(c)
Traceback (most recent call last):
File "", line 1, in
TypeError: name() argument 1 must be a unicode character, not str
>>> len(c)
2
So we cannot possibly make name() and lookup() inverses of each other.
What we really should have had is separate functions for name and alias
lookups, or better still, to expose the raw unicode tables as mappings and let
people create their own higher-level interfaces.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46947>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46923] Implement stack overflow protection for supported platforms
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 overflow" alone (with a space and no other qualifications): * on Bing, scroll halfway down the first page of results to find the "People also ask..." How do you get a stack overflow? How to prevent a stack overflow error? * also on Bing at the bottom of the first page of results is a question on stackoverflow.com asking what causes memory stack overflows; * on DuckDuckGo, the first page of search results fails to suggest anything useful; * on Google itself, on the first page is the People Also Ask What causes stack overflows? * as well as a link to Wikipedia's page on stack overflows. I expect that going forward, "python stack overflow exception" will be sufficient to hit the Python docs somewhere on the first page. Besides, presumably this OverflowedStack exception is likely to be rare, so I expect that few people will need to google it. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
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/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] Lambda can't be pickled with "spawn" and only "fork"
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. -- status: pending -> open ___ Python tracker <https://bugs.python.org/issue46871> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46883] Add glossary entries to clarify the true/True and false/False distinction
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 not as clear as I would prefer. Also relevant is this: https://docs.python.org/3/library/stdtypes.html#truth-value-testing -- ___ Python tracker <https://bugs.python.org/issue46883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46882] Clarify argument type of platform.platform(aliased, terse) to boolean
Steven D'Aprano added the comment: See #46883 -- ___ Python tracker <https://bugs.python.org/issue46882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46883] Add glossary entries to clarify the true/True and false/False distinction
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 False* in a boolean context. Other terms for this same concept include "truthy/falsey" and using true/false as adjectives rather than nouns, e.g. "a true value". But I am not sure whether this is actually written down anywhere in the documentation. It would be useful for those who are not aware of the convention (e.g. beginners and people coming from other languages) if the Glossary had entries for lowercase "true" and "false" that explained the usage and referred back to PEP 285. See for example #46882 where this came up. I suggest something like the following: boolean context Code such as ``if condition:`` and ``while condition:`` which causes the expression ``condition`` to be evaluated as if it were a :class:`bool`. false Any object which evaluates to the :class:`bool` singleton ``False`` in a :term:`boolean context`. Informally known as "falsey". See :term:`true` and :pep:`285`. Among the builtins , false values include ``None``, empty containers and strings, and zero numbers. true Any object which evaluates to the :class:`bool` singleton ``True`` in a :term:`boolean context`. Informally known as "truthy". See :term:`false` and :pep:`285`. Among the builtins , true values include non-empty containers and strings, non-zero numbers (including NANs), and all other objects by default. -- assignee: docs@python components: Documentation messages: 414204 nosy: docs@python, steven.daprano priority: normal severity: normal status: open title: Add glossary entries to clarify the true/True and false/False distinction type: enhancement versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue46883> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46882] Clarify argument type of platform.platform(aliased, terse) to boolean
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. Treated as a documentation change, your PR is wrong because it implies that *only* the singletons `True` and `False` are acceptable, when in fact any true and false (note the lowercase) values are acceptable. Personally, I prefer the terms "truthy" and "falsey", or "a true value" and "a false value" over a bare true/false, but some people do not, and it is a long-standing tradition in Python circles to understand lowercase true/false as the duck-typed values as opposed to the `True` and `False` bool singletons. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46882> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46871] BaseManager.register no longer supports lambda callable 3.8.12+
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.
Please double-check that the code you posted is the actual code that is
failing, and copy and paste the full traceback you receive, not just a one-line
summary.
Even if the error is reproducible, I doubt that the cause is what you state in
the title of this issue:
BaseManager.register no longer supports lambda callable
Lambdas are just functions, they aren't a different type of callable. So the
register method cannot distinguish between a lambda argument written directly
in place, and a named def defined earlier then passed by name. So whatever
error might be happening on your system, I doubt it has anything to do with the
use of lambda syntax
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46871>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : Removed file: https://bugs.python.org/file50635/6.jpeg ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- nosy: -xiaox55066 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413568 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413567 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
Change by Steven D'Aprano : -- Removed message: https://bugs.python.org/msg413566 ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46803] Item not shown when using mouse wheel to scroll for Listbox/Combobox
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 of just seven. By default, just three entries are visible at a time. If we number the lines 1-16, and start with lines 1-3 visible, then we get: * Initial view: lines 1, 2, 3 visible, 4-16 below the view area. * Scrollwheel down. * Lines 6-8 visible, 1-5 above the view area, 9-16 below. * Scrollwheel down. * Lines 11-13 visible, 1-10 above the view area, 14-16 below. * Scrollwheel down. * Lines 14-16 visible, 1-13 above the view area. So the scrollwheel scrolls down by: 5 lines, 5 lines, 3 lines. Going back the otherway, the scrollwheel scrolls up by 5, 5, 3. Why five lines? My guess is that it might have something to do with 16//3 = 5. I don't know if this is something we can fix, or we're stuck with whatever tk/tcl does. I don't know if this is related, or should be a separate issue, but I see that the keyboard PageUp and PageDown keys don't scroll up or down by a page, but by a single line -- and they don't correctly highlight the selected line either. Paging should scroll up or down by N-1 lines, where N is the number of visible lines in the view area. Likewise for clicking in the scrollbar's PageUp/PageDown region, which also scrolls by a single line. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46776] RecursionError when using property() inside classes
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 <https://bugs.python.org/issue46776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46776] RecursionError when using property() inside classes
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 instance.bar, which returns instance.bar... forever, or until RecursionError is triggered. Your class is the same as: class Foo: @property def bar(self): return self.bar So when you call instance.bar, it looks up bar, which is the property, which looks up bar, which is the property, which looks up bar, and so on. What did you expect to happen? -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46776> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46766] Add a class for file operations so a syntax such as open("file.img", File.Write | File.Binary | File.Disk) is possible.
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/issue46766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46766] Add a class for file operations so a syntax such as open("file.img", File.Write | File.Binary | File.Disk) is possible.
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 difference between binary and text files. It works the same way
in probably dozens of different languages.
open("file.img", File.Write | File.Binary | File.Disk) needs the beginner to
learn the same details, *plus* they have to learn about this mystery File
object, classes, dot notation, `|` the bitwise-or operator, and how to import
File from the io module.
My guess is that File.Write etc are just enums equivalent to strings 'w' and
'b', but what's File.Disk?
What else does this File object do?
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46766>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39805] Copying functions doesn't actually copy them
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.org/issue39805> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
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 than its floor, so as to preserve the usual identity x == (x // y) * y + x % y but it's not clear why that identity is more important than floor division returning the floor. I guess we could just document the difference and maybe add a Decimal ceildiv method, although that makes me sad :-( Could we "fix" Decimal? -- ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46639] Ceil division with math.ceildiv
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.ceildiv(x, y) be implemented as -(-x//y) in a type-agnostic fashion? Perhaps it is too late in the night for me, but I have no idea what ceilrem(x, y) would do or why anyone might want it. I agree with Vladimir that the import thing is not an issue. If we can require an import for much more important functions as sin, cos, tan, log, etc, then requiring an import is not excessive for a function of secondary importance. Feature-bloat: its taken 30 years for somebody to request ceildiv. At that rate, it will take another 500 years for us to catch up to mpz in terms of features/bloat. I'm not losing sleep over that :-) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46639> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46612] Unclear behavior of += operator
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: "An augmented assignment evaluates the target (which, unlike normal assignment statements, cannot be an unpacking) and the expression list, performs the binary operation specific to the type of assignment on the two operands, and assigns the result to the original target." And also: "the assignment done by augmented assignment statements is handled the same way as normal assignments." -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46612> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46467] Rounding 5, 50, 500 behaves differently depending on preceding value
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 even" and for rounding many values, it minimizes the expected total rounding error. https://en.wikipedia.org/wiki/Rounding#Round_half_to_even -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46467> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46466] help function reads comments
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 the top of the module (see inspect.getcomments())." -- nosy: +dam1784, steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue46466> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
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
False
Also see the disassembly I posted on Python-Ideas.
--
___
Python tracker
<https://bugs.python.org/issue46393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
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/issue46393> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46393] Generate frozenset constants when explicitly appropriate
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.daprano
___
Python tracker
<https://bugs.python.org/issue46393>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46385] Remove parenthetical symbols for readability and nlp
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 -> closed ___ Python tracker <https://bugs.python.org/issue46385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46385] Remove parenthetical symbols for readability and nlp
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 dashes (or with parentheses [commonly called round brackets in the British commonwealth]) or even commas -- so even in natural language they are used. Even programming languages which are much, much closer to natural language than Python, like Hypertalk and Inform-7, use parentheses and delimiters for various purposes, for example: http://inform7.com/book/WI_21_3.html Ultimately, we simply can't remove brackets (square, round or curly) from the language. It would make it impossible to tell whether func(1, 2, 3, 4, 5) was a call to func() with 5 integer arguments, or a single 5-element list argument, or two 2-element lists and an integer, or three integers and a 2-element list, etc. So don't waste your time taking this proposal to Python-Ideas. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46385> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46365] _ curses module is not installed
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 ___ Python tracker <https://bugs.python.org/issue46365> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46354] AttributeError: module 'collections' has no attribute 'Mapping'
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 importing the ABCs from 'collections' instead of from 'collections.abc' is deprecated since Python 3.3,and in 3.9 it will stop working So this is not a bug. -- nosy: +steven.daprano stage: -> resolved status: pending -> closed ___ Python tracker <https://bugs.python.org/issue46354> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46350] re.sub, re.Match.expand, etc doesn't allow x, u, U, or N escapes in the template
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 appears to have nothing to
do with regexes, but maybe I'm wrong? In any case, whether this is regular
expressions or plain old strings, it seems reasonable to me to limit \N{} to
ASCII-only (Unicode guarantees that code point names are ASCII) and some
reasonable length. I can't imagine the Unicode consortium ever deciding on a
name > 255 characters, it wouldn't be practical.
- The difference in normalisation between group names and identifiers.
--
nosy: +steven.daprano
___
Python tracker
<https://bugs.python.org/issue46350>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46349] inspect.getdoc() should append parent class method docs when encountering a local one line docstring
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 parent class docstring will have a lot of both false positives and false negatives. The false negatives just revert to the status quo, but the false positives will be annoying. I am leery of DWIM code. The reader should be capable of recognising that sort of message and calling up help for that class, so I think the benefit here is minimal and the failures common. But if we do go ahead with this, I have a style issue. At the moment, getdoc shadows `object`, for no good purpose. (I'm fine with shadowing builtins if there is a good reason.) This is a minor issue that is not worth fixing on its own, but if you do end up touching getdoc to implement this, could you please remove the unnecessary shadowing? If we can call the function "get *doc*" we can call the parameter *obj* :-) -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46349> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46324] 'import traceback' Causes a Crash
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: crash -> behavior ___ Python tracker <https://bugs.python.org/issue46324> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
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 irrelevant.
Removing all the irrelevant and extraneous complexity that obfuscates the
problem, we get to two lines of simplified code sufficient to demonstrate the
issue:
each = "name = "
[code.strip()[0] for func, code in [each.split('=')]]
which sure enough raises IndexError.
The hint was looking at your fix() function, which made it clear that you are
getting an IndexError because the string is an empty string. Well of course you
do, that is expected behaviour.
Why do you get an empty string? Because you split the line "name = " on the
equals sign, giving
func = "name "
code = " "
then you strip the whitespace from code giving:
code = ""
then you try to extract the first character of code using code[0], which raises
IndexError, because that's what it is supposed to do.
So there is no bug here, Python is working correctly.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46302>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46302] IndexError inside list comprehension + workaround
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" for i in range(2) if var.strip()[0] == "u"] ['ok', 'ok'] I am 99.99% certain that you have a bug in your code, but your code is so complicated that it is not obvious at a glance where the bug is. I am strongly tempted to just close this as "Works for me" and tell you to come back and re-open the bug report when you have isolated the issue to a simpler case, but I will resist the temptation for now. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46302> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46293] Typo in specifying escape sequence
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 -> closed ___ Python tracker <https://bugs.python.org/issue46293> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
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
sympathetic to this.
I can see a difference between (for example) the questions:
"I see that print('Hello world') returns None, but is it safe to assume
that print will *always* return None? It is not documented anywhere as
far as I can see."
and
"What does x = print('Hello world') do?"
--
___
Python tracker
<https://bugs.python.org/issue46282>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46282] print() docs do not indicate its return value
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/stdtypes.html#mutable-sequence-types e.g. s.append, s.clear, s.extend, s.insert, s.remove, s.reverse and likewise for list.sort, set.add, dict.clear and many others. (However, dict.update is a rare exception, it does mention that it returns None.) We should not feel it necessary to add an explicit comment to every function or method that operates by side-effect stating that they return None. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46282> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46213] webbrowser.open doesn't work in Termux
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://mail.python.org/pipermail/python-dev/2017-December/151171.html for a longer discussion. There's an Android build factory https://github.com/python/buildmaster-config/pull/26 but I cannot see an official Android buildbot running. https://buildbot.python.org/all/#/ The PR seems straightforward and simple to me, but I'm not an expert on the webbrowser module nor do I have an Android where I can test it to see if it works. DonaldDuck1313, your NEWS entry needs to be re-written to use ReST (Restructured Text) rather than Markdown: Change: [Termux](https://termux.com/) to `Termux <https://termux.com/>`_ -- nosy: +steven.daprano, xdegaye type: -> enhancement ___ Python tracker <https://bugs.python.org/issue46213> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46199] Calculation influenced by print
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 (and why, if it isn't obvious). 3. What actually happened instead. Ideally you should be able to get your example down to using one or two values, not three lists with 30 values each (90 values). -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46199> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46188] dictionary creation error
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
explanations. The behaviour you see is correct. Except for the last line, which
is a copy-and-paste error on your part: the actual last line is
>>> dictionary
{0: None, None: None, 2: 2, 4: 4, 6: 6, 8: 8}
So there is no error here, everything is working as expected.
If you need help understanding why the code is correct, please take the
discussion to the Python Discuss forum where you will be sure to get answers.
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46188>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'
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/issue46183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46183] float function errors on negative number string with comma seperator ex: '-1, 234.0'
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 is irrelevant. Commas are not supported
regardless of whether there is a negative sign or not.
The difficulty with commas is that it is ambiguous whether float('1,234')
should interpret the comma as British/American digit grouping separator, and
return 1234.0, or as the European decimal point, and return 1.234. For good or
bad, Python has a bias towards English (like most programming languages) and so
it chooses to only recognise the decimal point as a dot in the British/American
style, and reject the comma.
If you want to support European-style commas as the decimal point, the easiest
way is to call float('1,234'.replace(',', '.'))
--
nosy: +steven.daprano
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46183>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46173] float(x) with large x not raise OverflowError
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 before the correctly rounded result of float(M+K) overflows. Anything less than K=2**960 is too small to be distinguished from M when added to it. So there's no bug here, the behaviour is correct for IEEE-754, although perhaps the documentation is misleading. Mark, is my explanation right? -- nosy: +mark.dickinson, steven.daprano ___ Python tracker <https://bugs.python.org/issue46173> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46164] New `both()` operator for matching multiple variables to one
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 -> closed ___ Python tracker <https://bugs.python.org/issue46164> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
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 docs, but you haven't responded.
The description given in the docs exactly explains the observed
behaviour. Without recognising that, the observed behaviour is
perplexing to the point that it suggested to at least one person that it
was a bug in the language.
If you're not prepared to suggest an improvement to the documentation,
then I don't think that this conversation is going anywhere and maybe
we should just let the discussion die.
But for the record, in case you, or anyone else, does want to continue
the discussion in the hope of reaching additional insight to the
problem, my further comments are below.
[...]
> Saying that code will be "executed as if it were embedded in a class
> definition" is correct only so far as the fact that globals and locals
> are different in this case.
So it's correct in all the ways that matter:
- different globals and locals;
- and the behaviour is different.
and incorrect in no ways at all (see below). I don't think that supports
a charge of "misleading".
The bottom line here is that the description in the docs that you call
"misleading" did not mislead me, but lead me directly to the solution of
why the code behaved as it did, and why that was the intentional
behaviour rather than a bug.
So un-misleading, if you will.
> But it's also misleading because the code
> gets compiled as module-level code, not as class code.
Obviously there is no actual "class code" involved. That is why the
description says that it is executed *as if* it were embedded inside a
class statement, rather than by having an actual class statement added
to your source string.
I don't understand your comment about "compiled as module-level ... not
as class code". What's class code? (Aside from the actual class
statement itself, which is a red herring.)
If you look at the disassembly of the following two snippets:
dis.dis("""
a = 1
def f():
return a
print(f())
""")
and
dis.dis("""
class C:
a = 1
def f():
return a
print(f())
""")
the generated bytecode for the lines `a = 1` etc is the same, putting
aside the code for the actual class statement part. You get the same
code for `a = 1`
LOAD_CONST(1)
STORE_NAME(a)
the same code for both the body of the function:
LOAD_GLOBAL (a)
RETURN_VALUE
and the `def f()` statement:
LOAD_CONST()
LOAD_CONST('f')
MAKE_FUNCTION
STORE_NAME
and the same code for the call to print:
LOAD_NAME(print)
LOAD_NAME(f)
CALL_FUNCTION
CALL_FUNCTION
POP_TOP
LOAD_CONST (None)
RETURN_VALUE
Obviously the offsets and locations of constants will be different, but
aside from those incidental details, the code generated for the block is
the same whether it is inside a class statement or not.
So I don't understand what you consider to be the difference between
code compiled at module-level and code compiled at class-level. They
seem to me to be identical (aside from the incidentals).
The visible difference in behaviour relates to the *execution* of the
code, not to whether (quote):
"the code gets compiled as module-level code [or] as class code".
There is no distinct "class code". The difference in behaviour is in the
execution, not to the compilation.
> It should be pretty obvious why the following fails:
>
> exec("a = 1\ndef f(): return a\nprint(f())", {}, {})
Yes, it is obvious why it fails, in the same sense as the maths joke
about the professor who stares at the equations on the blackboard for
twenty minutes before exclaiming "Yes, it is obvious!".
It takes a sophisticated understanding of Python's scoping rules to
understand why that fails when the other cases succeed.
> Assignment is local by default, unless otherwise declared. Function
> f() has no access to the local scope where `a` is defined
With the same dict used for globals and locals, execution runs the
statements `a = 1`, the `def f` and the print in the same scope, which
is *both* global and local. This is what happens when you run code at
the module level: locals is globals.
Consequently, the statement `a = 1` assigns a to the local namespace,
which is the global namespace. And the call to f() retrieves a from the
global namespace, which is the local namespace.
This is what happens when you execute the code at module-level.
[issue46153] function fails in exec when locals is given
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 > > class definition. > > That's a misleading comparison That's taken straight out of the documentation. I don't think it is misleading, it is the opposite of misleading. Until I understood that exec with two different mapping objects as globals and locals behaves as if the code where embedded inside a class, I found the reported behaviour totally perplexing. If you think it is wrong, how would you explain the observed behaviour, and how would you word the documentation? > because a class definition intentionally supports nonlocal closures, I don't know what you mean by that. Classes are never closures. Only functions can be closures. (*Be* closures? *Have* a closure? The terminology is ambiguous.) >>> def f(): ... a = 1 ... class C: ... nonlocal a ... a = 999 ... print(a) ... return C ... >>> C = f() 999 >>> C.__closure__ Traceback (most recent call last): File "", line 1, in AttributeError: type object 'C' has no attribute '__closure__'. Did you mean: '__module__'? I don't know what terminology is appropriate here, but "closure" is surely not it. > which exec() doesn't support and shouldn't support. For example: [snip examples] Neither of those cases are relevant to the example here. > exec() executes as module code. Using separate globals and locals > mappings doesn't magically change how the code is compiled and > executed to make it equivalent to a class definition. Neither I nor the documentation said it was equivalent to a class definition. It is equivalent to code executed inside a class scope. > To understand > the case of separate globals and locals, just remember that assigning > to a variable by default makes it a local variable, unless it's > declared as a global. Also, class and function definitions are > implicitly an assignment, which by default will be local. Neither of those facts explain why the example code """a = 1 def f(): return a print(f()) """ behaves differently when given two distinct dicts as the globals and locals parameters, versus all the other cases (no arguments provided, or one argument, or the same dict repeated twice). Only the case where the provided globals and locals dicts are distinct behaves differently, and it behaves exactly the same as if you embedded that chunk of code inside a class definition and then executed it. -- ___ Python tracker <https://bugs.python.org/issue46153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
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 mathematics: https://hsm.stackexchange.com/questions/7247/in-a-popular-anecdote-who-took-20-minutes-to-decide-that-a-thing-was-obvious -- ___ Python tracker <https://bugs.python.org/issue46153> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
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 expectation that f() will look for a in the locals dict is
not correct. That's not how name resolution in Python works. a is looked up as
a global. You can't turn it into a local variable just by providing locals.
The names of the parameters are unfortunately confusing. The globals parameter
is always the global namespace. But locals is *never* the function's local
namespace. Nor is it a surrounding scope (nested functions), but it may be
treated as a surrounding *class* scope.
I agree that the behaviour is surprising and complex, but if you work through
the documentation carefully, it is behaving as designed.
What we need to realise is that locals describes the namespace where the *def
statement* runs, not the namespace used by the body of the function. The
function body's locals is always created when the function is called, it is
inaccessible from outside the function, and it most certainly does not use the
so-called "locals" parameter given to exec().
--
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
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:
>>> class C:
... a = 1
... def f():
... return a # This looks for global a, not C.a
... print(f())
...
Traceback (most recent call last):
File "", line 1, in
File "", line 5, in C
File "", line 4, in f
NameError: name 'a' is not defined
which is intentional behaviour. Functions defined inside a class do not have
direct access to the variables inside the class. I thought there was a FAQ
about this but I can't find it now.
So there is no bug here. By passing two distinct dicts as the globals and
locals to exec, the interpreter treats the code as if it were being executed
inside the body of a class statement. Both the a and the f get created in the
locals dict, not the globals dict:
>>> g = {'__builtins__': None}
>>> l = {}
>>> exec("""a = 1
... def f():
... return a
... """, g, l)
>>> g
{'__builtins__': None}
>>> l
{'a': 1, 'f': }
But when you call f(), it is looking for a in the globals dict.
--
resolution: -> not a bug
stage: -> resolved
status: open -> closed
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46153] function fails in exec when locals is given
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 see
is None. Or you can use the dis module to look at the disassembled bytecode.
To be a closure, you have to insert both the "a" and the `def f()` inside
another function, and then run that:
code = """
def outer():
a = 1
def f():
return a
return f
f = outer()
print(f())
"""
exec(code, {}, {})
prints 1 as expected.
--
components: +Interpreter Core
nosy: +steven.daprano
title: closure fails in exec when locals is given -> function fails in exec
when locals is given
type: crash -> behavior
___
Python tracker
<https://bugs.python.org/issue46153>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46112] PEP 8 code format
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." So PEP 8 itself tells us that legacy code that ignores the style guidelines is already compliant with PEP 8. -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46112> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23522] Misleading note in Statistics module documentation
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 for being so slow to come around. People may be less likely to wrongly imagine there is a single centre location of data if we use the term "central tendency" instead of location. I think we should also drop the reference to mode(), since it only works with discrete data and is not suitable for continuous data. "The mean is strongly affected by outliers and is not necessarily a typical example of the data points. For a more robust, although less efficient, measure of central tendency, see median()" How do we feel about linking to Wikipedia? I'd like to link both outliers and central tendency to the appropriate Wikipedia entries. -- stage: resolved -> versions: +Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 -Python 3.4 ___ Python tracker <https://bugs.python.org/issue23522> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
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__ = int
...
>>> type(A())
>>> a = A()
>>> a.__class__ = int
>>> type(a)
So from A, we might think that type() ignores __class__
>>> class B:
... pass
...
>>> type(B()) # no __class__ to inspect
>>> b = B()
>>> b.__class__ = int
Traceback (most recent call last):
File "", line 1, in
TypeError: __class__ assignment only supported for mutable types or ModuleType
subclasses
How very odd. But okay, let's try something else:
>>> b.__class__ = A # lie that this is an A not a B
>>> type(b)
So now type() *does* inspect __class__, and believes it.
If we generate the __class__ attribute dynamically with __getattr__, the method
doesn't even get called. But if we use __getattribute__:
>>> class C:
... def __getattribute__(self, name):
... print('C getattribute:', name)
... if name == '__class__':
... return int
... raise AttributeError
...
>>> C().__class__
C getattribute: __class__
>>> type(C())
type() ignores the dynamically generated __class__. But isinstance does not:
>>> isinstance(C(), int)
C getattribute: __class__
True
The same applies if we use property:
>>> class D:
... @property
... def __class__(self):
... return int
...
>>> type(D())
>>> isinstance(D(), int)
True
So the rules appear to be:
- you can set __class__, but only sometimes;
- type() will believe __class__, but only sometimes;
- you can generate __class__ dynamically, but not with __getattr__;
- isinstance() will believe __class__ (always?);
- and there is no indication of how much of this is deliberate language feature
and how much is an accident of implementation.
--
___
Python tracker
<https://bugs.python.org/issue32683>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
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 instance, and then immediately garbage collect it. In any case, type() and isinstance() do not work the same way. type() does not inspect the `__class__` attribute. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
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 discuss the interaction between a class' "real" type and it's "fake" type. To be honest, I'm not even sure I fully understand the interaction myself, or how they combine with virtual subclasses. A lot of my information comes from this Stackoverflow post: https://stackoverflow.com/questions/1060499/difference-between-typeobj-and-obj-class and in particular this comment: "Some code does this deliberately to lie about the type of objects, such as weakref.proxy. Some people think obj.__class__ should be preferred, because it believes the lie, while some people think type(obj) should be preferred because it ignores the lie. isinstance will return true if an object's real class or its lie class is an instance of the second argument." So I think that the behaviour here is correct, but it is not documented well and we should fix that. What I think happens: * type(obj) always and only returns the actual internal (C-level) type of the object, guaranteed to be a type object. * isinstance(obj, classinfo) returns True if any of the following hold: - the type() of object is a subclass of any of the classes in the classinfo object (a class, a Union of classes, or a tuple of classes); - obj.__class__ is a subclass of any of the classes in classinfo; - or obj is registered as a virtual subclass of any of the classes in classinfo, by calling type(ob).__subclasshook__; * obj.__class__ is determined using the normal attribute lookup mechanism, which means it does not have to be a static attribute but can be dynamically generated using properties, __getattr__, __getattribute__ or any other similar mechanism. And for the avoidance of doubt, a class is always considered a subclass of itself. I'm really not sure about the interaction with virtual subclasses, I probably have that bit wrong. And it is not clear to me what happens if __class__ is a non-type object. It seems to be permitted. Improving the documentation would be excellent. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
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." https://docs.python.org/3/reference/datamodel.html#object.__getattribute__ That includes lookups for `__class__`, regardless of whether the function doing the lookup is isinstance or some other function. You ask: "Are there any reasons why __class__ cannot be retrieved with object.__getattribute__ instead?" Yes, that would ignore overloaded attribute access, which would be a bug in my opinion. Being able to dynamically generate computed attributes by overloading `__getattr__` and `__getattribute__` is not a bug. It is part of Python's data model. See the documentation above. And that includes `__class__`. I don't believe that it is an accident or a bug that isinstance uses ordinary attribute lookup, which goes through the standard mechanism including the class' own `__getattribute__` method. But I will ask on the Python-Dev mailing list in case Guido or other core developers think that it is wrong to do so. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32683] isinstance is calling ob.__getattribute__ as a fallback instead of object.__class__.__get__
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 to check the object's `__class__`, if it has one. To do that it has to look at obj.__class__, which your class intercepts using `__getattribute__` and causes a side-effect. Overloading `__getattribute__` is perilous, because it intercepts *all* instance attribute lookups. In my opinion, one should (almost?) never overload the `__getattribute__` method, it is safer to overload `__getattr__`. In any case, I don't think there is anything to fix here. Dan has not responded since his initial bug report nearly four years ago, so I'm inclined to close this as "Not A Bug". Unless somebody gives a more convincing reason why the current behaviour is wrong, I think we should close it. -- ___ Python tracker <https://bugs.python.org/issue32683> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46017] Tutorial incorrectly refers to skits rather than sketches.
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 literary work or idea; especially a short, often humorous or satirical scene or play, frequently as part of a revue or variety show. Synonym: skit" https://en.wiktionary.org/wiki/sketch#English The Pythons themselves sometimes describe their work as "skits" and sometimes as "sketches". E.g. quote: "Included are transcripts of Hollywood Bowl Skits..." http://www.montypython.com/book_Monty%20Python%20Live!/24 while of course it is always "the Dead Parrot sketch". -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue46017> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45995] string formatting: normalize negative zero
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.org/issue45995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45995] string formatting: normalize negative zero
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 for the format method and f-strings. (I suspect that unless you get immediate and uncontroversial agreement from multiple core developers, you may need to take it for further discussion and perhaps even a PEP.) What you call a "distraction" I consider to be critical part of the display. The numbers you are displaying actually are negative, and rounding them for display does not change that. So they ought to show the minus sign. So I'm not really very sympathetic to this feature request. -- nosy: +steven.daprano versions: +Python 3.11 ___ Python tracker <https://bugs.python.org/issue45995> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45989] Add new function or method to return the dict key with the maximum value
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/issue45989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45989] Getting key of max value of dict really dose not sense
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 to find the maximum key according to its associated value, the key function that will work is collective_signals.get. That makes perfect sense. Not every one-line piece of code needs to be a builtin function. In any case, Python 3.6 to 3.10 are all in feature-freeze. Even if we added some special function to do this, which I doubt we will do, it could only go into 3.11. -- nosy: +steven.daprano versions: -Python 3.10, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45989> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45980] Why there isn't a “Python 2.2” for PyPI's classifiers?
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.daprano resolution: -> not a bug stage: -> resolved status: open -> closed type: performance -> versions: -Python 3.10, Python 3.11, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue45980> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45966] Error in Multiplication
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/issue45966> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45876] Improve accuracy of stdev functions in statistics
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 <https://bugs.python.org/issue45876> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45891] bool variable isinstance of int
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 some light on this", such as Reddit's r/python, the various mailing lists, Discuss, IRC, etc. In future please use them rather than the bug tracker. Regarding bool, you can start by reading this: https://www.python.org/dev/peps/pep-0285/ If that doesn't answer your questions, please feel free to take them to the many different forums here: https://www.python.org/community/forums/ https://www.python.org/community/lists/ https://www.python.org/community/irc/ -- nosy: +steven.daprano resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45869] Unicode and acii regular expressions do not agree on ascii space characters
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 3.9 ___ Python tracker <https://bugs.python.org/issue45869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45869] Unicode and acii regular expressions do not agree on ascii space characters
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 regular expression on strings consisting only of ASCII characters." But I'm not sure why you have that expectation. Is it documented somewhere? The docs clearly say that for character classes, "the characters they match depends on whether ASCII or LOCALE mode is in force." I am unable to find anything that says that the differences are limited only to non-ASCII code points. I don't think there is any standard definition of "whitespace" in either the ASCII standard, or the very many different regex engines (Perl, dot-Net, Java, ECMA, etc). Unicode does have an official whitespace character property, and as far as I can see '\x1c' through '\x1f' (File Separator, Group Separator, Record Separator and Unit Separator) are not considered whitespace: https://en.wikipedia.org/wiki/Unicode_character_property#Whitespace But the str.isspace() method does consider them as whitespace, while bytes.isspace() does not. >>> '\x1c'.isspace() True >>> b'\x1c'.isspace() False -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue45869> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45766] Add direct proportion option to statistics.linear_regression()
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 counts as close to zero?) If users want to check that, they can do so themselves. Regarding my concern with the coefficient of determination, I don't think that's enough of a problem that it should delay adding this functionality. I don't know what, if anything, should be done, but in the meantime we should approve this new feature. For the record, an example of the problem can be seen on the last slide here: https://www.azdhs.gov/documents/preparedness/state-laboratory/lab-licensure-certification/technical-resources/calibration-training/09-linear-forced-through-zero-calib.pdf The computed r**2 of 1.0 is clearly too high for the RTO line. -- ___ Python tracker <https://bugs.python.org/issue45766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45827] Unittest - commenting passing tests cause previous failing tests to pass
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 snippet makes months, a mutable list, a class attribute, which means it is shared by all instances of the class. The second snippet mutates that list, which means every single instance will see the same value. So commenting out some tests will change whether or not the shared list gets mutated, which will change whether or not other tests pass or fail. I think the smallest change you need make to fix your code is to put the initialisation of My_Time into an `__init__` method, so that the attributes (including the list) are no longer shared between all instances. class My_Time: def __init__(self): ... -- nosy: +steven.daprano ___ Python tracker <https://bugs.python.org/issue45827> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45811] Improve error message when source code contains invisible control characters
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 call last):
File "", line 1, in
File "", line 1
print("Hello")
^
SyntaxError: invalid syntax
The caret points to an invisible character. The offending control character is
not visible in the traceback, or the source code unless you use a hex editor.
Copying and pasting the string from the traceback, or the source code, may
remove the control character (depending on the tools you use), making it even
harder to track down the problem.
I suggest that the syntax error should state that the problem is an invisible
control character, and display it as a standard human-readable code together
with its hex code:
SyntaxError: invisible control character ^W (0x17)
Just in case it isn't obvious what the mapping between controls and the human
visible string is:
def control(char):
n = ord(char)
if 0 <= n <= 0x1F:
# C0 control codes
return '^' + chr(ord('@')+n)
elif n == 0x7F:
# DEL
return '^?'
elif 0x80 <= n <= 0x9F:
# C1 control codes
return 'Esc+' + chr(ord('@')+n-0x80)
else:
raise ValueError('Not a control character.')
https://en.wikipedia.org/wiki/C0_and_C1_control_codes
--
components: Interpreter Core
messages: 406379
nosy: steven.daprano
priority: normal
severity: normal
status: open
title: Improve error message when source code contains invisible control
characters
type: enhancement
versions: Python 3.11
___
Python tracker
<https://bugs.python.org/issue45811>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45810] Prohibit invisible control characters in string literals and comments
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/message/DN24FK3A2DSO4HBGEDGJXERSAUYK6VK6/ we should ban C0 and C1 control characters (aside from \t\n\f\r) in string literals and comments too. To be clear, the ban is on actual invisible control characters, not escape sequences. -- components: Interpreter Core messages: 406370 nosy: serhiy.storchaka, steven.daprano priority: normal severity: normal status: open title: Prohibit invisible control characters in string literals and comments type: security versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45810> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45784] SAP HANA Training in Chennai
Change by Steven D'Aprano : -- resolution: -> not a bug stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45784> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45782] Bug in struct.pack
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: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue45782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45766] Add direct proportion option to statistics.linear_regression()
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 competent to deal with. Are you happy to hold off a few days while I consult with some statistics experts? - There is some uncertainty as to the correct method of calculation, with many stats packages giving different results for the same data, e.g. https://web.ist.utl.pt/~ist11038/compute/errtheory/,regression/regrthroughorigin.pdf - Forcing the intercept through the origin is a dubious thing to do, even if you think it is theoretically justified, see for example the above paper, also: https://dynamicecology.wordpress.com/2017/04/13/dont-force-your-regression-through-zero-just-because-you-know-the-true-intercept-has-to-be-zero/ https://www.theanalysisfactor.com/regression-through-the-origin/ - Regression through the origin needs a revised calculation for the coefficient of determination (Pearson's R squared): https://pubs.cif-ifc.org/doi/pdf/10.5558/tfc71326-3 https://www.researchgate.net/publication/28191_Re-interpreting_R-squared_regression_through_the_origin_and_weighted_least_squares but it's not clear how to revise the calculation, with some methods giving R squared negative or greater than 1. - Regression through the origin is only one of a number of variants of least-squares linear regression that we might also wish to offer, e.g. intercept-only, Deming or orthogonal regression. https://en.wikipedia.org/wiki/Deming_regression -- ___ Python tracker <https://bugs.python.org/issue45766> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45721] Improve error message when python shell command is entered at the REPL prompt
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://windowsquestions.com/2021/10/09/syntaxerror-invalid-syntax-perhaps-you-forgot-a-comma/ I think it would be a nice feature if the compiler recognised obvious cases of "user tried to call Python from the Python prompt", and suggested a fix. If the statement matches the regex r"python\s+" the error message might say "it looks like you are trying to run a shell command at the Python prompt" rather than suggest a missing comma. -- messages: 405764 nosy: steven.daprano priority: normal severity: normal status: open title: Improve error message when python shell command is entered at the REPL prompt type: enhancement versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45721> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45705] |= set update scoping
Change by Steven D'Aprano : -- stage: -> resolved ___ Python tracker <https://bugs.python.org/issue45705> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
