[Python-Dev] async __setitem__

Yury Selivanov yselivanov.ml at gmail.com
Sat Jun 20 19:45:52 CEST 2015

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.


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 at python.org
> https://mail.python.org/mailman/listinfo/python-dev
> Unsubscribe: https://mail.python.org/mailman/options/python-dev/yselivanov.ml%40gmail.com

More information about the Python-Dev mailing list