Open oberstet opened 4 years ago
Adding slots is a bit of a challenge here. for each property we set a "private" counterpart of it. So for a property timestamp
we have a _timestamp
that gets set to None
in the constructor. Then the setter for timestamp also assigns to that internal property. So we would need to add both _timestamp
and timestamp
to the __slots__
tuple.
@oberstet is that desirable/expected ?
Good question! In a way, the general question actually is:
How to combine
in Python, and if that is useful / desirable in the first place. Let's first find the answer to that ..
Is the point of the _timestamp
with @property
versions to enforce "it must be of type X" when setting..? (e.g. here https://github.com/crossbario/cfxdb/blob/edf5603e83b2ae6e48568440da0b470a813774af/cfxdb/eventstore/event.py#L41)
the reason to have both _attribute
and @property
is so that _attribute
is lazily caching the actual value from the DB as a python native type (on first access)
rgd the specific domain of walltime/timestamps (the example you linked): this has evolved in xbr db classes to:
that is, accessing offers[txn, offer_oid].timestamp
returns a native np.datetime64
python object that will be stored in object._timestamp
upon first access.
there have been a handful reason why it has evolved into that (could expand if of interest) .. the example you linked is not xbr, but from event store (wamp event persistency), and this predates the xbr stuff where "timestamp" has evolved. another example is UUID - also https://github.com/crossbario/cfxdb/issues/38
The DB table classes currently lack slots (as in eg https://github.com/crossbario/autobahn-python/blob/5b3f28549f48fc0f3df54512dd6a2eb1826fbcd2/autobahn/wamp/message.py#L540).
We should use slots - part of the reasons is that it avoids accidently setting a non-existing attribute