[issue29916] No explicit documentation for PyGetSetDef and getter and setter C-API
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +3600 ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29916] No explicit documentation for PyGetSetDef and getter and setter C-API
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- keywords: +patch pull_requests: +3598 stage: -> patch review ___ Python tracker <rep...@bugs.python.org> <https://bugs.python.org/issue29916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30537] Using PyNumber_AsSsize_t in itertools.islice
New submission from Michael Seifert: In a question on StackOverflow (https://stackoverflow.com/questions/44302946/itertools-does-not-recognize-numpy-ints-as-valid-inputs-on-python-3-6) it was mentioned that numpys scalars cannot be used as index for `itertools.islice`. The reason for this is because the numbers are converted with `PyLong_AsSsize_t` (which requires a PyLongObject [or subclass]) instead of `PyNumber_AsSsize_t` (which only requires an `__index__` method). I'm not sure if there are many use-cases where numpy scalars make sense as inputs for `islice` but it's definetly unexpected that `itertools.islice([1, 2, 3, 4, 5, 6], np.int32(3))` currently throws a `ValueError: Stop argument for islice() must be None or an integer: 0 <= x <= sys.maxsize.` -- components: Library (Lib) messages: 294934 nosy: MSeifert priority: normal severity: normal status: open title: Using PyNumber_AsSsize_t in itertools.islice type: behavior versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30537> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)
Michael Seifert added the comment: > zip.__length_hint__() must return NotImplemented or raise TypeError if any of > iterators don't implement __length_hint__ or its __length_hint__() returns > NotImplemented or raises TypeError. > And what should return zip(range(3), range(2**1000)).__length_hint__()? I > expect 3, not OverflowError. That's actually non-trivial because PyObject_LengthHint just returns a Py_ssize_t. To recover NotImplemented will be complicated and there's no way to discriminate if the OverflowError happened in PyObject_LengthHint or in the called __length_hint__. But TypeError is correctly re-raised in the tests I made. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)
Michael Seifert added the comment: > I would like to mark this tracker item as closed. IMO it is a dead-end. Yes, even some (not very uncommon cases) give incorrect results: it = iter([1,2,3]) zip(it, it, it) has length_hint 3 but will only yield one item. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)
Michael Seifert added the comment: > I explored that notion of iterator length transparency years ago. While I > don't remember all the details, I did record some notes at the top of > Lib/test/test_iterlen.py. But isn't that the point of the length_hint? To provide an *estimate* for the length? So generally I would expect the length_hint to be accurate (at least accurate enough to avoid reallocations) for well-behaved iterators. And I think that's possible for "zip" and "map" (but also for several itertools: product, permutations, combinations, islice, accumulate, starmap, zip_longest). At least in theory. Also it would allow to prohibit infinite iterators to be passed to "length_hint"-aware functions. For example `list(count())` could raise an exception when `count.length_hint` would return math.inf or sys.maxsize + 1. The pull request was just because I was curious how it performed and wanted to share the code. Feel free to reject it. The performance improvement wasn't amazing in the micro-benchmarks. -- nosy: +MSeifert ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30059] No documentation for C type Py_Ellipsis
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +1279 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30059] No documentation for C type Py_Ellipsis
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +1278 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30059] No documentation for C type Py_Ellipsis
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +1280 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30059] No documentation for C type Py_Ellipsis
Michael Seifert added the comment: > I'm wondering if it is worth to add a separate section for Ellipsis at the > same level as "Slice Objects", but in the same file. I'm not sure either. There seems to be no precedent in the documentation, for example "Py_NotImplemented" is also just another (but mentioned first) point in the Object protocol [https://docs.python.org/3/c-api/object.html#object-protocol] and "Py_None" even has a complete page [https://docs.python.org/3/c-api/none.html]. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30059] No documentation for C type Py_Ellipsis
New submission from Michael Seifert: The "Py_Ellipsis" object is part of the public C-API but it isn't documented anywhere. It is defined in "sliceobject.o/.h" so I created a PR and added it to the "slice" documentation. -- assignee: docs@python components: Documentation messages: 291567 nosy: MSeifert, docs@python priority: normal pull_requests: 1238 severity: normal status: open title: No documentation for C type Py_Ellipsis type: enhancement versions: Python 2.7, Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30059> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue26828] Implement __length_hint__() on map() and filter() to optimize list(map) and list(filter)
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +1220 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue26828> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29897] itertools.chain behaves strangly when copied with copy.copy
Michael Seifert added the comment: Just an update what doesn't work: just overriding the `__copy__` method. I tried it but it somewhat breaks `itertools.tee` because if the passed iterable has a `__copy__` method `tee` rather copies the iterator (=> resulting in a lot of unnecessary memory overhead or breakage if a generator is "inside") instead of using it's memory-efficient internals. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29951] PyArg_ParseTupleAndKeywords exception messages containing "function"
Michael Seifert added the comment: Thank you for the suggestions, I added them to the PR. If you want But are you sure about the "keywords must be strings" -> "keyword arguments must be strings" change? I always thought the key is the "keyword" and the value the "(keyword) argument". -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29951] PyArg_ParseTupleAndKeywords exception messages containing "function"
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +816 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29951] PyArg_ParseTupleAndKeywords exception messages containing "function"
New submission from Michael Seifert: Some exceptions thrown by `PyArg_ParseTupleAndKeywords` refer to "function" or "this function" even when a function name was specified. For example: >>> import bisect >>> bisect.bisect_right([1,2,3,4], 2, low=10) TypeError: 'low' is an invalid keyword argument for this function Wouldn't it be better to replace the "this function" part (if given) with the actual function name? -- messages: 290885 nosy: MSeifert priority: normal severity: normal status: open title: PyArg_ParseTupleAndKeywords exception messages containing "function" type: behavior versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29951> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1234] semaphore errors on AIX 5.2
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +753 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue1234> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29917] Wrong link target in PyMethodDef documentation
New submission from Michael Seifert: The `link`-target of the "type" struct member is the python built-in "type". See [1]. I think it should not be a link at all. [1] https://docs.python.org/3.7/c-api/structures.html#c.PyMemberDef -- assignee: docs@python components: Documentation messages: 290575 nosy: MSeifert, docs@python priority: normal severity: normal status: open title: Wrong link target in PyMethodDef documentation ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29917> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29916] No explicit documentation for PyGetSetDef and getter and setter C-API
New submission from Michael Seifert: A copy of the struct definition can be found in the typeobject documentation [1]. There is also some explanation of the "closure" function pointer in the extending tutorial [2]. However the struct isn't explicitly defined as "c:type" so the 6 links to it in the documentations go nowhere. I also submitted a pull request. [1] https://docs.python.org/3.6/c-api/typeobj.html#c.PyTypeObject.tp_getset [2] https://docs.python.org/3/extending/newtypes.html -- assignee: docs@python components: Documentation messages: 290574 nosy: MSeifert, docs@python priority: normal pull_requests: 742 severity: normal status: open title: No explicit documentation for PyGetSetDef and getter and setter C-API ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29916> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29897] itertools.chain behaves strangly when copied with copy.copy
New submission from Michael Seifert: When using `copy.copy` to copy an `itertools.chain` instance the results can be weird. For example >>> from itertools import chain >>> from copy import copy >>> a = chain([1,2,3], [4,5,6]) >>> b = copy(a) >>> next(a) # looks okay 1 >>> next(b) # jumps to the second iterable, not okay? 4 >>> tuple(a) (2, 3) >>> tuple(b) (5, 6) I don't really want to "copy.copy" such an iterator (I would either use `a, b = itertools.tee(a, 2)` or `b = a` depending on the use-case). This just came up because I investigated how pythons iterators behave when copied, deepcopied or pickled because I want to make the iterators in my extension module behave similarly. -- components: Library (Lib) messages: 290106 nosy: MSeifert priority: normal severity: normal status: open title: itertools.chain behaves strangly when copied with copy.copy type: behavior versions: Python 3.5, Python 3.6 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29897> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29813] PyTuple_GetSlice does not always return a new tuple
Michael Seifert added the comment: I rather thought about something along the lines of: "Take a slice of the tuple pointed to by *p* from *low* to *high* and return it as a tuple. Whether the returned tuple is new or not is an implementation detail (and may depend on the value of the arguments)." Because from the point of the C-API tuples aren't immutable, at least not if they are new (refcount 1). Thank you both for your feedback. I'll leave it closed as "not a bug", I got the point about over-explaining. :) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29800] functools.partial segfaults in repr when keywords attribute is abused
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +555 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29800] functools.partial segfaults in repr when keywords attribute is abused
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +554 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29813] PyTuple_GetSlice does not always return a new tuple
Michael Seifert added the comment: > What leads to your headache? That depending on the arguments to "PyTuple_GetSlice" I get "SystemError: ..\Objects\tupleobject.c:156: bad argument to internal function" when using PyTuple_SetItem on the (supposedly) new tuple. Maybe I just misunderstood the word "new" in the documentation. :-) -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29813] PyTuple_GetSlice does not always return a new tuple
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- title: PyTuple_GetSlice documentation incorrect -> PyTuple_GetSlice does not always return a new tuple ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29813] PyTuple_GetSlice documentation incorrect
New submission from Michael Seifert: The PyTuple_GetSlice documentation says it "Take a slice of the tuple pointed to by p from low to high and return it as a new tuple." [0] However in case the start is <= 0 and the stop is >= tuplesize it doesn't return the promised "new tuple", it just returns the tuplepointer after incrementing it's refcount [1]. The behaviour is fine (it gave me a bit of a headache though), however could a note/warning/sentence be included in the docs mentioning that special case? [0] https://docs.python.org/3/c-api/tuple.html#c.PyTuple_GetSlice [1] https://github.com/python/cpython/blob/master/Objects/tupleobject.c#L414 -- assignee: docs@python components: Documentation messages: 289632 nosy: MSeifert, docs@python priority: normal severity: normal status: open title: PyTuple_GetSlice documentation incorrect type: behavior ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29813> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29800] functools.partial segfaults in repr when keywords attribute is abused
Michael Seifert added the comment: Given that this my first contribution to CPython I'm not too sure about the etiquette. When do I know (or who decides) when an agreement on a fix is reached? I wouldn't mind retracting the pull request if someone else wants to fix it differently. I actually used the PyUnicode_Check on purpose because I always viewed the representation should be either unreadably (like objectxyz at 0xwhatever) or something that can should be copy Returning something that will definetly throw an exception when copied seemed inappropriate. But the %S change definetly has it's attraction: shorter, also fixes the segfault and no need for type checking. Given Serhiy's answer it seems to me there could be another lurking problem because any %R or %S is potentially a problem within PyDict_Next - because this C-API-Function states that "The dictionary p should not be mutated during iteration. It is safe to modify the values of the keys as you iterate over the dictionary, but only so long as the set of keys does not change." But arbitary __str__ or __repr__ functions could do just that. I'm mostly an end-user so I'm not sure if I understand that right? -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29800] functools.partial segfaults in repr when keywords attribute is abused
Changes by Michael Seifert <michaelseifer...@yahoo.de>: -- pull_requests: +536 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue29800] functools.partial segfaults in repr when keywords attribute is abused
New submission from Michael Seifert: It's possible to create a segfault when one (inappropriatly) changes the functools.partial.keywords attribute manually. A minimal example reproducing the segfault is: >>> from functools import partial >>> p = partial(int) >>> p.keywords[1] = 10 >>> repr(p) System: Windows 10 Python: 3.5.3, 3.6.0, master-branch -- components: Library (Lib) messages: 289510 nosy: MSeifert priority: normal severity: normal status: open title: functools.partial segfaults in repr when keywords attribute is abused type: crash versions: Python 3.5, Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue29800> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
