Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +3600
___
Python tracker <rep...@bugs.python.org>
<https://bugs.python
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
keywords: +patch
pull_requests: +3598
stage: -> patch review
___
Python tracker <rep...@bugs.python.org>
<https://bugs.pyt
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
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), r
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 i
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
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +1279
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +1278
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +1280
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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_NotImpl
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
comp
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +1220
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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 mem
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 t
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +816
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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)
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +753
___
Python tracker <rep...@bugs.python.org>
<http://bugs.pytho
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
compo
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&
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)
>>>
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
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +555
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +554
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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.
May
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.pyt
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 "
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
Changes by Michael Seifert <michaelseifer...@yahoo.de>:
--
pull_requests: +536
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python
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.
29 matches
Mail list logo
