Roundup Robot added the comment:
New changeset f7cc54086cd2 by Guido van Rossum in branch 'default':
Fix news entry for issue 24018.
https://hg.python.org/cpython/rev/f7cc54086cd2
--
___
Python tracker rep...@bugs.python.org
Guido van Rossum added the comment:
Fixed.
On Fri, May 8, 2015 at 10:28 PM, Stefan Behnel rep...@bugs.python.org
wrote:
Stefan Behnel added the comment:
Thanks! Minor grouch: it should say collections.*abc*.Generator in the
NEWS entry.
--
Stefan Behnel added the comment:
This is blocking issue 24017 (async/await syntax).
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
___
Guido van Rossum added the comment:
Ask Yury if he'll commit it for you. It's ready.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
resolution: - fixed
stage: - resolved
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Roundup Robot added the comment:
New changeset ba5d7041e2f5 by Raymond Hettinger in branch 'default':
Issue #24018: Add a collections.Generator abstract base class.
https://hg.python.org/cpython/rev/ba5d7041e2f5
--
nosy: +python-dev
___
Python
Stefan Behnel added the comment:
Thanks! Minor grouch: it should say collections.*abc*.Generator in the NEWS
entry.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Changes by Raymond Hettinger raymond.hettin...@gmail.com:
--
assignee: lukasz.langa - rhettinger
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Łukasz Langa added the comment:
Yup, will do.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
___
Python-bugs-list mailing list
Guido van Rossum added the comment:
Yeah, looks good -- Łuke, can you commit this?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
___
Raymond Hettinger added the comment:
The latest patch looks good overall.
Łukasz, assigning back to you.
--
assignee: rhettinger - lukasz.langa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Please either
1) drop the throw() method entirely or
2) make throw an abstractmethod()
Ok, as I already said, I think it's important to provide the complete protocol
as code will usually expect that. Also, close() has a helpful implementation,
but it
Ludovic Gasc added the comment:
Sorry guys to be basic for you, but if I take my AsyncIO end-user hat, I'm
not sure to understand the potential end-user source code impacts to use Cython
with Python 3.5 and AsyncIO.
In concrete terms, it's only a low-level change, Cython will monkeypatch
Raymond Hettinger added the comment:
Therefore, I think it's important to cover the complete protocol
in the Generator ABC. I also think it's helpful to not require
users to override throw() in a subclass, as they might not need it.
Sorry, but I think you're fighting the fundament nature of
Stefan Behnel added the comment:
PEP 342 isn't really conclusive here as it intended to define the protocol
based on the de-facto design of a yield-based generator function. Trying to
abstract from that poses the question how a class based generator
implementation should look like.
Raymond Hettinger added the comment:
In the lastest patch, the close() method is now a valid mixin method.
However, the throw() method should be made abstract because it doesn't provide
the required operation (it doesn't even use the self argument) or it should
be left out entirely (i.e.
Antoine Pitrou added the comment:
I think the throw() method should be required.
If you don't need throw(), send() or close(), then you aren't really asking for
a full-blown generator: you are asking for an iterator, so you can just check
for collections.Iterator.
(PS: why is this bug
Guido van Rossum added the comment:
I'm with Raymond.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
___
Python-bugs-list mailing list
Stefan Behnel added the comment:
FYI, here's the patch implementation for Cython:
https://github.com/cython/cython/blob/cf63ff71c06b16c3a30facdc7859743f4cd495f6/Cython/Utility/Generator.c#L849
The only difference is that it takes care of changing __next__ to next in
Py2.x.
--
Stefan Behnel added the comment:
Searching for Python code that seems to implement the Generator protocol
doesn't return much:
https://code.openhub.net/search?s=%22def%20throw%28%22%20%22def%20send%28%22%20%22def%20close%28%22pp=0fl=Pythonmp=1ml=1me=1md=1ff=1filterChecked=true
But at least it
Stefan Behnel added the comment:
Adding a patch for the inspect docs that refers to the Right Way To Do It.
--
Added file: http://bugs.python.org/file39179/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39179/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Changes by Stefan Behnel sco...@users.sourceforge.net:
Added file: http://bugs.python.org/file39180/inspect_docs.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Stefan Behnel added the comment:
Good catch with the RuntimeError. Patch updated.
--
Added file: http://bugs.python.org/file39157/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
should inspect.isgenerator() be changed?
Replying to myself, one thing that speaks against this approach is that
inspect also has the functions getgeneratorlocals() and
getgeneratorstate(), which depend on gen.gi_frame. Cython could emulate
that, but normal
Stefan Behnel added the comment:
Yes, and there are certainly other compilers and tools. However, it's going to
be a short list, so if Py3.5 takes the lead, they can all just agree on the one
way to do it and let the first patcher win.
--
___
Guido van Rossum added the comment:
Is it an option to leave inspect alone? Its definition and use of generators is
very focused on the builtin implementation.
Although this means that code that wants to do the right thing but also be
backwards compatible has to use something like
```
def
Guido van Rossum added the comment:
Realistically only Cython will care much about this, so I'm okay if Cython just
monkeypatches the collections package.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Yes, code usually doesn't fall from the sky with a new CPython release. If
something wants to make use of this ABC, it still has to find ways to also work
with older CPythons. What would be a good fallback? A backport on PyPI?
I wouldn't even mind shipping
Antoine Pitrou added the comment:
In some distant future, Numba might also care too :)
(right now, we only support compiling basic generators, i.e. no send() and no
throw())
--
___
Python tracker rep...@bugs.python.org
Changes by Łukasz Langa luk...@langa.pl:
--
assignee: - lukasz.langa
nosy: +lukasz.langa
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Changes by Martin Panter vadmium...@gmail.com:
--
nosy: +vadmium
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
___
Python-bugs-list
Raymond Hettinger added the comment:
For the other ABCs, if you define the required abstract methods, you get
working versions of all the mixin methods.
In the case of the Generator ABC, throw() and close() are useless empty stub
methods. In the other ABCs, we leave optional methods out
Stefan Behnel added the comment:
Here's a new patch that addresses the review comments. I kept throw() and
close() non-abstract and added an example to the tests instead that implements
a minimal generator by inheriting these methods from the Generator base class,
using it as a mixin. It only
Stefan Behnel added the comment:
Next question: should inspect.isgenerator() be changed? Or should its usages be
replaced by isinstance(obj, Generator) ?
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Stefan Behnel added the comment:
Is it a problem that the check can't be done in a fast way from C code?
C code can still quickly special case the generator type in the positive case,
and it will usually be interested in an exact type match anyway. Determining
that an object is *not*
Martin Panter added the comment:
I agree that there is no big reason why we should force generators to stop
working after close(). Your new default implementation of close() is probably
the right thing too. I added a few new comments on Reitveld.
--
Antoine Pitrou added the comment:
Is it a problem that the check can't be done in a fast way from C code?
Other than that, sounds good to me.
--
nosy: +pitrou
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Guido van Rossum added the comment:
It's missing tests. :-)
Otherwise looks quite sensible.
Also, shouldn't you override __subclasshook__ so you don't inherit it from
Iterator?
--
___
Python tracker rep...@bugs.python.org
Stefan Behnel added the comment:
Ok, sure. Here's a new patch that adds tests and docs.
--
Added file: http://bugs.python.org/file39150/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39146/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
Stefan Behnel added the comment:
Sorry, here's another doc fix.
--
Added file: http://bugs.python.org/file39151/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
New submission from Stefan Behnel:
Currently, CPython tends to assume that generators are always implemented by a
Python function that uses the yield keyword. However, it is absolutely
possible to implement generators as a protocol by adding send(), throw() and
close() methods to an iterator.
Changes by Stefan Behnel sco...@users.sourceforge.net:
Removed file: http://bugs.python.org/file39150/generator_abc.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue24018
___
44 matches
Mail list logo
