Ian Kelly added the comment:
Chris Angelico suggested on python-list that another possibly useful thing to
do would be to add a "from __future__ import generator_stop" to
asyncio/futures.py. This would at least have the effect of causing "await
future" to raise a
Ian Kelly added the comment:
The place I'd expect to find it is in
https://docs.python.org/3/library/asyncio-task.html#coroutines, in the list of
"things a coroutine can do". The first two bullets in the list say that any
exceptions raised will be propagated. Maybe there should
Ian Kelly added the comment:
The asyncio docs also have this note, so this is technically not a bug:
Note: In this documentation, some methods are documented as coroutines, even if
they are plain Python functions returning a Future. This is intentional to have
a freedom of tweaking
New submission from Ian Kelly:
I was playing around with this class for adapting regular iterators to async
iterators using BaseEventLoop.run_in_executor:
import asyncio
class AsyncIteratorWrapper:
def __init__(self, iterable, loop=None, executor=None):
self._iterator = iter
Ian Kelly added the comment:
The idea is that the wrapped iterator is something potentially blocking, like a
database cursor that doesn't natively support asyncio. Usage would be something
like this:
async def get_data():
cursor.execute('select * from stuff')
async for row
Ian Kelly added the comment:
Fair enough. I think there should be some documentation though to the effect
that coroutines aren't robust to passing StopIteration across coroutine
boundaries. It's particularly surprising with PEP-492 coroutines, since those
aren't even iterators and intuitively
New submission from Ian Kelly:
'{:g}'.format(D('0.01'))
'0.01'
Formatted with '{:e}', the exponent would be -6, so per the formatting rules
described under the 'g' specifier at
https://docs.python.org/3/library/string.html#format-specification-mini-language
the above should
New submission from Ian Kelly:
I expect this should result in a recursion depth exceeded error, not a
segmentation fault.
$ cat test.py
import itertools
l = []
it = itertools.chain.from_iterable(l)
l.append(it)
next(it)
$ python3 test.py
Segmentation fault (core dumped)
--
components
Ian Kelly added the comment:
The bug also occurs using 32-bit Python 3.3.1 on Windows 7.
--
nosy: +ikelly
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue17697
Ian Kelly added the comment:
I'm not sure why you think this patch would be backwards incompatible.
I've tested it with gdbm-1.8.0 and gdbm-1.7.3, and it works for those.
__
Tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1167
New submission from Ian Kelly:
The ndbm functions in gdbm 1.8.1+ require the gdbm_compat library in
addition to gdbm.
--
components: Build, Extension Modules
files: gdbm_ndbm.diff
messages: 55939
nosy: ikelly
severity: normal
status: open
title: gdbm/ndbm 1.8.1+ needs libgdbm_compat.so
11 matches
Mail list logo
