[issue40397] Refactor typing._GenericAlias
Jelle Zijlstra added the comment: Looks like there's nothing left to do here. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue40397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37923] Combining typing.get_type_hints and inspect.signature
Jelle Zijlstra added the comment: As of Python 3.10, thanks to Larry Hastings inspect.signature will have a new eval_str= parameter that lets you evaluate string annotations. This isn't quite what you're asking for, though, because typing.get_type_hints does more work than eval_str does. Still, it's similar enough that I'm inclined to close this issue. -- nosy: +Jelle Zijlstra, larry ___ Python tracker <https://bugs.python.org/issue37923> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32752] no information about accessing typing.Generic type arguments
Jelle Zijlstra added the comment: We have typing.get_args() as of 3.8. -- nosy: +Jelle Zijlstra resolution: -> fixed stage: -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue32752> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28556] typing.py upgrades
Jelle Zijlstra added the comment: Looks like this is no longer relevant. -- nosy: +Jelle Zijlstra resolution: -> out of date stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.org/issue28556> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41232] Python `functools.wraps` doesn't deal with defaults correctly
Jelle Zijlstra added the comment: We could add a new argument to `@functools.wraps()` to differentiate between a wrapper with the same signature and one with a different signature. Here's a possible design: * functools.wraps adds a new keyword-only argument signature_changed. It defaults to False for backward compatibility. * If signature_changed is True: * __annotations__ are not copied * __wrapped__ is not set on the wrapping function. Instead, we set a new attribute __wrapped_with_changed_signature__ (that's a pretty terrible name, open to suggestions). This will make inspect.signature not look at the wrapped function. -- ___ Python tracker <https://bugs.python.org/issue41232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41232] Python `functools.wraps` doesn't deal with defaults correctly
Jelle Zijlstra added the comment: That's because inspect.signature by default follows the `.__wrapped__` attribute, so it gives you the signature for the *wrapped* function. That behavior is occasionally problematic (I ran into it in the context of https://github.com/quora/pyanalyze/issues/82), but I don't think it can be safely changed. -- ___ Python tracker <https://bugs.python.org/issue41232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41232] Python `functools.wraps` doesn't deal with defaults correctly
Jelle Zijlstra added the comment: We should not do this, because the wrapping function may have different defaults, and updating __defaults__ would make it use the wrapped function's defaults. Example: >>> def f(y=1): ... print(y) ... >>> f() 1 >>> f.__defaults__ (1,) >>> f.__defaults__ = () >>> f() Traceback (most recent call last): File "", line 1, in TypeError: f() missing 1 required positional argument: 'y' -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue41232> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44006] symbol documentation still exists
Jelle Zijlstra added the comment: You're right, the file doesn't exist on master. I guess there must be some sort of caching. For what it's worth, I found it by going to the module documentation on an earlier version and using the dropdown to navigate to 3.10. If you go to the dataclasses docs and select a version where it doesn't exist yet (e.g., 3.6), it redirects to https://docs.python.org/3.6/. That feels like the right behavior here too. -- ___ Python tracker <https://bugs.python.org/issue44006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44006] symbol documentation still exists
New submission from Jelle Zijlstra : symbol is being removed in 3.10, but https://docs.python.org/3.10/library/symbol.html still exists and claims it will be removed in "future versions". It was removed in bpo-40939 / GH-21005. -- assignee: docs@python components: Documentation messages: 392653 nosy: Jelle Zijlstra, docs@python, lys.nikolaou priority: normal severity: normal status: open title: symbol documentation still exists versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue44006> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44000] Current PY_VERSION 3.10.0a7+ does not conform to PEP 440
Change by Jelle Zijlstra : -- nosy: +lukasz.langa, ned.deily, pablogsal ___ Python tracker <https://bugs.python.org/issue44000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44000] Current PY_VERSION 3.10.0a7+ does not conform to PEP 440
Jelle Zijlstra added the comment: PEP 440 applies to Python packages, not to CPython itself. The "+" convention has been used in CPython for a long time, and changing it without a strong justification seems risky. -- nosy: +Jelle Zijlstra -lukasz.langa, ned.deily, pablogsal ___ Python tracker <https://bugs.python.org/issue44000> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue44001] typing.Literal: args must be hashable, not immutable
New submission from Jelle Zijlstra : After the changes from bpo-42345, the Literal documentation claims that "Literal objects will now raise a TypeError exception during equality comparisons if one of their parameters are not immutable." But in fact it's *unhashable* types that raise an error; mutable but hashable types such as functions or custom objects work fine. I'll submit a PR for this but may wait until GH-25787 is resolved. -- assignee: Jelle Zijlstra components: Documentation messages: 392608 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: typing.Literal: args must be hashable, not immutable versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue44001> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43901] Lazy-create an empty annotations dict in all unannotated user classes and modules
Jelle Zijlstra added the comment: For what it's worth, I checked grep.app and found only one usage of del on __annotations__, in a test suite: https://github.com/go-python/gpython/blob/master/py/tests/function.py#L82. Changing its behavior seems very low risk. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43901> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32891] Add 'Integer' as synonym for 'Integral' in numbers module.
Jelle Zijlstra added the comment: Like Mark I'm opposed to this change. It requires little work in CPython itself, but numbers.Integral has now been a part of the language for many years and the name is used in numerous third-party projects. Forcing all of them to change doesn't seem particularly valuable. "Integer" is probably a better name in a vacuum, but "Integral" isn't actively misleading. ------ nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue32891> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43817] Add inspect.get_annotations()
Jelle Zijlstra added the comment: I agree with Guido that it's better to design inspect.signature to not throw an error for annotations that don't eval() cleanly. I use inspect.signature for getting information about callables (third-party and first-party) in my type checker: https://github.com/quora/pyanalyze/blob/master/pyanalyze/arg_spec.py#L436. In that context, I'd much rather get string annotations that I can process myself later than get an exception if the annotations aren't valid at runtime. In the former case I can still get useful information out of the signature even if I don't know how to process some annotations. For example, I'll still know what parameters exist even if I don't know what their types are. In the latter case, I don't get any useful signature data. -- ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43817] Add typing.get_annotations()
Change by Jelle Zijlstra : -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43817> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43772] Minor repr error in typing.TypeVar.__ror__()
Change by Jelle Zijlstra : -- keywords: +patch nosy: +Jelle Zijlstra nosy_count: 4.0 -> 5.0 pull_requests: +24074 stage: test needed -> patch review pull_request: https://github.com/python/cpython/pull/25339 ___ Python tracker <https://bugs.python.org/issue43772> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43803] ctypes string_at/wstring_at bad argument name
Jelle Zijlstra added the comment: It's a bit worse: the actual name is "ptr", the function docstrings say "addr", and the documentation (https://docs.python.org/3.9/library/ctypes.html#ctypes.string_at) has "address". I'd favor updating them all to say "ptr", because changing the name of the runtime parameter would risk breaking users' code. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43803> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43783] Make ParamSpec.args/kwargs more useful objects
Change by Jelle Zijlstra : -- keywords: +patch pull_requests: +24029 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25298 ___ Python tracker <https://bugs.python.org/issue43783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43783] Make ParamSpec.args/kwargs more useful objects
Change by Jelle Zijlstra : -- assignee: -> Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43783] Make ParamSpec.args/kwargs more useful objects
New submission from Jelle Zijlstra : Currently, typing.ParamSpec.args and ParamSpec.kwargs are just object() instances, which makes them useless for runtime inspection of __annotations__. This type was introduced by PEP 612. Instead, I propose to make them return some special helper object with __origin__ set to the underlying ParamSpec object. I'll work on a PR soon. -- components: Library (Lib) messages: 390583 nosy: Jelle Zijlstra, gvanrossum, levkivskyi priority: normal severity: normal status: open title: Make ParamSpec.args/kwargs more useful objects versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43783> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37804] Remove Thread.isAlive in Python 3.9
Change by Jelle Zijlstra : -- pull_requests: +23916 pull_request: https://github.com/python/cpython/pull/25174 ___ Python tracker <https://bugs.python.org/issue37804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43723] Deprecate camelCase aliases from threading.py
Change by Jelle Zijlstra : -- keywords: +patch pull_requests: +23915 stage: -> patch review pull_request: https://github.com/python/cpython/pull/25174 ___ Python tracker <https://bugs.python.org/issue43723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43723] Deprecate camelCase aliases from threading.py
New submission from Jelle Zijlstra : Followup from issue37804: deprecate the remaining camelCase aliases, such as threading.currentThread. PR coming soon. -- assignee: Jelle Zijlstra components: Library (Lib) messages: 390165 nosy: Jelle Zijlstra, pitrou priority: normal severity: normal status: open title: Deprecate camelCase aliases from threading.py versions: Python 3.10 ___ Python tracker <https://bugs.python.org/issue43723> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37804] Remove Thread.isAlive in Python 3.9
Jelle Zijlstra added the comment: Sure, I can submit a PR. While we're at it, we should probably also deprecate the setter/getter methods that you mention. Here's what I propose doing: - On 3.10 (or 3.11 if it's too late for 3.10), make getName and friends throw a DeprecationWarning, scheduling them for removal in 3.12 or 3.13 - On 3.8 and lower, update the docs to explicitly call out the names of the deprecated methods - On 3.9 and higher, update the docs similarly but mention that threading.isAlive was already removed If there's no objection, I'll open separate issues and PRs for these in a few days. -- ___ Python tracker <https://bugs.python.org/issue37804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37804] Remove Thread.isAlive in Python 3.9
Jelle Zijlstra added the comment: The threading documentation for 3.9 still claims "While they are not listed below, the camelCase names used for some methods and functions in this module in the Python 2.x series are still supported by this module." It would be better to mention when isAlive was removed. The method is still used in some major libraries, like NLTK (https://github.com/nltk/nltk/blob/637af5380d6071517a5f0d224649e5c3560b5f91/nltk/inference/api.py#L536). Documenting the removal clearly in the threading docs would make it easier for developers to upgrade. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue37804> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue43616] random.shuffle() crashes with Unhandled exception
Jelle Zijlstra added the comment: Could you post code that fully reproduces the problem? I suspect the root cause for the bug is in lxml (a third-party library), not in CPython itself. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue43616> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40826] Segfaults on io.FileIO(0).name in 3.9
New submission from Jelle Zijlstra : $ gdb ./python ... (gdb) r ... Python 3.9.0b1 (tags/v3.9.0b1:97fe9cfd9f8, May 30 2020, 05:26:48) ... >>> import io >>> io.FileIO(0).name 0 >>> Program received signal SIGSEGV, Segmentation fault. _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:100 100 return tstate->interp; (gdb) bt #0 _PyInterpreterState_GET () at ./Include/internal/pycore_pystate.h:100 #1 PyOS_InterruptOccurred () at ./Modules/signalmodule.c:1785 #2 0x00673905 in my_fgets (buf=buf@entry=0xa40780 "8LJ\367\377\177", len=len@entry=100, fp=fp@entry=0x774a48e0 <_IO_2_1_stdin_>) at Parser/myreadline.c:87 #3 0x0067397b in PyOS_StdioReadline (sys_stdin=sys_stdin@entry=0x774a48e0 <_IO_2_1_stdin_>, sys_stdout=sys_stdout@entry=0x774a5620 <_IO_2_1_stdout_>, prompt=prompt@entry=0x76f8d8e0 ">>> ") at Parser/myreadline.c:269 #4 0x00673b4f in PyOS_Readline (sys_stdin=0x774a48e0 <_IO_2_1_stdin_>, sys_stdout=0x774a5620 <_IO_2_1_stdout_>, prompt=0x76f8d8e0 ">>> ") at Parser/myreadline.c:355 #5 0x005d90d9 in tok_nextc (tok=0xa3fd30) at Parser/tokenizer.c:856 #6 0x005dad02 in tok_get (tok=tok@entry=0xa3fd30, p_start=p_start@entry=0x7fffd508, p_end=p_end@entry=0x7fffd510) at Parser/tokenizer.c:1194 #7 0x005dcb69 in PyTokenizer_Get (tok=0xa3fd30, p_start=p_start@entry=0x7fffd508, p_end=p_end@entry=0x7fffd510) at Parser/tokenizer.c:1842 #8 0x00653c73 in _PyPegen_fill_token (p=0x76f8f540) at Parser/pegen/pegen.c:551 #9 0x00670355 in statement_newline_rule (p=0x76f8f540) at Parser/pegen/parse.c:1143 #10 interactive_rule (p=0x76f8f540) at Parser/pegen/parse.c:725 #11 _PyPegen_parse (p=p@entry=0x76f8f540) at Parser/pegen/parse.c:19388 #12 0x00654b32 in _PyPegen_run_parser (p=0x76f8f540) at Parser/pegen/pegen.c:1037 #13 0x00654e4c in _PyPegen_run_parser_from_file_pointer (fp=fp@entry=0x70f74a48e0, start_rule=start_rule@entry=80, filename_ob=filename_ob@entry=0x76f84eb0, enc=enc@entry=0x7704ec60 "utf-8", ps1=ps1@entry=0x76f8d8e0 ">>> ", ps2=ps2@entry=0x9000d0 , flags=0x7fffd7b8, errcode=0x7fffd6e4, arena=0x76ff6b30) at Parser/pegen/pegen.c:1097 #14 0x005d6bea in PyPegen_ASTFromFileObject (fp=0x70f74a48e0, fp@entry=0x774a48e0 <_IO_2_1_stdin_>, filename_ob=filename_ob@entry=0x76f84eb0, mode=80, mode@entry=256, enc=enc@entry=0x7704ec60 "utf-8", ps1=ps1@entry=0x76f8d8e0 ">>> ", ps2=0x9000d0 , ps2@entry=0x76f8dbe0 "... ", flags=, errcode=, arena=) at Parser/pegen/peg_api.c:52 #15 0x005460d9 in PyRun_InteractiveOneObjectEx (fp=fp@entry=0x774a48e0 <_IO_2_1_stdin_>, filename=filename@entry=0x76f84eb0, flags=flags@entry=0x7fffd7b8) at Python/pythonrun.c:243 #16 0x0054631e in PyRun_InteractiveLoopFlags (fp=fp@entry=0x774a48e0 <_IO_2_1_stdin_>, filename_str=filename_str@entry=0x673e32 "", flags=flags@entry=0x7fffd7b8) at Python/pythonrun.c:122 #17 0x00546d4c in PyRun_AnyFileExFlags (fp=0x774a48e0 <_IO_2_1_stdin_>, filename=0x673e32 "", closeit=0, flags=0x7fffd7b8) at Python/pythonrun.c:81 #18 0x00429fb7 in pymain_run_stdin (cf=0x7fffd7b8, config=0x9bd800) at Modules/main.c:467 #19 pymain_run_python (exitcode=0x7fffd7b0) at Modules/main.c:556 #20 Py_RunMain () at Modules/main.c:632 #21 0x0042a2d6 in pymain_main (args=0x7fffd8a0) at Modules/main.c:662 #22 Py_BytesMain (argc=, argv=) at Modules/main.c:686 #23 0x77100830 in __libc_start_main (main=0x41ef30 , argc=1, argv=0x7fffd9f8, init=, fini=, rtld_fini=, stack_end=0x7fffd9e8) at ../csu/libc-start.c:291 #24 0x00429089 in _start () (gdb) Same happens with Python 3.9.0b1+ (heads/3.9:588efc29c5d, May 30 2020, 14:16:10) (current HEAD of the 3.9 branch). In previous versions of Python this would exit the interpreter but not segfault. -- keywords: 3.9regression messages: 370386 nosy: Jelle Zijlstra, benjamin.peterson, stutzbach priority: normal severity: normal status: open title: Segfaults on io.FileIO(0).name in 3.9 versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue40826> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40397] Refactor typing._GenericAlias
Jelle Zijlstra added the comment: Thanks Serhyi! I can confirm that the issue I posted is fixed. -- priority: release blocker -> normal ___ Python tracker <https://bugs.python.org/issue40397> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40397] Refactor typing._GenericAlias
Jelle Zijlstra added the comment:
The most recent change here caused a regression. The following file:
```
from typing import Generic, TypeVar, Union
class CannotTransform(Exception): pass
T = TypeVar("T")
E = TypeVar("E", bound=Exception)
class Ok(Generic[T]): pass
class Err(Generic[E]): pass
Result = Union[Ok[T], Err[E]]
TResult = Result[T, CannotTransform]
TMatchResult = TResult[int]
```
Now fails with:
```
Traceback (most recent call last):
File "/Users/jzijlstra-mpbt/py/cpython/Lib/../../black/black.py", line 22, in
TMatchResult = TResult[int]
File "/Users/jzijlstra-mpbt/py/cpython/Lib/typing.py", line 244, in inner
return func(*args, **kwds)
File "/Users/jzijlstra-mpbt/py/cpython/Lib/typing.py", line 704, in
__getitem__
arg = arg[subargs]
File "/Users/jzijlstra-mpbt/py/cpython/Lib/typing.py", line 244, in inner
return func(*args, **kwds)
File "/Users/jzijlstra-mpbt/py/cpython/Lib/typing.py", line 695, in
__getitem__
_check_generic(self, params)
File "/Users/jzijlstra-mpbt/py/cpython/Lib/typing.py", line 194, in
_check_generic
raise TypeError(f"{cls} is not a generic class")
TypeError: __main__.Err[__main__.CannotTransform] is not a generic class
```
Before commit c1c7d8ead9eb214a6149a43e31a3213c52448877 it was fine. This was
found when we added 3.9-dev to CI for Black
(https://github.com/psf/black/pull/1393).
--
nosy: +Jelle Zijlstra
priority: normal -> release blocker
___
Python tracker
<https://bugs.python.org/issue40397>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37384] Compiling Python 3.7.3 from source and getting all sorts of errors on Debian?
Jelle Zijlstra added the comment: As Ned and Christian hinted, the issue might be related to --enable-optimizations. Have you tried compiling without that flag? -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue37384> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33482] codecs.StreamRecoder.writelines is broken
Change by Jelle Zijlstra : -- pull_requests: +13417 ___ Python tracker <https://bugs.python.org/issue33482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33482] codecs.StreamRecoder.writelines is broken
Change by Jelle Zijlstra : -- pull_requests: +13416 stage: test needed -> patch review ___ Python tracker <https://bugs.python.org/issue33482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34648] Confirm the types of parameters of traceback.format_list and traceback.StackSummary.from_list post-3.5
Jelle Zijlstra added the comment: > How people can get Iterable[FrameSummary] as an input and pass it to > format_list()? If I want to format a traceback, but omit traceback lines that refer to a particular module (for example, code for a coroutine runner), I could write `format_list(filter(lambda fs: 'asyncio' not in fs.filename, extract_stack())`. I would also favor broadening the documented argument type for `format_list()` to say it accepts an iterable of FrameSummaries. No code change is necessary and it makes the code more flexible. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue34648> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] aiter() and anext() built-in functions
Jelle Zijlstra added the comment: Do these really need to be builtins? They seem too specialized to be widely useful; I've personally never needed them in any async code I've written. It would make more sense to me to put them in a module like operators. -- nosy: +Jelle Zijlstra ___ Python tracker <https://bugs.python.org/issue31861> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33519] Should MutableSequence provide .copy()?
Change by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- keywords: +patch pull_requests: +6623 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33519] Should MutableSequence provide .copy()?
Jelle Zijlstra <jelle.zijls...@gmail.com> added the comment: Makes sense. I can provide a patch to the docs. -- ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33519] Should MutableSequence provide .copy()?
New submission from Jelle Zijlstra <jelle.zijls...@gmail.com>: https://docs.python.org/3.7/library/stdtypes.html#mutable-sequence-types lists .copy() among the methods provided by mutable sequences. However, MutableSequence does not actually define .copy(): https://github.com/python/cpython/blob/master/Lib/_collections_abc.py#L945. Should we add .copy() to the ABC or remove the promise that all mutable sequences implement .copy()? -- components: Library (Lib) messages: 316664 nosy: Jelle Zijlstra, rhettinger, stutzbach priority: normal severity: normal status: open title: Should MutableSequence provide .copy()? versions: Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33519> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33482] codecs.StreamRecoder.writelines is broken
Change by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- keywords: +patch pull_requests: +6465 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33482] codecs.StreamRecoder.writelines is broken
New submission from Jelle Zijlstra <jelle.zijls...@gmail.com>: codecs.StreamRecoder.writelines is implemented as: def writelines(self, list): data = ''.join(list) data, bytesdecoded = self.decode(data, self.errors) return self.writer.write(data) It can't take a list of bytes because then the ''.join throws an error, and it can't take a list of str because self.decode takes bytes. It looks like bytes are intended (self.write takes bytes), so I'll submit a simple PR to fix this. -- messages: 316465 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: codecs.StreamRecoder.writelines is broken versions: Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue33482> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30406] async and await should be keywords in 3.7
Change by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +5900 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue30406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31965] Incorrect documentation for multiprocessing.connection.{Client, Listener}
New submission from Jelle Zijlstra <jelle.zijls...@gmail.com>:
https://docs.python.org/3/library/multiprocessing.html#multiprocessing.connection.Client
claims that there is an "authenticate" argument, but it does not exist in the
implementation
(https://github.com/python/cpython/blob/master/Lib/multiprocessing/connection.py#L487).
--
assignee: Jelle Zijlstra
components: Documentation
messages: 305713
nosy: Jelle Zijlstra, davin, pitrou
priority: normal
pull_requests: 4267
severity: normal
status: open
title: Incorrect documentation for multiprocessing.connection.{Client,Listener}
versions: Python 3.7
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python.org/issue31965>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31698] Add REQ_NAME to the node.h API
Change by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- keywords: +patch pull_requests: +3900 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31698] Add REQ_NAME to the node.h API
New submission from Jelle Zijlstra <jelle.zijls...@gmail.com>: See https://github.com/python/cpython/pull/1669#pullrequestreview-67229284 -- assignee: Jelle Zijlstra components: Interpreter Core messages: 303739 nosy: Jelle Zijlstra, yselivanov priority: low severity: normal status: open title: Add REQ_NAME to the node.h API versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue31698> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30984] traceback.print_exc return value documentation
New submission from Jelle Zijlstra: The documentation for traceback.format_tb says "Return a list of “pre-processed” stack trace entries extracted from the traceback object tb. It is useful for alternate formatting of stack traces. The optional limit argument has the same meaning as for print_tb(). A “pre-processed” stack trace entry is a 4-tuple (filename, line number, function name, text) representing the information that is usually printed for a stack trace." However, as of 3.5 it actually returns a StackSummary object, which is a subclass of list and contains FrameSummary objects. FrameSummary objects are not tuples. The documentation is accurate for 3.4 and earlier. I'm surprised this change was made because it seems like a compatibility break, but it's too late to do something about that now. The documentation should be changed to correct the return value and add a "versionchanged: 3.5" note. -- assignee: docs@python components: Documentation messages: 298807 nosy: Jelle Zijlstra, docs@python priority: normal severity: normal status: open title: traceback.print_exc return value documentation versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30984> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Jelle Zijlstra added the comment: Thanks Joe! I adapted your benchmark suite to also run my implementation. See https://github.com/JelleZijlstra/cnamedtuple/commit/61b6fbf4de37f8131ab43c619593327004974e52 for the code and results. The results are consistent with what we've seen before. Joe's cnamedtuple is about 40x faster for class creation than the current implementation, and my PR only speeds class creation up by 4x. That difference is big enough that I think we should seriously consider using the C implementation. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Jelle Zijlstra added the comment:
I benchmarked some common namedtuple operations with the following script:
#!/bin/bash
echo 'namedtuple creation'
./python -m timeit -s 'from collections import namedtuple' 'x = namedtuple("x",
["a", "b", "c"])'
echo 'namedtuple instantiation'
./python -m timeit -s 'from collections import namedtuple; x = namedtuple("x",
["a", "b", "c"])' 'x(1, 2, 3)'
echo 'namedtuple attribute access'
./python -m timeit -s 'from collections import namedtuple; x = namedtuple("x",
["a", "b", "c"]); i = x(1, 2, 3)' 'i.a'
echo 'namedtuple _make'
./python -m timeit -s 'from collections import namedtuple; x = namedtuple("x",
["a", "b", "c"])' 'x._make((1, 2, 3))'
--
With my patch as it stands now I get:
$ ./ntbenchmark.sh
namedtuple creation
2000 loops, best of 5: 101 usec per loop
namedtuple instantiation
50 loops, best of 5: 477 nsec per loop
namedtuple attribute access
500 loops, best of 5: 59.9 nsec per loop
namedtuple _make
50 loops, best of 5: 430 nsec per loop
--
With unpatched CPython master I get:
$ ./ntbenchmark.sh
namedtuple creation
500 loops, best of 5: 409 usec per loop
namedtuple instantiation
50 loops, best of 5: 476 nsec per loop
namedtuple attribute access
500 loops, best of 5: 60 nsec per loop
namedtuple _make
100 loops, best of 5: 389 nsec per loop
So creating a class is about 4x faster (similar to the benchmarks various other
people have run) and calling _make() is 10% slower. That's probably because of
the line "if len(result) != cls._num_fields:" in my implementation, which would
have been something like "if len(result) != 3" in the exec-based implementation.
I also cProfiled class creation with my patch. These are results for creating
1 3-element namedtuple classes:
390005 function calls in 2.793 seconds
Ordered by: cumulative time
ncalls tottime percall cumtime percall filename:lineno(function)
10.0530.0002.8260.000
:1(make_nt)
11.0990.0002.7730.000
/home/jelle/qython/cpython/Lib/collections/__init__.py:380(namedtuple)
10.9480.0000.9810.000 {built-in method builtins.exec}
100.3160.0000.3160.000 {method 'format' of 'str' objects}
10.0690.0000.2200.000 {method 'join' of 'str' objects}
40.0710.0000.1520.000
/home/jelle/qython/cpython/Lib/collections/__init__.py:439()
10.0440.0000.0440.000 {built-in method builtins.repr}
30.0330.0000.0330.000 {method 'startswith' of 'str'
objects}
40.0310.0000.0310.000 {method 'isidentifier' of 'str'
objects}
40.0250.0000.0250.000 {method '__contains__' of
'frozenset' objects}
10.0220.0000.0220.000 {method 'replace' of 'str'
objects}
10.0220.0000.0220.000 {built-in method sys._getframe}
30.0200.0000.0200.000 {method 'add' of 'set' objects}
20.0180.0000.0180.000 {built-in method builtins.len}
10.0130.0000.0130.000 {built-in method
builtins.isinstance}
10.0090.0000.0090.000 {method 'get' of 'dict' objects}
So about 35% of time is still spent in the exec() call to create __new__.
Another 10% is in .format() calls, so using f-strings instead of .format()
might also be worth it.
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue28638>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- resolution: rejected -> ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Jelle Zijlstra added the comment: Should we consider a C-based implementation like https://github.com/ll/cnamedtuple? It could improve speed even more, but would be harder to maintain and test and harder to keep compatible. My sense is that it's not worth it unless benchmarks show a really dramatic difference. As for Raymond's list of goals, my PR now preserves _source and verbose=True and the test suite passes. I think the only docs change needed is in the description for _source (https://docs.python.org/3/library/collections.html#collections.somenamedtuple._source), which is no longer "used to create the named tuple class". I'll add that to my PR. I haven't done anything towards the last two goals yet. Should the change be applied to 3.6? It is fully backwards compatible, but perhaps the change is too disruptive to be included in the 3.6 series at this point. -- resolution: -> rejected ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Optimize namedtuple creation
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +2796 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28638] Creating namedtuple is too slow to be used in common stdlib (e.g. functools)
Jelle Zijlstra added the comment: I'm also concerned that the slowness of namedtuple creation is causing people to avoid using it. I can see why we wouldn't want a complicated solution like using Argument Clinic, but it's not clear to me why Serhiy's approach in namedtuple-no-compile.patch was rejected. This approach could provide a speedup for all namedtuple instantiations without complicating the implementation. I wrote a similar implementation in https://github.com/JelleZijlstra/cpython/commit/5634af4ccfd06a2fabc2cc2cfcc9c014caf6f389 and found that it speeds up namedtuple creation, uses less code, and creates only one necessary backwards compatibility break (we no longer have _source). -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28638> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30896] BytesWarning in re module when compiling certain bytes patterns
New submission from Jelle Zijlstra: This code in sre_parse (line 738 and down): warnings.warn( 'Flags not at the start of the expression %s%s' % ( source.string[:20], # truncate long regexes ' (truncated)' if len(source.string) > 20 else '', ), DeprecationWarning, stacklevel=7 ) triggers a BytesWarning if you do `_line_re = re.compile(br'^(.*?)$(?m)')`. The fix should be simple; I can try to get a PR in over the next few days. -- components: Library (Lib) messages: 298095 nosy: Jelle Zijlstra, ezio.melotti, serhiy.storchaka priority: normal severity: normal status: open title: BytesWarning in re module when compiling certain bytes patterns versions: Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30896> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30623] python-nightly import numpy fails since recently
Jelle Zijlstra added the comment: Sounds like the issue is with numpy, not CPython, so there's little reason to keep this CPython bug open. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30623] python-nightly import numpy fails since recently
Jelle Zijlstra added the comment: The error is /home/travis/virtualenv/python3.7-dev/lib/python3.7/site-packages/numpy/core/multiarray.cpython-37m-x86_64-linux-gnu.so: undefined symbol: PyTraceMalloc_Untrack. On a quick look I couldn't find any recent changes in CPython related to tracemalloc. -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30623> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30266] AbstractContextManager should support __method__ = None
Jelle Zijlstra added the comment: Thanks for doing the merge and backport! -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30518] Import type aliases from another module
Jelle Zijlstra added the comment: This is likely an issue with the setup of your project, not with type aliases. You haven't given enough information to tell me what the real problem is. I'm not sure what you mean by "I still can't compile 'Blocks'". -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30518> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30484] Garbage Collector can cause Segfault whilst iterating dictionary items
Jelle Zijlstra added the comment: I could reproduce this on 3.4, but not on 3.3, 2.7, or master. -- nosy: +Jelle Zijlstra versions: +Python 3.4 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30484> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30441] os.environ raises RuntimeError: dictionary changed size during iteration
Jelle Zijlstra added the comment: Even with the patch, I don't think it's safe to modify os.environ while it's being accessed concurrently in another thread. The other thread's modification could arrive while the dict() call in your patch is running (in CPython the GIL might protect you, but that's an implementation detail). I think the real solution is that your application uses a lock or some other concurrency mechanism to protect access to os.environ. -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30441> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30424] make pydoc-topics fails
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- assignee: -> docs@python components: +Documentation nosy: +docs@python stage: -> needs patch versions: +Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30424] make pydoc-topics fails
New submission from Jelle Zijlstra: Running `make pydoc-topics` in Doc/ on master fails with $ make pydoc-topics sphinx-build -b pydoc-topics -d build/doctrees -D latex_elements.papersize= . build/pydoc-topics Running Sphinx v1.6.1 making output directory... loading pickled environment... not yet created building [mo]: targets for 0 po files that are out of date building [pydoc-topics]: all pydoc topics updating environment: 466 added, 0 changed, 0 removed reading sources... [100%] whatsnew/index looking for now-outdated files... none found pickling environment... done checking consistency... done /Users/jzijlstra-mpbt/py/venvs/venv36/lib/python3.6/site-packages/sphinx/application.py:444: RemovedInSphinx17Warning: app.status_iterator() is now deprecated. Use sphinx.util.status_iterator() instead. RemovedInSphinx17Warning) /Users/jzijlstra-mpbt/py/venvs/venv36/lib/python3.6/site-packages/sphinx/application.py:425: RemovedInSphinx17Warning: app._display_chunk() is now deprecated. Use sphinx.util.display_chunk() instead. RemovedInSphinx17Warning) building topics... [ 1%] assert Exception occurred: File "/Users/jzijlstra-mpbt/py/venvs/venv36/lib/python3.6/site-packages/sphinx/builders/__init__.py", line 129, in create_translator assert translator_class, "translator not found for %s" % self.__class__.__name__ AssertionError: translator not found for PydocTopicsBuilder The full traceback has been saved in /var/folders/nh/ctlmlrjs6sx561k27fgn4btmgp/T/sphinx-err-_9ox_985.log, if you want to report the issue to the developers. Please also report this if it was a user error, so that a better error message can be provided next time. A bug report can be filed in the tracker at <https://github.com/sphinx-doc/sphinx/issues>. Thanks! make: *** [build] Error 1 I ran into this because some code in Lib/pydoc.py told me to run make pydoc-topics as part of the patch for issue 30406. -- messages: 294104 nosy: Jelle Zijlstra, ezio.melotti priority: normal severity: normal status: open title: make pydoc-topics fails ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30424> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30359] Annotating a function as returning an (async) context manager?
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30359> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30406] async and await should be keywords in 3.7
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +1763 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30406] async and await should be keywords in 3.7
New submission from Jelle Zijlstra: According to PEP 492, async and await should be full keywords in Python 3.7, but this hasn't been implemented yet. I have a patch ready that I'll submit as a PR soon. -- components: Interpreter Core messages: 293976 nosy: Jelle Zijlstra, giampaolo.rodola, haypo, yselivanov priority: normal severity: normal status: open title: async and await should be keywords in 3.7 versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30406> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30266] AbstractContextManager should support __method__ = None
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +1546 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30266] AbstractContextManager should support __method__ = None
New submission from Jelle Zijlstra: Like other ABCs, contextlib.AbstractContextManager should support the pattern where setting a method to None disables structural subtyping, which was introduced across the standard library in issue 25958. Ivan Levkivskyi suggested making AbstractContextManager support this pattern in CR comments in https://github.com/python/cpython/pull/1412/files#r114482765. Should this change be applied to 3.6 as well as master? I'm leaning towards yes, because the resolution to issue 25958 (https://hg.python.org/cpython/rev/72b9f195569c) added a general statement in the documentation that "Setting a special method to ``None`` indicates that the corresponding operation is not available". Thus, the fact that contextlib.AbstractContextManager doesn't obey this rule is a bug. I'll send a PR shortly. -- components: Library (Lib) messages: 292955 nosy: Jelle Zijlstra, levkivskyi, ncoghlan, yselivanov priority: normal severity: normal status: open title: AbstractContextManager should support __method__ = None versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30266> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30241] Add contextlib.AbstractAsyncContextManager
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +1520 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30241] Add contextlib.AbstractAsyncContextManager
New submission from Jelle Zijlstra: It would be useful to have an abstract base class for asynchronous context managers, similar to the existing contextlib.AbstractContextManager. We can then also add this class to typing and use it as a PEP 544 Protocol. I have code ready for contextlib.AbstractAsyncContextManager and will submit the PR shortly. I'll also add support in typing and typeshed if the CPython change is accepted. -- components: Library (Lib) messages: 292835 nosy: Jelle Zijlstra, levkivskyi, ncoghlan, yselivanov priority: normal severity: normal status: open title: Add contextlib.AbstractAsyncContextManager type: enhancement versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30241> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30235] Validate shutil supports path-like objects, update docs accordingly
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +1501 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30235> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30218] shutil.unpack_archive doesn't support PathLike
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +1476 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30218] shutil.unpack_archive doesn't support PathLike
New submission from Jelle Zijlstra: According to PEP 519, it should. I'll submit a PR soon. -- components: Library (Lib) messages: 292642 nosy: Jelle Zijlstra, brett.cannon, tarek priority: normal severity: normal status: open title: shutil.unpack_archive doesn't support PathLike versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30218> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30174] Duplicate code in pickletools.py
New submission from Jelle Zijlstra: The bytes1 ArgumentDescriptor is duplicated in pickletools.py. -- messages: 292364 nosy: Jelle Zijlstra, alexandre.vassalotti priority: normal pull_requests: 1408 severity: normal status: open title: Duplicate code in pickletools.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30174> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29974] typing.TYPE_CHECKING doc example is incorrect
Jelle Zijlstra added the comment: The example is actually correct; I just confirmed by running it in my shell. Type annotations on local variables are not evaluated at runtime; see PEP 526. -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29974> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29935] list and tuple index methods should accept None parameters
Jelle Zijlstra added the comment: I agree with George that supporting None here is the better option. This problem also applies to collections.deque. tuple, list, and deque all have very similar index implementations, and it would be nice to merge their argument parsing boilerplate. -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29935> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29162] pyshell.py: name 'sys' is not defined
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +735 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29162> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29847] Path takes and ignores **kwargs
Jelle Zijlstra added the comment: Thanks, I'll add a PR. This doesn't need to be documented, right? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29847] Path takes and ignores **kwargs
New submission from Jelle Zijlstra: pathlib.Path.__new__ takes **kwargs, but doesn't do anything with them (https://github.com/python/cpython/blob/master/Lib/pathlib.py#L979). This doesn't appear to be documented. This feature should presumably be either documented or removed (probably removed unless I'm missing some reason for having it). Brief discussion on a typeshed PR at https://github.com/python/typeshed/pull/991#discussion-diff-105813974R100 -- messages: 289817 nosy: Jelle Zijlstra, pitrou priority: normal severity: normal status: open title: Path takes and ignores **kwargs ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29847> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29825] PyFunction_New() not validate code object
Jelle Zijlstra added the comment: I don't think this is a bug; it is known and expected that you can do all kinds of bad things by writing bytecode manually. (You can already make Python write to random memory by giving it LOAD_FAST or STORE_FAST opcodes with incorrect offsets.) This doesn't seem to be clearly documented though; the documentation just says that bytecode can change between releases. -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29825> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29691] Some tests fail in coverage Travis check
Jelle Zijlstra added the comment: I'll look into creating a PR when I have some time. It would also be useful to tweak the Travis/coverage configuration so that it fails loudly if one of the tests doesn't pass in the coverage check. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29692] contextlib.contextmanager may incorrectly unchain RuntimeError
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- nosy: +Jelle Zijlstra ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29692> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29691] Some tests fail in coverage Travis check
New submission from Jelle Zijlstra: A few tests fail in the coverage Travis target (see e.g. https://travis-ci.org/python/cpython/jobs/206480468): test_traceback and test_xml_etree. I extracted the actual failures by running in verbose mode locally: == FAIL: test_recursive_traceback_cpython_internal (test.test_traceback.TracebackFormatTests) -- Traceback (most recent call last): File "/home/jelle/cpython-dev/cpython-1/Lib/test/test_traceback.py", line 431, in test_recursive_traceback_cpython_internal self._check_recursive_traceback_display(render_exc) File "/home/jelle/cpython-dev/cpython-1/Lib/test/test_traceback.py", line 347, in _check_recursive_traceback_display self.assertEqual(actual[-1], expected[-1]) AssertionError: 'RecursionError: maximum recursion depth exceeded in comparison' != 'RecursionError: maximum recursion depth exceeded' - RecursionError: maximum recursion depth exceeded in comparison ? -- + RecursionError: maximum recursion depth exceeded == FAIL: test_recursive_traceback_python (test.test_traceback.TracebackFormatTests) -- Traceback (most recent call last): File "/home/jelle/cpython-dev/cpython-1/Lib/test/test_traceback.py", line 423, in test_recursive_traceback_python self._check_recursive_traceback_display(traceback.print_exc) File "/home/jelle/cpython-dev/cpython-1/Lib/test/test_traceback.py", line 347, in _check_recursive_traceback_display self.assertEqual(actual[-1], expected[-1]) AssertionError: 'RecursionError: maximum recursion depth exceeded in comparison' != 'RecursionError: maximum recursion depth exceeded' - RecursionError: maximum recursion depth exceeded in comparison ? -- + RecursionError: maximum recursion depth exceeded == FAIL: test_bug_xmltoolkit63 (test.test_xml_etree.BugsTest) -- Traceback (most recent call last): File "/home/jelle/cpython-dev/cpython-1/Lib/test/test_xml_etree.py", line 1538, in test_bug_xmltoolkit63 self.assertEqual(sys.getrefcount(None), count) AssertionError: 505087 != 505084 Fixing this will improve the coverage check on PRs. ------ components: Tests messages: 288786 nosy: Jelle Zijlstra, eli.bendersky, ezio.melotti, michael.foord, scoder priority: normal severity: normal status: open title: Some tests fail in coverage Travis check versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29691> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29679] Add @contextlib.asynccontextmanager
Jelle Zijlstra added the comment: Thanks, I'll address your PR comments. issue 29302 is asking for AsyncExitStack, but that can be an independent change. I haven't personally felt the need for AsyncExitStack. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29679] Add @contextlib.asynccontextmanager
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- pull_requests: +307 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29679] Add @contextlib.asynccontextmanager
New submission from Jelle Zijlstra: An async equivalent of @contextmanager would be an obvious use case for async generators and the async with statement. In my own code, I have several async context objects that could have been written more concisely if @asynccontextmanager was available. I'll be working on a PR to implement this. -- components: Library (Lib) messages: 288729 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Add @contextlib.asynccontextmanager versions: Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29679> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Jelle Zijlstra added the comment: Fixed the typo -- Added file: http://bugs.python.org/file46445/issue29310-3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Jelle Zijlstra added the comment: Thanks! Uploaded a revised patch. -- Added file: http://bugs.python.org/file46442/issue29310-2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- assignee: Jelle Zijlstra -> ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- keywords: +patch Added file: http://bugs.python.org/file46410/issue29310.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29310] Document typing.NamedTuple default argument syntax
New submission from Jelle Zijlstra: Document https://github.com/python/typing/pull/338 I should have a patch in the next few days; creating this issue to remind myself. -- assignee: Jelle Zijlstra components: Documentation messages: 285740 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Document typing.NamedTuple default argument syntax versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29310> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29198] AsyncGenerator is missing from typing
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: Added file: http://bugs.python.org/file46220/typingindentation.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29198] AsyncGenerator is missing from typing
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: Added file: http://bugs.python.org/file46219/asyncgenerator3.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29205] col_offset for AsyncFunctionDef AST nodes is wrong
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: -- keywords: +patch Added file: http://bugs.python.org/file46215/issue29205.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29205] col_offset for AsyncFunctionDef AST nodes is wrong
Jelle Zijlstra added the comment: The col_offset is actually correct when there is a decorator: In [26]: code = '@decorator\nasync def f(): pass' In [27]: tree = ast.parse(code) In [28]: tree.body[0].col_offset Out[28]: 0 The same issue appears with async for and async with: In [31]: code = '@decorator\nasync def f():\nasync for x in y: pass' In [32]: tree = ast.parse(code) In [34]: tree.body[0].body[0] Out[34]: <_ast.AsyncFor at 0x7f5cb6a77198> In [35]: tree.body[0].body[0].col_offset Out[35]: 10 -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29205] col_offset for AsyncFunctionDef AST nodes is wrong
New submission from Jelle Zijlstra: The col_offset attribute for ast.AsyncFunctionDef objects points to the "def" keyword, not to the "async" keyword that actually starts the node. Test case: In [18]: code = 'async def f(): pass' In [19]: tree = ast.parse(code) In [20]: tree.body[0] Out[20]: <_ast.AsyncFunctionDef at 0x7f5cb6a58f60> In [21]: tree.body[0].col_offset Out[21]: 6 -- components: Library (Lib) messages: 284978 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: col_offset for AsyncFunctionDef AST nodes is wrong versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29205> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29198] AsyncGenerator is missing from typing
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: Added file: http://bugs.python.org/file46203/asyncgenerator2.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29198] AsyncGenerator is missing from typing
New submission from Jelle Zijlstra: PEP 525 async generators weren't added to typing.py, probably by oversight. I sent pull requests to typing and typeshed on GitHub to add an AsyncGenerator class and stub: - https://github.com/python/typing/pull/346 - https://github.com/python/typeshed/pull/815 However, typing docs are not in GitHub, so I'm attaching a doc patch here. -- components: Library (Lib) files: asyncgenerator.patch keywords: patch messages: 284937 nosy: Jelle Zijlstra, gvanrossum, yselivanov priority: normal severity: normal status: open title: AsyncGenerator is missing from typing versions: Python 3.6, Python 3.7 Added file: http://bugs.python.org/file46202/asyncgenerator.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29198> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28967] copy.copy fails on threading.local subclass
Jelle Zijlstra added the comment: This might be due to issue22995. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28967] copy.copy fails on threading.local subclass
New submission from Jelle Zijlstra: Calling copy.copy on a threading.local subclass copies attributes over correctly in Python 2.7, but creates an empty object in Python 3.3-3.5 and fails with a pickle-related error in 3.6. Marking this as a release blocker and assigning to Ned because this appears to be a regression in 3.6. However, given that the behavior in previous Python 3 versions isn't very useful either, I'd personally not want to block 3.6 on it. I haven't yet looked at code to figure out what is causing the differences in behavior. I couldn't find any tracker issues related to copying or pickling threading.local objects, but may have missed something. $ cat thread_local_copy.py import copy import threading class Obj(threading.local): def __init__(self): self.x = 3 o = Obj() o2 = copy.copy(o) assert hasattr(o2, 'x') $ python2.7 thread_local_copy.py $ python3.3 thread_local_copy.py Traceback (most recent call last): File "thread_local_copy.py", line 10, in assert hasattr(o2, 'x') AssertionError $ python3.4 thread_local_copy.py Traceback (most recent call last): File "thread_local_copy.py", line 10, in assert hasattr(o2, 'x') AssertionError $ python3.5 thread_local_copy.py Traceback (most recent call last): File "thread_local_copy.py", line 10, in assert hasattr(o2, 'x') AssertionError $ ./python.exe -V Python 3.6.0+ $ ./python.exe thread_local_copy.py Traceback (most recent call last): File "thread_local_copy.py", line 9, in o2 = copy.copy(o) File "/Users/Jelle/code/cpython/Lib/copy.py", line 96, in copy rv = reductor(4) TypeError: can't pickle Obj objects -- assignee: ned.deily files: thread_local_copy.py keywords: 3.6regression messages: 283165 nosy: Jelle Zijlstra, ned.deily priority: release blocker severity: normal status: open title: copy.copy fails on threading.local subclass type: behavior versions: Python 3.6 Added file: http://bugs.python.org/file45886/thread_local_copy.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28962] Crash when throwing an exception with a malicious __hash__ override
New submission from Jelle Zijlstra: $ cat baderror.py class BadError(Exception): def __init__(self): self.i = 0 def __hash__(self): self.i += 1 return self.i e = BadError() raise e from e $ ./python.exe -V Python 3.5.2+ $ ./python.exe baderror.py Segmentation fault: 11 I have reproduced this with Python 3.3, 3.4, 3.5, and 3.6; I assume it's been present throughout the 3 series. This is because print_exception_recursive in pythonrun.c keeps following the __cause__ chain, and here the exception is its own __cause__. It uses a set to ensure that it breaks cycles, but that doesn't help here because of the exception's incorrect __hash__ method. -- components: Interpreter Core files: baderror.py messages: 283118 nosy: Jelle Zijlstra priority: normal severity: normal status: open title: Crash when throwing an exception with a malicious __hash__ override versions: Python 3.3, Python 3.4, Python 3.5, Python 3.6, Python 3.7 Added file: http://bugs.python.org/file45876/baderror.py ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28962> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28603] traceback module can't format/print unhashable exceptions
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: Added file: http://bugs.python.org/file45872/issue28603-list.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28603] traceback module can't format/print unhashable exceptions
Changes by Jelle Zijlstra <jelle.zijls...@gmail.com>: Added file: http://bugs.python.org/file45871/issue28603-ignore.patch ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue28603> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
