[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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("/proc/sys/debug/exception-trace", "r+b") as f:
... mmap.mmap(f.fileno(), 0)
...
Traceback (most recent call last):
File "", line 2, in
ValueError: mmap offset is greater than file size
Same goes for almost any other /proc file, because most of them have S_ISREG()
== True and st_size = 0.
How about adding a keyword argument to `mmap.mmap()`, which disables
fstat-based size checks?
--
components: Library (Lib)
messages: 140330
nosy: superbobry
priority: normal
severity: normal
status: open
title: Disable size checks in mmap.mmap()
type: feature request
versions: Python 2.6
___
Python tracker
<http://bugs.python.org/issue12556>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 to XenBus [1]. Unfortunately, I'm not aware of any other cases. By the way, I've checked mmap(2) manpage -- it looks like the C-version has nothing against mmaping 0-sized files, Why does Python's `mmap` still checks file size? [1] http://wiki.xensource.com/xenwiki/XenBus -- ___ Python tracker <http://bugs.python.org/issue12556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 me to mmap it. Anyway, you're right, the use-case is too uncommon. -- resolution: -> rejected status: open -> closed ___ Python tracker <http://bugs.python.org/issue12556> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 resulting dataclass. However, they are not part of the dataclass structure and are only used for __*init__ generation, so perhaps they shouldn't be? Wdyt? -- components: Library (Lib) messages: 392058 nosy: eric.smith, superbobry priority: normal severity: normal status: open title: InitVar should not be available on a @dataclass-decorated class versions: Python 3.10, Python 3.11, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue43953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 kept in the class namespace. Do you see what could go wrong if we delete them? -- ___ Python tracker <https://bugs.python.org/issue43953> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 <https://bugs.python.org/issue45524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 typing from dataclasses import dataclass def make_A(): import collections @dataclass class A: x: collections.defaultdict return A A = make_A() @dataclass class B(A): y: int # NameError: name 'collections' is not defined print(typing.get_type_hints(B.__init__)) ``` -- ___ Python tracker <https://bugs.python.org/issue45524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 confusing the error message is, it might be worth having an issue for that. Wdyt? -- ___ Python tracker <https://bugs.python.org/issue45524> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 should "materialize" the stored attributes
whenever __dict__ (or rather a pointer to __dict__) is accessed. In this
context materialization means something like:
__dict__ = {}
for key, value in zip(keys, values):
__dict__[key] = value
Now, what if a __dict__ is accessed during a GC collection (which is possible:
collect->deduce_unreachable->subtract_refs->subtype_traverse via tp_traverse)?
The JIT compiler should be able to detect such calls and avoid allocating
anything:
if collecting:
return
__dict__ = {}
# ...
This is possible to implement in pure Python using gc.isenabled and
gc.callbacks, but there is no existing API to do that in C.
Does this sounds convincing enough to motivate adding
int PyGC_IsEnabled(void)
int PyGC_IsCollecting(void)
to the C API?
--
nosy: +sergei.lebedev
___
Python tracker
<https://bugs.python.org/issue28254>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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-wrapped freefunc # All defined in globals(). LAST_FREED = None def myfree(ptr): global LAST_FREED LAST_FREED = ptr FREE_FUNC = freefunc(myfree) FREE_INDEX = RequestCodeExtraIndex(FREE_FUNC) Imagine that we have registered another co_extra slot FOO_INDEX of type Foo and a freefunc FreeFoo. Furthermore, assume that * FOO_INDEX < FREE_INDEX * FOO_INDEX is set on any executed code object including myfree. Consider what happens when we collect the globals() of the test_code module. myfree is referenced by globals() and FREE_FUNC. If FREE_FUNC is DECREF'd first, then by the time we get to myfree it has a refcount of 1 and DECREF'ing it leads to a code_dealloc call. Recall that the code object corresponding to myfree has two co_extra slots: * FOO_INDEX pointing to some Foo*, and * FREE_INDEX with a value of NULL. So, code_dealloc will first call FreeFoo (because FOO_INDEX < FREE_INDEX) and then the ctypes wrapper of myfree. The following sequence of calls looks roughly like this _CallPythonObject ... PyEval_EvalCodeEx _PyEval_EvalCodeWithName frame_dealloc code_dealloc # ! The argument of the last code_dealloc call is *the same* myfree code object (!). This means that code_dealloc will attempt to call FreeFoo on an already free'd pointer leading to a crash. -- components: Tests messages: 360117 nosy: slebedev priority: normal severity: normal status: open title: test_code.CoExtra leads to double-free when ce_size >1 type: crash versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39358> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 any performance implications/runtime costs associated with making it (row, col) a namedtuple? -- nosy: +superbobry ___ Python tracker <https://bugs.python.org/issue5857> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 maintain a list of such changes for tooling authors (who might need to support multiple Python versions). [*]: https://github.com/python/cpython/blob/68526fe258da8c01196fd7cf48e8e5f1280bf8fd/Grammar/python.gram#L523 -- components: Interpreter Core messages: 377435 nosy: lys.nikolaou, slebedev priority: normal severity: normal status: open title: PEG parser doesn't allow lambda in for_if_clause type: behavior versions: Python 3.10, Python 3.9 ___ Python tracker <https://bugs.python.org/issue41848> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 Python 2.7 LoadLibrary explicitly mentions None as allowed in
the error message:
>>> ctypes.cdll.LoadLibrary(42)
Traceback (most recent call last):
File "", line 1, in
File "[...]/ctypes/__init__.py", line 444, in LoadLibrary
return self._dlltype(name)
File "[...]/ctypes/__init__.py", line 366, in __init__
self._handle = _dlopen(self._name, mode)
TypeError: dlopen() argument 1 must be string or None, not int
A side-effect of None being allowed is that chaining find_library and
LoadLibrary is error-prone:
>>> ctypes.cdll.LoadLibrary(find_library("foobar"))
--
messages: 324654
nosy: superbobry
priority: normal
severity: normal
status: open
title: cdll.LoadLibrary allows None as an argument
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7
___
Python tracker
<https://bugs.python.org/issue34592>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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 standard builtin ``__import__()`` is called. However, one can easily verify this isn't (always) the case:: import sys assert "glob" not in sys.modules __import__ = print import glob # Doesn't print anything. I've traced the import statement from ``ceval.c`` to the frozen ``importlib._bootstrap`` and it seems the cause of the problem is in ``_find_and_load_unlocked``, which simply ignores the ``_import`` argument in the case above:: def _find_and_load_unlocked(name, import_): path = None # ... parent processing ... spec = _find_spec(name, path) if spec is None: raise ImportError(_ERR_MSG.format(name), name=name) else: # XXX import_ is not used. module = _SpecMethods(spec)._load_unlocked() # ... more parent processing ... return module I'm not sure if this is a bug in the documentation or implementation, so any feedback is appreciated. -- assignee: docs@python components: Documentation, Library (Lib) messages: 253635 nosy: docs@python, superbobry priority: normal severity: normal status: open title: _find_and_load_unlocked doesn't always use __import__ versions: Python 3.4, Python 3.5 ___ Python tracker <http://bugs.python.org/issue25500> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[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> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
