[issue46644] typing: remove callable() check from typing._type_check

Jelle Zijlstra added the comment: Some tests are failing on main, probably due to a race. PR incoming. -- resolution: fixed -> status: closed -> open ___ Python tracker ___ _

[issue46644] typing: remove callable() check from typing._type_check

Change by Jelle Zijlstra : -- pull_requests: +29930 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/31833 ___ Python tracker ___ __

[issue46644] typing: remove callable() check from typing._type_check

Jelle Zijlstra added the comment: New changeset 75174371e6cac935b598a68c1113f6db1e0d6ed8 by Jelle Zijlstra in branch 'main': bpo-46644: Fix test_typing test broken by GH-31151 due to a merge race (GH-31833) https://github.com/python/cpython/commit/75174371e6cac935b598a68c1113f6db1e0d6ed8 -

[issue46644] typing: remove callable() check from typing._type_check

Change by Jelle Zijlstra : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ __

[issue2771] Test issue

Change by admin : -- github: 1 -> 18614 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue46990] Surprising list overallocation from .split()

Tim Peters added the comment: Well, that's annoying ;-) In context, the OP was saving a list of 10 million splits. So each overallocation by a single element burned 80 million bytes of RAM. Overallocating by 7 burned 560 million bytes. Which is unusual. Usually a split result is short-lived,

[issue44799] typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar

Jelle Zijlstra added the comment: This is now fixed in main thanks to bpo-46644: ``` >>> get_type_hints(Foo) {'attr': dataclasses.InitVar[int]} ``` We're not backporting that change to the bugfix branches. If we want to fix this issue in 3.10 and 3.9, we'll have to add a `__call__` method to

[issue46642] typing: tested TypeVar instance subclass TypeError is incidental

Jelle Zijlstra added the comment: This still behaves similarly after the bpo-46642 fix: >>> class V(TypeVar("T")): pass ... Traceback (most recent call last): File "", line 1, in File "/Users/jelle/py/cpython/Lib/typing.py", line 906, in __init__ self.__constraints__ = tuple(_type_ch

[issue46991] Specialize list[slice]

New submission from Ken Jin : According to https://github.com/faster-cpython/ideas/blob/main/stats.md#binary_subscr it's the second most common failed specialization. array.array[int] is quite hard to specialize, considering that array.array deals with 13 different item types based on its ini

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

New submission from 김준환 : If use textwrap.dedent with string formatting, may get unintended sentences. For example, a sentence like this: ``` import textwrap def get_something_string(): return textwrap.dedent("""\ test text2 test text3 test text4""") textwrap.deden

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: Sorry, it's an indent , not an intent . -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue31975] Add a default filter for DeprecationWarning in __main__

Change by Kevin Locke : -- nosy: +kevinoid nosy_count: 7.0 -> 8.0 pull_requests: +29931 pull_request: https://github.com/python/cpython/pull/23172 ___ Python tracker ___ __

[issue44799] typing.get_type_hints() raises TypeError for a variable annotated by dataclasses.InitVar

Eric V. Smith added the comment: I agree it's not worth fixing in 3.9 and 3.10. -- ___ Python tracker ___ ___ Python-bugs-list mail

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What is the flag you mention? What would it do? This sounds like a new feature, which can only go in to 3.11. -- nosy: +eric.smith ___ Python tracker ___

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: If it's only for version 3.11, what do you think of the default behavior of the dedent method being changed? The method description says: > Remove any common leading whitespace from every line in `text`. ``` def get_something_string(): return textwrap.dedent("""\

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What would the presence of "<<" do? You haven't described your proposal. -- ___ Python tracker ___ ___

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: "<<" This marks that line. ignore it -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: What would x be equal to here: def get_something_string(): return textwrap.dedent("""\ test text2 test text3 test text4""") x = f"""\ test text1 {get_something_string()} test text5 test text6""" ? With 3.10

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: No, I know `textwrap.dedent` as a convenience function used for code readability. But to have the result I want, I currently need to do something like this: If it's a method inside a class, it's even more ugly. Class A: def get_something_string(): return t

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: Sorry, Can't edit comments Please see the code example below ``` Class A: def get_something_string(): return textwrap.dedent("""\ test text2 test text3 test text4""") textwrap.dedent(f"""\ test text1 {A.get_something_string()} test te

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

Eric V. Smith added the comment: I’m sorry, I don’t understand your proposal. Please answer my question about what “x” would be equal to under your proposed change. -- ___ Python tracker

[issue46992] If use textwrap.dedent with string formatting, may get unintended sentences.

김준환 added the comment: x does not change. sorry. I also haven't figured out the implementation in my head yet. I want to provide some functionality to provide consistent indentation while using formatting . For example """ test {multi_line_text} """.format(multi_line_text, consistent

<    1   2