On 30/04/2019 09.52, Peter Otten wrote: > Thomas Jollans wrote: > >> On 29/04/2019 09.18, Peter Otten wrote: >>> Jonathan Leroy - Inikup via Python-list wrote: >>> alice.name = "Bob" # __setattr__ >>> >>> del customers[42] # __delitem__ >> >> do you want this sort of thing to update the upstream database directly? > > I thought so. However, you have to answer this question no matter which of > the suggested APIs you choose.
True, but with a .update(key=value, ...) method (which takes multiple kwargs) you don't have the potential issue of more requests than necessary if you're updating multiple fields. > >> Maybe there should be a commit() method on every object. Maybe not. > > I originally had > > db = api.connect(...) > customers = db.customers > > but then decided this was out of scope for the question. It would however > allow > > with db: > ... # modify db > # implicit commit, or rollback on exception > >> I imagine it would be best if the data is cached locally (i.e. alice = >> customers[1] does a query, print(alice.name) does not). In this case you >> probably want the local/database separation to be consistent for both >> getting and setting things. > > That looks like a lot of work, with the potential to introduce additional > inconsistencies. But there's probably prior art. > > How do ORMs like SQLObject handle this? It's been a while, but I'm pretty sure the Django ORM at least has caching everywhere. > >>> del customers[alice] >> >> Are you sure about this? > > On a scale from one to ten? Yes ;) > >>>> #3 seems to be more "pretty" to me, but I did not find any "official" >>>> recommendation online. >> >> I'd like #3 if it had square brackets after .customers. Of the >> suggestions as they are I prefer #2. > > -- https://mail.python.org/mailman/listinfo/python-list
