Hi Martin,
Actually, I think that it's better to adopt a bit different design:
async with db.transaction():
table[key1] = 'a'
table[key2] = 'b'
And then, in __aexit__ you should flush the updates to the database
in bulk. Usually, when working with an ORM, you need to update more
than one field anyways. And if it's just one,
'await table.set(key, val)' looks more obvious than
'await table[key] = val'.
I'd also recommend you to prohibit __setitem__ and __setattr__ outside
of a transaction.
Yury
On 2015-06-19 8:56 AM, Martin Teichmann wrote:
Hi everyone,
I was really happy to see PEP 492 - that is really a big step forward.
It makes many programming constructs possible in combination with
asyncio, which have been cumbersome or impossible until now.
One thing that still is impossible is to have __setitem__ be used
asynchronously. As an example, I am working with a database that
I access over the network, and it is easy to write
data = await table[key]
to get something out of the database. But getting something in, I have
to write something like
await table.set(key, value)
It would be cool if I could just write
await table[key] = value
which would, I think, fit in nicely with all of PEP 492.
That said, I was hesitating which keyword to use, await or async. PEP 492
says something like async is an adjective, await a command. Then for
setitem, technically, I would need an adverb, so "asyncly table[key] = value".
But I didn't want to introduce yet another keyword (two different ones for the
same thing are already confusing enough), so I arbitrarily chose await.
If we are really going for it (I don't see the use case yet, I just
mention it for
completeness), we could also be extend this to other points where variables
are set, e.g. "for await i in something():" which is a bit similar to
"async for i in something()" yet different.
Greetings
Martin
_______________________________________________
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/yselivanov.ml%40gmail.com
_______________________________________________
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
