[issue46558] Quadratic time internal base conversions
Carl Friedrich Bolz-Tereick added the comment: Somebody pointed me to V8's implementation of str(bigint) today: https://github.com/v8/v8/blob/main/src/bigint/tostring.cc They say that they can compute str(factorial(1_000_000)) (which is 5.5 million decimal digits) in 1.5s: https://twitter.com/JakobKummerow/status/1487872478076620800 As far as I understand the code (I suck at C++) they recursively split the bigint into halves using % 10^n at each recursion step, but pre-compute and cache the divisors' inverses. -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue46558> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
Carl Friedrich Bolz-Tereick added the comment:
Ok, I can definitely agree with Serhiy pov: "True" is a keyword that always
evaluates to the object that you get when you call bool(1). There is usually no
name "True" and directly assigning to it is forbidden. But there are various
other ways to assign a name "True". One is eg globals("True") = 5, another one
(discussed in this issue) is using identifiers that NFKC-normalize to the
string "True".
--
___
Python tracker
<https://bugs.python.org/issue46555>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46555] Unicode-mangled names refer inconsistently to constants
Carl Friedrich Bolz-Tereick added the comment:
hah, this is "great":
>>> 𝕋𝕣𝕦𝕖 = 1
>>> globals()
{'__name__': '__main__', '__doc__': None, '__package__': None, '__loader__':
, '__spec__': None,
'__annotations__': {}, '__builtins__': , 'True':
1}
The problem is that the lexer assumes that anything that is not ASCII cannot be
a keyword and lexes 𝕋𝕣𝕦𝕖 as an identifier.
--
nosy: +Carl.Friedrich.Bolz
___
Python tracker
<https://bugs.python.org/issue46555>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
Carl Friedrich Bolz-Tereick added the comment: Or, in other words, in my opinion this is the root cause of the bug: class Base: def __init_subclass__(cls): global broken_class broken_class = cls assert 0 try: class Broken(Base): pass except: pass assert broken_class not in Base.__subclasses__() The assert fails, which imo it shouldn't. -- ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38085] Interrupting class creation in __init_subclass__ may lead to incorrect isinstance() and issubclass() results
Carl Friedrich Bolz-Tereick added the comment: hm, I think I figured it out. The root cause is that even though the creation of the class Triffid fails, it can still be found via Animal.__subclasses__(), which the special subclass logic for ABCs is looking at. Triffid fills its _abc_impl data with some content, but Triffid._abc_impl was never successfully initialized, therefore it mutates the _abc_impl of its first base class Animal. My conclusion would be that if a class is not successfully created, it shouldn't appear in the .__subclasses__() list of its bases. See attached script for some illuminating prints. -- nosy: +Carl.Friedrich.Bolz Added file: https://bugs.python.org/file50515/x.py ___ Python tracker <https://bugs.python.org/issue38085> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
Carl Friedrich Bolz-Tereick added the comment: Oh, don't worry, it's all good! It got fixed and I learned something. -- ___ Python tracker <https://bugs.python.org/issue46042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
Carl Friedrich Bolz-Tereick added the comment: ah, confused, seems you fixed them both too. will take a closer look! -- ___ Python tracker <https://bugs.python.org/issue46042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
Carl Friedrich Bolz-Tereick added the comment: Oh no, I was about to open mine ;-) https://github.com/python/cpython/compare/main...cfbolz:bpo-46042-syntax-error-range-duplicate-argument?expand=1 Basically equivalent, but I fixed the second bug too (would be very easy to add to yours) -- ___ Python tracker <https://bugs.python.org/issue46042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
Carl Friedrich Bolz-Tereick added the comment:
let's see whether I promised too much, I don't know CPython's symtable.c too
well yet ;-). Will shout for help when I get stuck.
Anyway, here is a related bug, coming from the same symtable function
symtable_add_def_helper, also with an imprecise error location:
$ cat x.py
{i for i in range(5)
if (j := 0)
for j in range(5)}
$ ./python x.py
File "/home/cfbolz/projects/cpython/x.py", line 1
{i for i in range(5)
SyntaxError: comprehension inner loop cannot rebind assignment expression
target 'j'
--
___
Python tracker
<https://bugs.python.org/issue46042>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue46042] Error range of "duplicate argument" SyntaxErrors is too big
New submission from Carl Friedrich Bolz-Tereick : The error range for the "duplicate argument in function definition" SyntaxError is too large: $ cat x.py def f(a, b, c, d, e, f, g, a): pass $ python x.py File "/home/cfbolz/projects/cpython/x.py", line 1 def f(a, b, c, d, e, f, g, a): pass ^^^ SyntaxError: duplicate argument 'a' in function definition I would expect only the second 'a' to be underlined. I can try to fix this. -- messages: 408248 nosy: Carl.Friedrich.Bolz, pablogsal priority: normal severity: normal status: open title: Error range of "duplicate argument" SyntaxErrors is too big ___ Python tracker <https://bugs.python.org/issue46042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37971] Wrong trace with multiple decorators (linenumber wrong in frame)
Change by Carl Friedrich Bolz-Tereick : -- pull_requests: +28252 stage: -> patch review pull_request: https://github.com/python/cpython/pull/30027 ___ Python tracker <https://bugs.python.org/issue37971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37971] Wrong trace with multiple decorators (linenumber wrong in frame)
Carl Friedrich Bolz-Tereick added the comment: I ran into this problem in PyPy today, preparing a patch for CPython too (without looking at the old one). -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue37971> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45859] test_collections has a wrong test in case _itemgetter is not available
Change by Carl Friedrich Bolz-Tereick : -- keywords: +patch pull_requests: +27929 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29691 ___ Python tracker <https://bugs.python.org/issue45859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45859] test_collections has a wrong test in case _itemgetter is not available
New submission from Carl Friedrich Bolz-Tereick : test_field_descriptor in test_collections tries to pickle the descriptors of a namedtuple's fields, which is _collections._itemgetter on CPython. However, on PyPy that class doesn't exist. The code in collections deals fine with that fact, but the above-mentioned test does not make sense in that situation, since you can't pickle properties. To test this behaviour, you can replace "from _collections import _tuplegetter" in collections/__init__.py with raise ImportError and see the test fail on CPython too. -- messages: 406738 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: test_collections has a wrong test in case _itemgetter is not available versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45859> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45781] Deleting __debug__ should be an SyntaxError
Carl Friedrich Bolz-Tereick added the comment: ouch, apologies for not checking that! -- ___ Python tracker <https://bugs.python.org/issue45781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45781] Deleting __debug__ should be an SyntaxError
New submission from Carl Friedrich Bolz-Tereick : Right now, deleting __debug__ is not prevented: >>> def f(): ... del __debug__ ... Of course actually executing it doesn't work: >>> del __debug__ Traceback (most recent call last): File "", line 1, in NameError: name '__debug__' is not defined Compare with assigning to __debug__: >>> def f(): ... __debug__ = 1 ... File "", line 2 SyntaxError: cannot assign to __debug__ -- messages: 406149 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: Deleting __debug__ should be an SyntaxError ___ Python tracker <https://bugs.python.org/issue45781> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45764] Parse error improvement forgetting ( after def
Change by Carl Friedrich Bolz-Tereick : -- keywords: +patch pull_requests: +27735 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29484 ___ Python tracker <https://bugs.python.org/issue45764> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45764] Parse error improvement forgetting ( after def
New submission from Carl Friedrich Bolz-Tereick :
Something I see beginners make occasionally when defining functions without
arguments is this:
def f:
...
Right now it just gives an "invalid syntax", would be nice to get an "expected
'('".
I will try to give this a go! Should be a matter of making the '(' token an
expected one.
--
messages: 406010
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: Parse error improvement forgetting ( after def
___
Python tracker
<https://bugs.python.org/issue45764>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45727] Parse error when missing commas is inconsistent
New submission from Carl Friedrich Bolz-Tereick : I found following inconsistency in the error message when there's a missing comma (it behaves that way both on main and 3.10). Here's what happens with numbers, as expected: Python 3.11.0a1+ (heads/main:32f55d1a5d, Nov 5 2021, 13:18:52) [GCC 11.2.0] on linux Type "help", "copyright", "credits" or "license" for more information. >>> 1 2 3 4 File "", line 1 1 2 3 4 ^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? But with names the error is further right in the lines: >>> a b c d File "", line 1 a b c d ^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? >>> a b c d e f g File "", line 1 a b c d e f g ^^^ SyntaxError: invalid syntax. Perhaps you forgot a comma? That looks potentially quite confusing to me? (I don't know if these nit-picky parsing issues are too annoying, if they are please tell me to stop filing them). -- messages: 405792 nosy: Carl.Friedrich.Bolz, pablogsal priority: normal severity: normal status: open title: Parse error when missing commas is inconsistent versions: Python 3.11 ___ Python tracker <https://bugs.python.org/issue45727> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45716] Confusing parsing error message when trying to use True as keyword argument
New submission from Carl Friedrich Bolz-Tereick : A bit of a nitpick, but the following SyntaxError message is a bit confusing: >>> f(True=1) File "", line 1 f(True=1) ^ SyntaxError: expression cannot contain assignment, perhaps you meant "=="? The problem with that line is not that it contains an assignment, it's almost a valid keyword argument after all. The problem is that the name of the keyword is True, which is no longer a name you can assign to. It would be better to produce the same error as with __debug__: >>> f(__debug__=1) File "", line 1 SyntaxError: cannot assign to __debug__ The latter error message is however produced by the compiler, not the parser I think? -- messages: 405741 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: Confusing parsing error message when trying to use True as keyword argument ___ Python tracker <https://bugs.python.org/issue45716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45624] test_graphlib.py depends on iteration order of sets
Change by Carl Friedrich Bolz-Tereick : -- keywords: +patch pull_requests: +27496 stage: -> patch review pull_request: https://github.com/python/cpython/pull/29233 ___ Python tracker <https://bugs.python.org/issue45624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45624] test_graphlib.py depends on iteration order of sets
Carl Friedrich Bolz-Tereick added the comment: here's the traceback running on pypy3.9-alpha: == FAIL: test_simple_cases (test.test_graphlib.TestTopologicalSort) -- Traceback (most recent call last): File "/home/cfbolz/projects/small-commits-pypy/lib-python/3/test/test_graphlib.py", line 39, in test_simple_cases [(3, 5, 7), (11, 8), (2, 10, 9)], File "/home/cfbolz/projects/small-commits-pypy/lib-python/3/test/test_graphlib.py", line 19, in _test_graph self.assertEqual(list(static_order_with_groups(ts)), list(expected)) AssertionError: Lists differ: [(3, 7, 5), (8, 11), (2, 9, 10)] != [(3, 5, 7), (11, 8), (2, 10, 9)] First differing element 0: (3, 7, 5) (3, 5, 7) - [(3, 7, 5), (8, 11), (2, 9, 10)] + [(3, 5, 7), (11, 8), (2, 10, 9)] -- ___ Python tracker <https://bugs.python.org/issue45624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45624] test_graphlib.py depends on iteration order of sets
New submission from Carl Friedrich Bolz-Tereick : test_graphlib fails on PyPy because it depends on the iteration order of sets. Will open a PR soon. -- messages: 405084 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: test_graphlib.py depends on iteration order of sets ___ Python tracker <https://bugs.python.org/issue45624> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30570] issubclass segfaults on objects with weird __getattr__
Carl Friedrich Bolz-Tereick added the comment: PyPy raises a RecursionError here, which sounds like an ok outcome. So simply checking for the recursion would also be a way of fixing this... -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue30570> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45417] Enum creation non-linear in the number of values
Carl Friedrich Bolz-Tereick added the comment: I fixed the reliance of set being insertion ordered in pypy and opened a pull request. -- ___ Python tracker <https://bugs.python.org/issue45417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue45417] Enum creation non-linear in the number of values
Change by Carl Friedrich Bolz-Tereick : -- nosy: +Carl.Friedrich.Bolz nosy_count: 6.0 -> 7.0 pull_requests: +27198 stage: -> patch review pull_request: https://github.com/python/cpython/pull/28907 ___ Python tracker <https://bugs.python.org/issue45417> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34561] Replace list sorting merge_collapse()?
Carl Friedrich Bolz-Tereick added the comment: Thanks for your work Tim, just adapted the changes to PyPy's Timsort, using bits of runstack.py! -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue34561> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue25130] Make tests more PyPy compatible
Change by Carl Friedrich Bolz-Tereick : -- nosy: +Carl.Friedrich.Bolz nosy_count: 6.0 -> 7.0 pull_requests: +26460 pull_request: https://github.com/python/cpython/pull/28002 ___ Python tracker <https://bugs.python.org/issue25130> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43907] pickle.py bytearray memoization bug with protocol 5
Change by Carl Friedrich Bolz-Tereick : -- keywords: +patch pull_requests: +24221 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25501 ___ Python tracker <https://bugs.python.org/issue43907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43907] pickle.py bytearray memoization bug with protocol 5
New submission from Carl Friedrich Bolz-Tereick : The new codepath for the BYTEARRAY8 bytecode is missing memoization: >>> import pickletools, pickle >>> b = (bytearray(b"abc"), ) * 2 >>> b1, b2 = pickle.loads(pickle.dumps(b, 5)) # C version >>> b1 is b2 True (bytearray(b'abc'), bytearray(b'abc')) >>> b1, b2 = pickle.loads(pickle._dumps(b, 5)) # python version >>> b1 is b2 # :-( False Found it because PyPy is using pickle.py with no C implementation. I'm preparing a patch. -- messages: 391537 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: pickle.py bytearray memoization bug with protocol 5 ___ Python tracker <https://bugs.python.org/issue43907> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Carl Friedrich Bolz-Tereick added the comment: @shreyanavigyan This is a bit off-topic, but it's called "short-circuiting", described here: https://docs.python.org/3/library/stdtypes.html#boolean-operations-and-or-not (or/and aren't really "operators", like +/- etc, they cannot be overridden, they evaluate their components lazily and are therefore almost control flow) -- ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43833] Unexpected Parsing of Numeric Literals Concatenated with Boolean Operators
Carl Friedrich Bolz-Tereick added the comment: It's not just about keywords. Eg '1x' tokenizes too but then produces a syntax error in the parser. Keywords are only special in that they can be used to write syntactically meaningful things with these concatenated numbers. -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue43833> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
Carl Friedrich Bolz-Tereick added the comment: yes, that sounds fair. In PyPy we improve things occasionally if somebody feels like working on it, but in general competing against GMP is a fools errand. -- ___ Python tracker <https://bugs.python.org/issue3451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3451] Asymptotically faster divmod and str(long)
Carl Friedrich Bolz-Tereick added the comment: FWIW, we have implemented a faster algorithm for divmod for big numbers using Mark's fast_div.py in PyPy. In particular, this speeds up str(long) for large numbers significantly (eg calling str on the result of math.factorial(2**17) is now 15x faster than CPython ;-)). -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue3451> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43753] [C API] Add Py_Is(x, y) and Py_IsNone(x) functions
Carl Friedrich Bolz-Tereick added the comment: Just chiming in to say that for PyPy this API would be extremely useful, because PyPy's "is" is not implementable with a pointer comparison on the C level (due to unboxing we need to compare integers, floats, etc by value). Right now, C extension code that compares pointers is subtly broken and cannot be fixed by us. -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue43753> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41972] bytes.find consistently hangs in a particular scenario
Carl Friedrich Bolz-Tereick added the comment: > BTW, this initialization in the FASTSEARCH code appears to me to be a > mistake: >skip = mlast - 1; Thanks for pointing that out Tim! Turns out PyPy had copied that mindlessly and I just fixed it. (I'm also generally following along with this issue, I plan to implement the two-way algorithm for PyPy as well, once you all have decided on a heuristic. We are occasionally in a slightly easier situation, because for constant-enough needles we can have the JIT do the pre-work on the needle during code generation.) -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue41972> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43154] code.InteractiveConsole can crash if sys.excepthook is broken
New submission from Carl Friedrich Bolz-Tereick : When using code.InteractiveConsole to implement a Python shell (like PyPy is doing), having a broken sys.excepthook set can crash the console (see attached terminal log). Instead, it should catch errors and report then ignore them (using sys.unraisablehook I would think, but right now it's not that simple to call unraisablehook from python code). Related to https://bugs.python.org/issue43148 -- files: crash.log messages: 386593 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: code.InteractiveConsole can crash if sys.excepthook is broken Added file: https://bugs.python.org/file49797/crash.log ___ Python tracker <https://bugs.python.org/issue43154> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43148] Call sys.unraisablehook in the REPL when sys.excepthook is broken
Change by Carl Friedrich Bolz-Tereick : -- nosy: +Carl.Friedrich.Bolz ___ Python tracker <https://bugs.python.org/issue43148> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38197] Meaning of tracebacklimit differs between sys.tracebacklimit and traceback module
Carl Friedrich Bolz-Tereick added the comment: It's still inconsistent between the two ways to get a traceback, and the inconsistency is not documented. -- ___ Python tracker <https://bugs.python.org/issue38197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39486] bug in %-formatting in Python, related to escaped %-characters
Carl Friedrich Bolz-Tereick added the comment: Ok, that means it's intentional. I still think it's missing a documentation change and consistent error messages. -- ___ Python tracker <https://bugs.python.org/issue39486> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39486] bug in %-formatting in Python, related to escaped %-characters
New submission from Carl Friedrich Bolz-Tereick :
The following behaviour of %-formatting changed between Python3.6 and
Python3.7, and is in my opinion a bug that was introduced.
So far, it has been possible to add conversion flags to a conversion specifier
in %-formatting, even if the conversion is '%' (meaning a literal % is emitted
and no argument consumed).
Eg this works in Python3.6:
>>>> "%+%abc% %" % ()
'%abc%'
The conversion flags '+' and ' ' are ignored.
Was it discussed and documented anywhere that this is now an error? Because
Python3.7 has the following strange behaviour instead:
>>> "%+%abc% %" % ()
Traceback (most recent call last):
File "", line 1, in
TypeError: not enough arguments for format string
That error message is just confusing, because the amount of arguments is not
the problem here. If I pass a dict (thus making the number of arguments
irrelevant) I get instead:
>>> "%+%abc% %" % {}
Traceback (most recent call last):
File "", line 1, in
ValueError: unsupported format character '%' (0x25) at index 2
(also a confusing message, because '%' is a perfectly fine format character)
In my opinion this behaviour should either be reverted to how Python3.6 worked,
or the new restrictions should be documented and the error messages improved.
--
messages: 360965
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: bug in %-formatting in Python, related to escaped %-characters
versions: Python 3.7
___
Python tracker
<https://bugs.python.org/issue39486>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39485] Bug in mock running on PyPy3
Change by Carl Friedrich Bolz-Tereick : -- keywords: +patch pull_requests: +17629 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18252 ___ Python tracker <https://bugs.python.org/issue39485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39485] Bug in mock running on PyPy3
New submission from Carl Friedrich Bolz-Tereick :
One of the new-in-3.8 tests for unittest.mock,
test_spec_has_descriptor_returning_function, is failing on PyPy. This exposes a
bug in unittest.mock. The bug is most noticeable on PyPy, where it can be
triggered by simply writing a slightly weird descriptor (CrazyDescriptor in the
test). Getting it to trigger on CPython would be possible too, by implementing
the same descriptor in C, but I did not actually do that.
The relevant part of the test looks like this:
from unittest.mock import create_autospec
class CrazyDescriptor(object):
def __get__(self, obj, type_):
if obj is None:
return lambda x: None
class MyClass(object):
some_attr = CrazyDescriptor()
mock = create_autospec(MyClass)
mock.some_attr(1)
On CPython this just works, on PyPy it fails with:
Traceback (most recent call last):
File "x.py", line 13, in
mock.some_attr(1)
File
"/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/unittest/mock.py",
line 938, in __call__
_mock_self._mock_check_sig(*args, **kwargs)
File
"/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/unittest/mock.py",
line 101, in checksig
sig.bind(*args, **kwargs)
File
"/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/inspect.py", line
3034, in bind
return args[0]._bind(args[1:], kwargs)
File
"/home/cfbolz/bin/.pyenv/versions/pypy3.6-7.2.0/lib-python/3/inspect.py", line
2955, in _bind
raise TypeError('too many positional arguments') from None
TypeError: too many positional arguments
The reason for this problem is that mock deduced that MyClass.some_attr is a
method on PyPy. Since mock thinks the lambda returned by the descriptor is a
method, it adds self as an argument, which leads to the TypeError.
Checking whether something is a method is done by _must_skip in mock.py. The
relevant condition is this one:
elif isinstance(getattr(result, '__get__', None), MethodWrapperTypes):
# Normal method => skip if looked up on type
# (if looked up on instance, self is already skipped)
return is_type
else:
return False
MethodWrapperTypes is defined as:
MethodWrapperTypes = (
type(ANY.__eq__.__get__),
)
which is just types.MethodType on PyPy, because there is no such thing as a
method wrapper (the builtin types look pretty much like python-defined types in
PyPy).
On PyPy the condition isinstance(getattr...) is thus True for all descriptors!
so as soon as result has a __get__, it counts as a method, even in the above
case where it's a custom descriptor.
Now even on CPython the condition makes no sense to me. It would be True for a
C-defined version of CrazyDescriptor, it's just not a good way to check whether
result is a method.
I would propose to replace the condition with the much more straightforward
check:
elif isinstance(result, FunctionTypes):
...
something is a method if it's a function on the class. Doing that change makes
the test pass on PyPy, and doesn't introduce any test failures on CPython
either.
Will open a pull request.
--
messages: 360961
nosy: Carl.Friedrich.Bolz, cjw296
priority: normal
severity: normal
status: open
title: Bug in mock running on PyPy3
___
Python tracker
<https://bugs.python.org/issue39485>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39220] constant folding affects annotations despite 'from __future__ import annotations'
Carl Friedrich Bolz-Tereick added the comment: I don't have a particularly deep opinion on what should be done, just a bit of weirdness I hit upon while implementing the PEP in PyPy. fwiw, we implement it as an AST transformer that the compiler runs before running the optimizer to make sure that the AST optimizations don't get applied to annotions. The transformer replaces all annotations with a Constant ast node, containing the unparsed string. -- ___ Python tracker <https://bugs.python.org/issue39220> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39220] constant folding affects annotations despite 'from __future__ import annotations'
New submission from Carl Friedrich Bolz-Tereick :
PEP 563 interacts in weird ways with constant folding. running the following
code:
```
from __future__ import annotations
def f(a: 5 + 7) -> a ** 39:
return 12
print(f.__annotations__)
```
I would expect this output:
```
{'a': '5 + 7', 'return': 'a ** 39'}
```
But I get:
```
{'a': '12', 'return': 'a ** 39'}
```
--
components: Interpreter Core
files: x.py
messages: 359341
nosy: Carl.Friedrich.Bolz
priority: normal
severity: normal
status: open
title: constant folding affects annotations despite 'from __future__ import
annotations'
versions: Python 3.7
Added file: https://bugs.python.org/file48827/x.py
___
Python tracker
<https://bugs.python.org/issue39220>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue38197] Meaning of tracebacklimit differs between sys.tracebacklimit and traceback module
New submission from Carl Friedrich Bolz-Tereick : The meaning of sys.tracebacklimit seems to be different than the meaning of the various limit parameters in the traceback module. One shows the top n stack frames, the other the bottom n. Is this intentional, and if yes, is that difference documented somewhere? (it came up because PyPy just uses the traceback module and has no equivalent of PyTraceBack_Print). See the attached script to understand the problem. The script formats the same exception twice, once with the traceback module, once by the interpreter. I would have expected them to look the same for all limits, but instead: $ ./python /tmp/x.py 3 limit 3 from traceback module: Traceback (most recent call last): File "/tmp/x.py", line 19, in main() File "/tmp/x.py", line 16, in main x3() File "/tmp/x.py", line 14, in x3 x2() ZeroDivisionError: division by zero from interpreter: Traceback (most recent call last): File "/tmp/x.py", line 14, in x3 x2() File "/tmp/x.py", line 12, in x2 x1() File "/tmp/x.py", line 10, in x1 1 / 0 ZeroDivisionError: division by zero -- files: x.py messages: 352628 nosy: Carl.Friedrich.Bolz priority: normal severity: normal status: open title: Meaning of tracebacklimit differs between sys.tracebacklimit and traceback module versions: Python 3.7 Added file: https://bugs.python.org/file48610/x.py ___ Python tracker <https://bugs.python.org/issue38197> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s
Change by Carl Friedrich Bolz-Tereick : -- pull_requests: +14466 pull_request: https://github.com/python/cpython/pull/14659 ___ Python tracker <https://bugs.python.org/issue18374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s
Change by Carl Friedrich Bolz-Tereick : -- pull_requests: +14423 stage: needs patch -> patch review pull_request: https://github.com/python/cpython/pull/14607 ___ Python tracker <https://bugs.python.org/issue18374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18374] ast.parse gives wrong position (col_offset) for some BinOp-s
Carl Friedrich Bolz-Tereick added the comment: I think the attached patch fixes the problem. Will create a pull request soon. -- versions: +Python 3.5 -Python 3.7, Python 3.8, Python 3.9 Added file: https://bugs.python.org/file48458/binop-offset.patch ___ Python tracker <https://bugs.python.org/issue18374> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
