[issue41673] Result of multiprocessing.heap.BufferWrapper.create_memoryview can point to freed memory
Eric Wieser added the comment: Whoops, typo. `>>> b[0]` should read `m[0]`. -- ___ Python tracker <https://bugs.python.org/issue41673> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41673] Result of multiprocessing.heap.BufferWrapper.create_memoryview can point to freed memory
New submission from Eric Wieser :
The full definition of `multiprocessing.heap.BufferWrapper` is:
class BufferWrapper(object):
_heap = Heap()
def __init__(self, size):
if size < 0:
raise ValueError("Size {0:n} out of range".format(size))
if sys.maxsize <= size:
raise OverflowError("Size {0:n} too large".format(size))
block = BufferWrapper._heap.malloc(size)
self._state = (block, size)
util.Finalize(self, BufferWrapper._heap.free, args=(block,))
def create_memoryview(self):
(arena, start, stop), size = self._state
return memoryview(arena.buffer)[start:start+size]
But this means that a `memoryview` can be constructed that point to free'd
"memory",
>>> b = BufferWrapper(10)
>>> m = b.create_memoryview()
>>> del b # free is called
>>> b[0] # making this invalid
It would be better if `m` would keep a reference to `b` so that it remains
alive.
`RawArray` works around this by placing a reference to `b` in
`ctypes_obj._wrapper`, but this results in `b` being lost again if `m2 =
memoryview(ctypes_obj); del ctypes_obj` is used.
--
components: Library (Lib), ctypes
messages: 376149
nosy: Eric Wieser
priority: normal
severity: normal
status: open
title: Result of multiprocessing.heap.BufferWrapper.create_memoryview can point
to freed memory
versions: Python 3.10, Python 3.9
___
Python tracker
<https://bugs.python.org/issue41673>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41584] Clarify documentation for binary arithmetic operation subclass __r*__ precedence
Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue41584> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17336] Complex number representation round-trip doesn't work with signed zero values
Eric Wieser added the comment:
> BTW I don't want repr() of a complex number to use the complex(..., ...)
A compromise would be to only use this notation if signed zeros are involved.
---
Another option would be to use slightly unusual reprs for these complex
numbers, which at least round-trip:
def check(s, v):
c = eval(s)
# use string equality, because it's the easiest way to compare signed
zeros
cs = f"complex({c.real}, {c.imag})"
vs = f"complex({v.real}, {v.imag})"
assert vs == cs, f' expected {vs} got {cs}'
check("-(0+0j)", complex(-0.0, -0.0))
check("(-0.0-0j)", complex(-0.0, 0.0)) # non-intuitive
check("-(-0.0-0j)", complex(0.0, -0.0)) # non-intuitive
Which I suppose would extend to complex numbers containing just one signed zero
check("(-0.0-1j)", complex(-0.0, -1))
check("-(0.0-1j)", complex(-0.0, 1))
check("-(1+0j)", complex(-1, -0.0))
check("-(-1+0j)", complex(1, -0.0))
Only two of these reprs are misleading for users who don't understand what's
going on, the rest will just strike users as odd.
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue17336>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41485] Repr of complex number with signed zero does not roundtrip
Eric Wieser added the comment: Apologies for not searching the issue tracker effectively until after filing this. -- ___ Python tracker <https://bugs.python.org/issue41485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41485] Repr of complex number with signed zero does not roundtrip
Eric Wieser added the comment: This was reported and closed in https://bugs.python.org/issue17336, but it seems to me that this is easy to avoid - have `__repr__` return `complex(...)` for values which do not round-trip. -- ___ Python tracker <https://bugs.python.org/issue41485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue41485] Repr of complex number with signed zero does not roundtrip
New submission from Eric Wieser : Python distinguishes signed zeros by their repr: # floats >>> 0.0 0.0 >>> -0.0 -0.0 # complex >>> complex(0.0, 0.0) # A 0j >>> complex(0.0, -0.0) # B -0j >>> complex(-0.0, 0.0) # C (-0+0j) >>> complex(-0.0, -0.0) # D (-0+0j) However, only one of these `complex` reprs round-trips: >>> 0j # ok 0j >>> -0j # doesn't round-trip (-0-0j) >>> (-0+0j) # doesn't round-trip 0j >>> (-0-0j) 0j -- components: Interpreter Core messages: 374864 nosy: Eric Wieser priority: normal severity: normal status: open title: Repr of complex number with signed zero does not roundtrip versions: Python 3.8 ___ Python tracker <https://bugs.python.org/issue41485> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31861] add aiter() and anext() functions to operator module
Change by Eric Wieser : -- nosy: +Eric Wieser ___ 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
[issue37496] Support annotations in signature strings.
Eric Wieser added the comment: This seems somewhat related to https://bugs.python.org/issue31939 -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue37496> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40606] Copy property return annotations to __annotations__
Change by Eric Wieser : -- keywords: +patch nosy: +Eric.Wieser nosy_count: 1.0 -> 2.0 pull_requests: +19361 stage: -> patch review pull_request: https://github.com/python/cpython/pull/20052 ___ Python tracker <https://bugs.python.org/issue40606> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue40606] Copy property return annotations to __annotations__
New submission from Eric Wieser :
Consider a class like
class MyClass:
x: int
y: int
Which has
>>> MyClass.__annotations__
{'x': int, 'y': int}
In future, it might change to
class MyClass:
@property
def x(self) -> int:
...
@functools.cached_property
def x(self) -> int:
...
Most code won't be able to tell the difference, as properties are already a
mostly-transparent replacement for attributes - but any code looking at
`__annotations__` will find it is now absent.
It would be handy if `property.__set_name__` and `cachedproperty.__set_name__`
could populate the `__annotations__` dict from their return type annotation.
This isn't just hypothetically useful - `sphinx` master as of
https://github.com/sphinx-doc/sphinx/pull/7564 is able to retrieve the type of
any descriptor with this behavior.
--
components: Library (Lib)
messages: 368710
nosy: Eric Wieser
priority: normal
severity: normal
status: open
title: Copy property return annotations to __annotations__
type: enhancement
versions: Python 3.6, Python 3.7, Python 3.8, Python 3.9
___
Python tracker
<https://bugs.python.org/issue40606>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23967] Make inspect.signature expression evaluation more powerful
Eric Wieser added the comment: > To make this work I had to write an ast printer that produces evaluatable > Python code. Note that it's not complete, I know it's not complete, it's > missing loads of operators. Assume that if this is a good idea I will add > all the missing operators. Now that `ast.unparse` is in (bpo-38870), can this patch be simplified? -- ___ Python tracker <https://bugs.python.org/issue23967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue23967] Make inspect.signature expression evaluation more powerful
Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue23967> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37881] __text_signature__ parser doesn't handle globals in extension module
Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue37881> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34305] inspect.getsourcefile and inspect.getcomments do not work with decorated functions
Eric Wieser added the comment: Nothing holding it up from my end, just waiting on someone to review it. Perhaps this ping will help with that. -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue34305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39610] memoryview.__len__ should raise an exception for 0d buffers
Eric Wieser added the comment: Thanks for pointing out the docs reference, I updated the patch to reword that section. There's a sentence right before the one you draw attention to which to me reads as another argument to change this: > ``len(view)`` is equal to the length of :class:`~memoryview.tolist` On Python 2.7, this gives >>> len(view_0d) 1 >>> len(view_0d.tolist()) NotImplementedError: tolist() only supports one-dimensional objects On Python 3.8 before my patch, this gives: >>> len(view_0d) 1 >>> len(view_0d.tolist()) TypeError: object of type 'int' has no len() On Python 3.8, with my patch, this gives: >>> len(view_0d) TypeError: 0-dim memory has no length >>> len(view_0d.tolist()) TypeError: object of type 'int' has no len() As I read it, only with my patch is this sentence satisfied by the implementation. -- ___ Python tracker <https://bugs.python.org/issue39610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39610] memoryview.__len__ should raise an exception for 0d buffers
Change by Eric Wieser : -- keywords: +patch pull_requests: +17836 stage: -> patch review pull_request: https://github.com/python/cpython/pull/18463 ___ Python tracker <https://bugs.python.org/issue39610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39610] memoryview.__len__ should raise an exception for 0d buffers
New submission from Eric Wieser : Right now, the behavior is: >>> import numpy as np >>> arr_0d = np.array(42) >>> mem_0d = memoryview(arr_0d) >>> len(mem_0d) 1 >>> mem_0d[0] TypeError: invalid indexing of 0-dim memory It seems bizarre to have this object pretend to be a sequence when you ask for its length, yet not behave like one when you actually try to use this length. I'd suggest cpython should behave like numpy here, and fail: >>> len(arr_0d) TypeError: len() of unsized object Perhaps `TypeError: cannot get length of 0-dim memory` would be more appropriate as a message. --- Wasn't sure how to classify this, feel free to reclassify ------ components: Interpreter Core messages: 361821 nosy: Eric Wieser, skrah priority: normal severity: normal status: open title: memoryview.__len__ should raise an exception for 0d buffers type: behavior versions: Python 3.5, Python 3.6, Python 3.7, Python 3.8, Python 3.9 ___ Python tracker <https://bugs.python.org/issue39610> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue39471] Meaning and clarification of PyBuffer_Release()
Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue39471> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29258] __init__.py required for pkgutil.walk_packages in python3
Eric Wieser added the comment: If the resolution here is that this is behaving as intended (which personally I disagree with), I think this issue should remain open as a documentation task - the docs should clearly state that this does not apply to PEP420 namespace packages. -- ___ Python tracker <https://bugs.python.org/issue29258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37604] warnings should use a ContextVar to manage filters/registry
Eric Wieser added the comment: A relevant old issue is https://bugs.python.org/issue6647 -- components: +Library (Lib) nosy: +Eric Wieser type: -> behavior ___ Python tracker <https://bugs.python.org/issue37604> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29258] __init__.py required for pkgutil.walk_packages in python3
Change by Eric Wieser : -- nosy: +Eric Wieser ___ Python tracker <https://bugs.python.org/issue29258> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] memoryview & ctypes: incorrect itemsize for empty array
Eric Wieser added the comment: Pinging again, now that the patch has undergone a revision with some cleanup thanks to @skrah -- ___ Python tracker <https://bugs.python.org/issue32782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"
Change by Eric Wieser : -- pull_requests: +13779 stage: backport needed -> patch review pull_request: https://github.com/python/cpython/pull/13906 ___ Python tracker <https://bugs.python.org/issue37188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"
Change by Eric Wieser : -- components: +ctypes ___ Python tracker <https://bugs.python.org/issue37188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37187] CField.size from the ctypes module does not behave as documented on bitfields
Change by Eric Wieser : -- components: +ctypes type: -> behavior ___ Python tracker <https://bugs.python.org/issue37187> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"
Change by Eric Wieser : -- keywords: +patch pull_requests: +13759 stage: -> patch review pull_request: https://github.com/python/cpython/pull/13881 ___ Python tracker <https://bugs.python.org/issue37188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37188] Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception"
New submission from Eric Wieser : Introduced in the fix to bpo-36504, GH-12660. ```python >>> (ctypes.c_uint8 * 0 * 2)() Fatal Python error: Floating point exception >>> struct Empty(ctypes.Structure): _fields_ = [] >>> (Empty * 2)() Fatal Python error: Floating point exception ``` This used to work just fine ------ messages: 344901 nosy: Eric Wieser, ZackerySpytz priority: normal severity: normal status: open title: Creating a ctypes array of an element with size zero causes "Fatal Python error: Floating point exception" type: crash versions: Python 2.7, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue37188> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue37187] CField.size from the ctypes module does not behave as documented on bitfields
New submission from Eric Wieser :
This behavior is pretty surprising:
```python
import ctypes
class Simple(ctypes.Structure):
_fields_ = [
('a', ctypes.c_uint8),
('b', ctypes.c_uint8),
]
class Bitfields(ctypes.Structure):
_fields_ = [
('a', ctypes.c_uint8, 8),
('b', ctypes.c_uint8, 8),
]
print(Simple.b.size) # 1
print(Bitfields.b.size) # 262148
```
The docstring for this field, from `help(type(Bitfields.b).size)`, is:
> Help on getset descriptor _ctypes.CField.size:
>
> size
>size in bytes of this field
So either the behavior or the docstring needs to change.
--
assignee: docs@python
components: Documentation
messages: 344895
nosy: Eric Wieser, docs@python
priority: normal
severity: normal
status: open
title: CField.size from the ctypes module does not behave as documented on
bitfields
___
Python tracker
<https://bugs.python.org/issue37187>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] memoryview & ctypes: incorrect itemsize for empty array
Eric Wieser added the comment:
> Revising the code example to use an empty array
I think you mean
>>> import array
>>> memoryview(array.array('H', [])).itemsize
2
Your example is an array containing 0, not an empty array - but the conclusion
is the same.
> It is technically un-necessary as it can be obtained using
> PyBuffer_SizeFromFormat
This obviously predicates on `PyBuffer_SizeFromFormat` being implemented, which
according to the docs it is not.
> I think that the grammar would allow for an empty record "T{}" that would
> have itemsize 0 but is of little use inside numpy.
It also allows for records of empty arrays, "T{(0)d:data:}". While these are of
little use, they _are_ supported by both ctypes and numpy, so we should support
them in the PEP3118 interface used between them.
--
nosy: +Eric Wieser
___
Python tracker
<https://bugs.python.org/issue32782>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8987] Distutils doesn't quote Windows command lines properly
Eric Wieser added the comment: > then we should perhaps instead consider the rewrite for 3.6: provide a *new* > distutils function that does use Popen and does things "right" (based on > everything we've learned since distutils was written), leaving the old > function in place, deprecated, for backward compatibility. Was any progress made towards achieving this? It's frustrating that the correct quoting behavior we get with `subprocess.Popen(List[str])` is not used by `spawn`, and now every level of distutils code has to think about whether it needs to quote its arguments for the shell. -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue8987> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4921] Object lifetime and inner recursive function
Eric Wieser added the comment: For anyone doing archaeology - this came up on python-dev about a year after this issue was filed: https://mail.python.org/pipermail/python-dev/2009-December/094439.html -- ___ Python tracker <https://bugs.python.org/issue4921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] ctypes: memoryview gives incorrect PEP3118 itemsize for array of length zero
Eric Wieser added the comment: Pinging again, for lack of a clearer path forward -- ___ Python tracker <https://bugs.python.org/issue32782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34305] inspect.getsourcefile and inspect.getcomments do not work with decorated functions
Eric Wieser added the comment: Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing. -- ___ Python tracker <https://bugs.python.org/issue34305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34494] simple "sequence" class ignoring __len__
Eric Wieser added the comment: What I think I find surprising is that I'd expect the sequence protocol to be defined by `__getitem__` and `__len__`, and for `__iter__` to be inferred as: def __iter__(self): for i in range(len(self)): yield self[i] But in reality it seems it is inferred only from `__getitem__`, as: def __iter__(self): i = 0 while True: try: yield self[i] except IndexError: return i += 1 -- ___ Python tracker <https://bugs.python.org/issue34494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34494] simple "sequence" class ignoring __len__
Change by Eric Wieser : -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue34494> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1764286] inspect.getsource does not work with decorated functions
Eric Wieser added the comment: New issue opened at https://bugs.python.org/issue34305, along with a PR linked there. -- ___ Python tracker <https://bugs.python.org/issue1764286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34305] inspect.getsourcefile and inspect.getcomments do not work with decorated functions
Change by Eric Wieser : -- keywords: +patch pull_requests: +8108 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue34305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34305] inspect.getsourcefile and inspect.getcomments do not work with decorated functions
Change by Eric Wieser : -- nosy: +yselivanov ___ Python tracker <https://bugs.python.org/issue34305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue34305] inspect.getsourcefile and inspect.getcomments do not work with decorated functions
New submission from Eric Wieser : Following on from https://bugs.python.org/issue1764286 - inspect.getsourcefile and inspect.getcomments fall afoul of the same problem. -- components: Library (Lib) messages: 322847 nosy: Eric.Wieser priority: normal severity: normal status: open title: inspect.getsourcefile and inspect.getcomments do not work with decorated functions ___ Python tracker <https://bugs.python.org/issue34305> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1764286] inspect.getsource does not work with decorated functions
Eric Wieser added the comment: This now leaves `inspect.getsource` inconsistent with `inspect.getsourcefile`: >>> import inspect >>> from contextlib import contextmanager >>> @contextmanager ... def func(): ...yield >>> inspect.getsource(func) '@contextmanager\ndef func():\nyield\n' >>>inspect.getsourcefile(func) 'C:\\Program Files\\Python 3.5\\lib\\contextlib.py' Should `getsourcefile` be changed to match? This is causing numpy/numpy#11639, but it's not clear if this is a bug or by design. -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue1764286> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue8525] Display exceptions' subclasses in help()
Eric Wieser added the comment: > I get the following results for builtin objects that have defined subclasses >From that list, the only unhelpful ones with > 4 items, in my opinion, appear >to be `object`, since that just tells you every type that exists, and `tuple`, >because that lists every single namedtuple. > So it is USEFUL to know ALL subclasses of a given Exception class I agree with this - most of the value here comes from showing the full set of exceptions. If we don't do that, we should probably point the user to calling `cls.__subclasses__()` so they can inspect the full list -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue8525> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
Eric Wieser added the comment: > It should be fairly simple to modify the code to use a format of "B" > for unions, so that it at least matches the itemsize Seems reasonable, although: * I think it should be "B" or "()B" * I'd rather leave that for a later patch. While it would be correct, it's still not correct enough to be that useful, since ultimately the union layout is still lost. I'd prefer to focus on fixing the part of the PEPE3118 implementation that is most useful, rather than committing to fixing the whole thing all at once. -- ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] ctypes: memoryview gives incorrect PEP3118 itemsize for array of length zero
Eric Wieser added the comment: Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing. Ideally this and https://bugs.python.org/issue32780 would make the same patch release. -- ___ Python tracker <https://bugs.python.org/issue32782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
Eric Wieser added the comment: Pinging, as recommended by https://devguide.python.org/pullrequest/#reviewing. PEP3118 as a protocol is far less useful if the canonical implementation is non-compliant. -- ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33909] PyObject_CallFinalizerFromDealloc is not referenced in any documentation
New submission from Eric Wieser : PEP 442 states that: > Two new C API functions are provided to ease calling of tp_finalize, > especially from custom deallocators. But it does not give the names of these functions, nor do any python docs I can discover. >From grepping for tp_finalize, it seems the functions in question are: - PyObject_CallFinalizerFromDealloc - PyObject_CallFinalizer It would be great if these could be documented, and perhaps even an example given of when it's appropriate to call each one. -- assignee: docs@python components: Documentation messages: 320036 nosy: Eric.Wieser, docs@python priority: normal severity: normal status: open title: PyObject_CallFinalizerFromDealloc is not referenced in any documentation versions: Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8 ___ Python tracker <https://bugs.python.org/issue33909> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33267] ctypes array types create reference cycles
Eric Wieser added the comment: Apologies, I missed the important part of that snippet: ``` In [3]: gc.collect(); x = make_array_ctype((1,)); del x; gc.collect() Out[3]: 7 ``` -- ___ Python tracker <https://bugs.python.org/issue33267> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue33267] ctypes array types create reference cycles
New submission from Eric Wieser :
Discovered in https://github.com/numpy/numpy/pull/10882/files#r180813166
A reproduction:
```
In [1]: import ctypes
In [2]: def make_array_ctype(shape):
...: import ctypes
...: ct = ctypes.c_uint8
...: for i in shape:
...: ct = i * ct
...: return ct
...:
# all on one line to keep ipython out of this
In [3]: gc.collect(); x = make_array_ctype((1,)); del x; gc.collect()
```
Using the proposed function in https://github.com/numpy/numpy/pull/10891, we
get a few more details:
```
In [4]: from numpy.testing import assert_no_gc_cycles
In [5]: assert_no_gc_cycles(make_array_ctype, (1,))
AssertionError: Reference cycles were found when calling make_array_ctype: 7
objects were collected, of which 6 are shown below:
tuple object with id=282226536:
(,)
PyCArrayType object with id=286500408:
getset_descriptor object with id=2822252062256:
getset_descriptor object with id=2822252062184:
tuple object with id=2822243712440:
(,
,
,
)
StgDict object with id=286211928:
{'__dict__': ,
'__doc__': None,
'__module__': '__main__',
'__weakref__': ,
'_length_': 1,
'_type_': }
```
I suppose this isn't really a bug, but it's not clear to me why a cycle needs
to be created here.
--
components: ctypes
messages: 315216
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: ctypes array types create reference cycles
versions: Python 3.5
___
Python tracker
<https://bugs.python.org/issue33267>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28716] Fractions instantiation revisited
Eric Wieser added the comment: > Are you suggesting that _if_ they were to implement `as_integer_ratio` at > some point in the future, then they'd become compatible with `Fraction` Yes, exactly. Conversely, there's little gain in implementing it _until_ `Fraction` supports calling it. -- ___ Python tracker <https://bugs.python.org/issue28716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue4921] Object lifetime and inner recursive function
Eric Wieser added the comment: Would it be possible for function self-reference cell vars to be weak references? This wouldn't solve the issue for co-recursive inner functions, but would at least prevent reference cycles for the more common case of simple recursive functions. -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue4921> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] ctypes: memoryview gives incorrect PEP3118 itemsize for array of length zero
Change by Eric Wieser : -- keywords: +patch pull_requests: +5394 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32782> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32782] ctypes: memoryview gives incorrect PEP3118 itemsize for array of length zero
New submission from Eric Wieser :
Take the following simple structure:
class Foo(ctypes.Structure):
_fields_ = [('f', ctypes.uint32_t)]
And construct some arrays with it:
def get_array_view(N):
return memoryview((Foo * N)())
In most cases, this works as expected, returning the size of one item:
>>> get_array_view(10).itemsize
4
>>> get_array_view(1).itemsize
4
But when N=0, it returns the wrong result
>>> get_array_view(0).itemsize
0
Which contradicts its `.format`, which still describes a 4-byte struct
>>> get_array_view(0).format
'T{>I:one:}'
This causes a downstream problem in numpy:
>>> np.array(get_array_view(0))
RuntimeWarning: Item size computed from the PEP 3118 buffer format string
does not match the actual item size.
--
components: ctypes
messages: 311740
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: ctypes: memoryview gives incorrect PEP3118 itemsize for array of length
zero
type: behavior
versions: Python 3.6
___
Python tracker
<https://bugs.python.org/issue32782>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
Change by Eric Wieser : -- type: -> behavior ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
Change by Eric Wieser : -- keywords: +patch pull_requests: +5383 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue32780> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue32780] ctypes: memoryview gives incorrect PEP3118 format strings for both packed and unpacked structs
New submission from Eric Wieser :
Discovered [here](https://github.com/numpy/numpy/issues/10528)
Consider the following structure, and a memoryview created from it:
class foo(ctypes.Structure):
_fields_ = [('one', ctypes.c_uint8),
('two', ctypes.c_uint32)]
f = foo()
mf = memoryview(f)
We'd expect this to insert padding, and it does:
>>> mf.itemsize
8
But that padding doesn't show up in the format string:
>>> mf.format
'T{ No padding is added when using non-native size and alignment, e.g. with ‘<’,
> ‘>’
But ctypes doesn't even get it right for packed structs:
class foop(ctypes.Structure):
_fields_ = [('one', ctypes.c_uint8),
('two', ctypes.c_uint32)]
_pack_ = 1
f = foo()
mf = memoryview(f)
The size is what we'd expect:
>>> mf.itemsize
5
But the format is garbage:
>>> mf.format
'B' # sizeof(byte) == 5!?
--
components: ctypes
messages: 311705
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: ctypes: memoryview gives incorrect PEP3118 format strings for both
packed and unpacked structs
versions: Python 2.7, Python 3.4, Python 3.5, Python 3.6, Python 3.7, Python 3.8
___
Python tracker
<https://bugs.python.org/issue32780>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue31801] vars() manipulation encounters problems with Enum
Eric Wieser added the comment:
Not necessarily an argument against this feature, but two workarounds exist for
this already:
1. Use `nonlocal` to prevent `value` going into the class namespace:
value = None
class BaudRate(enum.Enum):
nonlocal value
for value in rates:
locals()['B%d' % value] = value
@classmethod
def valid_rate(cls, value):
return (any(value == item.value for item in cls))
2. Use `types.new_class`, which is more suited to dynamic class creation anyway:
def make_cls(ns):
for value in rates:
ns['B%d' % value] = value
@classmethod
def valid_rate(cls, value):
return (any(value == item.value for item in cls))
ns['valid_rate'] = valid_rate
types.new_class('BaudRate', (enum.Enum,), exec_body=make_cls)
--
nosy: +Eric.Wieser
___
Python tracker
<https://bugs.python.org/issue31801>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue28716] Fractions instantiation revisited
Eric Wieser added the comment: > allows Fraction instantiation from duck-typing classes that provide > as_integer_ratio This would allow the numpy `np.floating` types to take part in `Fraction` conversion as well, which would be great. As far as I can tell, `Decimal` already follows this duck-typing, so it would be a shame for other modules not to. Perhaps an `num, den = operator.rational(x)` is needed to unify this code across the places that coerce rational numbers. -- nosy: +Eric.Wieser ___ Python tracker <https://bugs.python.org/issue28716> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30140] Binary arithmetic does not always call subclasses first
Changes by Eric Wieser : -- nosy: +Eric.Wieser ___ Python tracker <http://bugs.python.org/issue30140> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27042] Incorrect grammar for function definitions
Eric Wieser added the comment: The parent commit is also bad: https://hg.python.org/cpython/rev/b65007ef59c0 -- ___ Python tracker <http://bugs.python.org/issue27042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27042] Incorrect grammar for function definitions
Eric Wieser added the comment: The offending patch can be found at https://hg.python.org/cpython/rev/71ff2235bb4c -- ___ Python tracker <http://bugs.python.org/issue27042> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue27042] Incorrect grammar for function definitions
New submission from Eric Wieser:
https://docs.python.org/3.2/reference/compound_stmts.html#function-definitions
and onwards say the following
decorator ::= "@" dotted_name ["(" [parameter_list [","]] ")"] NEWLINE
This is a regression from the 2.7 docs, which correctly said
decorator ::= "@" dotted_name ["(" [argument_list [","]] ")"] NEWLINE
The implication is that the following is supposedly valid in python 3:
@deco(what : "is this" = "supposed to mean")
def foo(annotations: "are only for here" = "right?"):
pass
The interpreter disagrees with the docs, and correctly rejects this syntax as
garbage
--
assignee: docs@python
components: Documentation
messages: 265735
nosy: Eric.Wieser, docs@python
priority: normal
severity: normal
status: open
title: Incorrect grammar for function definitions
versions: Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6
___
Python tracker
<http://bugs.python.org/issue27042>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18110] Nested set comprehensions in class scope fail
Eric Wieser added the comment: Thanks for the clarification - this behavior now makes perfect sense to me. As expected, swapping the list comprehension for a generator comprehension, or vice versa, prevents the error. -- ___ Python tracker <http://bugs.python.org/issue18110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18110] Nested set comprehensions in class scope fail
Changes by Eric Wieser : -- status: closed -> open ___ Python tracker <http://bugs.python.org/issue18110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18110] Nested set comprehensions in class scope fail
Eric Wieser added the comment: This is not at first glance, a duplicate of 3692 - in that case, the list comprehension is referring to another class variable. Most notably, that describes a behavioural change introduced by python 3 - in this case, python 3 handles it correctly - there's a bug in the python 2 implementation. -- resolution: duplicate -> ___ Python tracker <http://bugs.python.org/issue18110> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue18110] Nested set comprehensions in class scope fail
New submission from Eric Wieser:
This code:
class Sudoku(dict):
COLUMNS = [
{(x, y) for y in xrange(9)} for x in xrange(9)
]
When run on Python 2.7.5, fails with this traceback:
Traceback (most recent call last):
File "", line 1, in
class Sudoku(object):
File "", line 3, in Sudoku
{(x, y) for y in xrange(9)} for x in xrange(9)
File "", line 3, in
{(x, y) for y in xrange(9)} for x in xrange(9)
NameError: global name 'x' is not defined
Yet `x` is clearly not a global - it's defined in the comprehension.
Running the comprehension outside of the class gives no error:
>>> [
{(x, y) for y in xrange(9)} for x in xrange(9)
]
[set([...]), ...]
Nor does using `set`:
class Sudoku(dict):
COLUMNS = [
set((x, y) for y in xrange(9)) for x in xrange(9)
]
--
components: Interpreter Core
messages: 190420
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: Nested set comprehensions in class scope fail
type: behavior
versions: Python 2.7
___
Python tracker
<http://bugs.python.org/issue18110>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17788] Add a with expression, for use in comprehensions
Changes by Eric Wieser : -- components: +Interpreter Core ___ Python tracker <http://bugs.python.org/issue17788> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue17788] Add a with expression, for use in comprehensions
New submission from Eric Wieser:
It would be nice if there was a `with` "expression". Such that instead of:
with open(...) as f:
result = foo(f)
One could write:
result = foo(f) with open(...) as f
This would be particularly useful in comprehensions. Instead of:
files = {}
for fname in os.listdir('.'):
if predicate(fname):
with open(fname) as f:
files[fname] = foo(f)
files = {
fname: foo(f) with open(fname) as f
for fname in os.listdir('.') if predicate(fname)
}
--
messages: 187232
nosy: Eric.Wieser
priority: normal
severity: normal
status: open
title: Add a with expression, for use in comprehensions
type: enhancement
___
Python tracker
<http://bugs.python.org/issue17788>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
