[issue46167] Parse assert (x == y, "Descriptive text") as statement params instead of a tuple

Change by Sergei Lebedev : -- nosy: +slebedev ___ Python tracker <https://bugs.python.org/issue46167> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue45524] Cross-module dataclass inheritance breaks get_type_hints

Sergei Lebedev added the comment: Is it worth filing a separate issue for locals()? In my experience local classes are less common than cross-module inheritance, so I suspect that the chances of someone accidentally hitting lack of locals() forwarding are quite low. However, given how

[issue45524] Cross-module dataclass inheritance breaks get_type_hints

Sergei Lebedev added the comment: Is it worth also addressing the case where a @dataclass/typing.TypeDict class is defined within a function? ``` from __future__ import annotations import

[issue45524] Cross-module dataclass inheritance breaks get_type_hints

Sergei Lebedev added the comment: I think the example has a minor typo. The crash is reproducible on 3.9 if the last line in bar.py is typing.get_type_hints(B.__init__) instead of typing.get_type_hints(B) -- ___ Python tracker <ht

[issue43953] InitVar should not be available on a @dataclass-decorated class

Sergei Lebedev added the comment: I understand that this is a side-effect of having a default value, but I was hoping we could delattr InitVar's in @dataclass. I'm not aware of this causing problems, but it does feel a bit unsatisfying that InitVar's with defaults are ke

[issue43953] InitVar should not be available on a @dataclass-decorated class

New submission from Sergei Lebedev : Motivating example: >>> @dataclass ... class A: ... x: InitVar[int] = 0 ... y: int = 1 ... >>> a = A() >>> a.x 0 >>> a.y 1 PEP-557 does not specify if fields annotated with InitVar[...] are available on the result

[issue5857] Return namedtuples from tokenize token generator

Sergei Lebedev added the comment: > I strongly prefer that there not be inner named tuples. Hi Raymond, do you still strongly prefer (row, col) to remain unnamed? If so, could you comment on what makes you prefer that apart from (row, col) being more common than (col, row)? Are there

[issue41848] PEG parser doesn't allow lambda in for_if_clause

New submission from Sergei Lebedev : Reproducer: [x for x in [] if lambda: x] This parses fine in 3.8, but doesn't parse in 3.9 because the grammar expects a disjunction after if in for_if_clause [*]. While this change has zero practical significance, I think it might be useful to mai

[issue39358] test_code.CoExtra leads to double-free when ce_size >1

Change by Sergei Lebedev : -- nosy: +dino.viehland ___ Python tracker <https://bugs.python.org/issue39358> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue39358] test_code.CoExtra leads to double-free when ce_size >1

New submission from Sergei Lebedev : tl;dr Passing a Python function as a freefunc to _PyEval_RequestCodeExtraIndex leads to double-free. In general, I think that freefunc should not be allowed to call other Python functions. --- test_code.CoExtra registers a new co_extra slot with a ctypes

[issue28254] Add C API for gc.enable, gc.disable, and gc.isenabled

Sergei Lebedev added the comment: I know this patch has already been rejected, but I wanted to give another potential use-case for accessing GC status from C: JIT compilers. Imagine a JIT compiler which uses alternative storage for instance attributes. In order to maintain correctness, it

[issue34592] cdll.LoadLibrary allows None as an argument

New submission from Sergei Lebedev : LoadLibrary in Python 2.7 through 3.7 accepts None as an argument. I wonder if this has been allowed for a reason? If not, it should probably be changed to raise a TypeError instead. >>> ctypes.cdll.LoadLibrary(None) Interestingly, on P

[issue8844] Condition.wait() doesn't raise KeyboardInterrupt

Sergei Lebedev added the comment: Is it possible to backport this patch to 2.7? -- nosy: +superbobry ___ Python tracker <http://bugs.python.org/issue8844> ___ ___

[issue25500] _find_and_load_unlocked doesn't always use __import__

New submission from Sergei Lebedev: According to the current import system documentation > When calling ``__import__()`` as part of an import statement, the import > system first checks the module global namespace for a function by that name. > If it is not found, then the standar

[issue12556] Disable size checks in mmap.mmap()

Sergei Lebedev added the comment: > Passing mmap(2) a 0 length doesn't make much sense anyway - for example, Linux returns EINVAL. Yup, but passing mmap(2) a zero-sized file and a non-zero length works just fine. > Why do you want a mmap? Why not using a file? Because Xen requires

[issue12556] Disable size checks in mmap.mmap()

Sergei Lebedev added the comment: > Do you have an example of a /proc entry with st_size == 0 that can be mmapped > (mapping /proc/sys/debug/exception-trace fails with EACCESS)? Yes, I've ran into the issue, while trying to mmap /proc/xen/xsd_kva, which is an interface t

[issue12556] Disable size checks in mmap.mmap()

New submission from Sergei Lebedev : Current `mmap` implementation raises a ValueError if a sum of offset and length exceeds file size, as reported by `fstat`. While perfectly valid for most use-cases, it doesn't work for "special" files, for example: >>> with open(&q