[Python-Dev] ABCs - Re: PEP 492: async/await in Python; version 4
Stefan Behnel schrieb am 02.05.2015 um 06:54: Yury Selivanov schrieb am 01.05.2015 um 20:52: I don't like the idea of combining __next__ and __anext__. Ok, fair enough. So, how would you use this new protocol manually then? Say, I already know that I won't need to await the next item that the iterator will return. For normal iterators, I could just call next() on it and continue the for-loop. How would I do it for AIterators? BTW, I guess that this AIterator, or rather AsyncIterator, needs to be a separate protocol (and ABC) then. Implementing __aiter__() and __anext__() seems perfectly reasonable without implementing (or using) a Coroutine. That means we also need an AsyncIterable as a base class for it. Would Coroutine then inherit from both Iterator and AsyncIterator? Or should we try to separate the protocol hierarchy completely? The section on Coroutine objects seems to suggest that inheritance from Iterator is not intended. OTOH, I'm not sure if inheriting from AsyncIterator is intended for Coroutine. The latter might just be a stand-alone ABC with send/throw/close, after all. I think that in order to get a better understanding of the protocol(s) that this PEP proposes, and the terminology that it should use, it would help to implement these ABCs. That might even help us to decide if we need new builtins (or helpers) aiter() and anext() in order to deal with these protocols. Stefan ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492 quibble and request
On 1 May 2015 at 20:59, Guido van Rossum gu...@python.org wrote: On Fri, May 1, 2015 at 12:49 PM, Ron Adam ron3...@gmail.com wrote: Another useful async function might be... async def yielding(): pass In a routine is taking very long time, just inserting await yielding() in the long calculation would let other awaitables run. That's really up to the scheduler, and a function like this should be provided by the event loop or scheduler framework you're using. Really? I was under the impression that 'await yielding()' as defined above would actually not suspend the coroutine at all, therefore not giving any opportunity for the scheduler to resume another coroutine, and I thought I understood the PEP well enough. Does this mean that somehow await x guarantees that the coroutine will suspend at least once? To me the async def above was the equivalent of the following in the 'yield from' world: def yielding(): return yield # Just to make it a generator Then yield from yielding() will not yield at all - which makes its name rather misleading! -- Arnaud ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sub-claasing pathlib.Path seems impossible
http://stackoverflow.com/a/29880095/2097780 My favorite thing about Python is that it's so easy to be evil. ;) On Fri, May 1, 2015 at 2:30 PM, Christophe Bal projet...@gmail.com wrote: Hello. In this post http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141, I have noticed a problem with the following code. from pathlib import Path class PPath(Path): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) test = PPath(dir, test.txt) This gives the following error message. Traceback (most recent call last): File /Users/projetmbc/test.py, line 14, in module test = PPath(dir, test.txt) File /anaconda/lib/python3.4/pathlib.py, line 907, in __new__ self = cls._from_parts(args, init=False) File /anaconda/lib/python3.4/pathlib.py, line 589, in _from_parts drv, root, parts = self._parse_args(args) File /anaconda/lib/python3.4/pathlib.py, line 582, in _parse_args return cls._flavour.parse_parts(parts)AttributeError: type object 'PPath' has no attribute '_flavour' This breaks the sub-classing from Python point of view. In the post http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141, I give a hack to sub-class Path but it's a bit Unpythonic. *Christophe BAL* *Enseignant de mathématiques en Lycée **et développeur Python amateur* *---* *French math teacher in a Lycée **and **Python **amateur developer* ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PEP 492: async/await in Python; version 4
On Fri, May 01, 2015 at 09:24:47PM +0100, Arnaud Delobelle wrote: I'm not convinced that allowing an object to be both a normal and an async iterator is a good thing. It could be a recipe for confusion. In what way? I'm thinking that the only confusion would be if you wrote async for instead of for, or vice versa, and instead of getting an exception you got the (a)syncronous behaviour you didn't want. But I have no intuition for how likely it is that you could write an asyncronous for loop, leave out the async, and still have the code do something meaningful. Other than that, I think it would be fine to have an object be both a syncronous and asyncronous iterator. You specify the behaviour you want by how you use it. We can already do that, e.g. unittest's assertRaises is both a test assertion and a context manager. Objects can have multiple roles, and it's not usually abused, or confusing. I'm not sure that async iterables will be any different. -- Steve ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Sub-claasing pathlib.Path seems impossible
It does sound like subclassing Path should be made easier. On Sat, May 2, 2015 at 1:30 PM, Ryan Gonzalez rym...@gmail.com wrote: http://stackoverflow.com/a/29880095/2097780 My favorite thing about Python is that it's so easy to be evil. ;) On Fri, May 1, 2015 at 2:30 PM, Christophe Bal projet...@gmail.com wrote: Hello. In this post http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141, I have noticed a problem with the following code. from pathlib import Path class PPath(Path): def __init__(self, *args, **kwargs): super().__init__(*args, **kwargs) test = PPath(dir, test.txt) This gives the following error message. Traceback (most recent call last): File /Users/projetmbc/test.py, line 14, in module test = PPath(dir, test.txt) File /anaconda/lib/python3.4/pathlib.py, line 907, in __new__ self = cls._from_parts(args, init=False) File /anaconda/lib/python3.4/pathlib.py, line 589, in _from_parts drv, root, parts = self._parse_args(args) File /anaconda/lib/python3.4/pathlib.py, line 582, in _parse_args return cls._flavour.parse_parts(parts)AttributeError: type object 'PPath' has no attribute '_flavour' This breaks the sub-classing from Python point of view. In the post http://stackoverflow.com/questions/29850801/simple-subclassing-pathlib-path-does-not-work/29854141#29854141, I give a hack to sub-class Path but it's a bit Unpythonic. *Christophe BAL* *Enseignant de mathématiques en Lycée **et développeur Python amateur* *---* *French math teacher in a Lycée **and **Python **amateur developer* ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/rymg19%40gmail.com -- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/guido%40python.org -- --Guido van Rossum (python.org/~guido) ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
