update() override for datastore entities

[ghost]

Writing a code sample I find myself using the dict.update(dict) function quite often to do bulk adds of properties to an entity.

I realized that this can potentially have unsafe behavior (overriding protected fields such as 'id'), and additionally returns None which doesn't seem very pythonic or consistent with past APIs

Would it make sense to override this method within the datastore.entity.Entity class so that it

1. returns an updated handle to the same object (for list comprehension/chaining), and
2. does some sanity checking on the added properties?

[tseaver]

I'm not sure what "special" properties you have in mind, but entity.update(some_dict) won't mess with anything that the gcloud-datastore API needs: all the "special" stuff is down in the attributes (_dataset and _key) and can't be affected by assignment to any of the keys stored by the entity.

Note that the datastore docs for entities do say:

Don't name a property "key." This name is reserved for a special property used to store the
Model key. Though it may work locally, a property named "key" will prevent deployment to
App Engine.

I don't know whether we should be preventing people from using that key. @dhermes, @silvolu opinions?

Given that Python's own dict.update() doesn't return the dict instance, I can't see that making ours return it is "Pythonic": in fact, mutators which return their instance are pretty much un-Pythonic (think about the sort() or append() methods for lists, for instance).

[dhermes]

@ebbixby I am tracking issues like this in #336.

I'm closing this and adding your remarks to that thread.

1. RE: chaining, this is (sort of) being discussed in DISCUSSION: Are setter methods which clone and return object type confusing to end-users? #188. It's very JavaScript-y (not Pythonic).
2. RE: sanity checking, what did you have in mind? Could you comment on Smooth out API surfaces before M1 #336
3. RE: Protected fields, etc., the actual fields are accessed via __getitem__, not __getattr__, so there is no conflict.
4. RE: Over-all idea. If you have used ndb, the long term goal is to provide a higher-level API like that and have these classes be the underpinning.

Please re-open if you think #336 is not the right place for your concerns.

UPDATE: I forgot to say, thanks for using our library!