I have some questions about the cache. You describe how ZoneInfo(key)
must use a cache (I think about the only freedom is whether it’s a plain dict or a weak value dict – it can’t even be an LRU cache since evictions would break the required semantics). You also describe how ZoneInfo.nocache(key)
returns a new object each time (not consulting the cache).
-
What’s not 100% crystal clear is whether the new object created by
ZoneInfo.nocache()
is entered into the cache. Not doing this seems to make the most sense, but it’s not explicit. -
Ditto for
ZoneInfo.from_file()
. -
Perhaps more importantly, I found no mention of the cache in the section about pickling. I presume that the most common case is that a pickled
ZoneInfo
object is in fact identical to one with the same key read from the current tz database (this will be the case e.g. if pickles are used for RPC within one host). But I can easily see an application mixing locally-created datetime objects with ones received from a pickle, and those wouldn’t be comparable because the tzinfo objects would have different identities. Ditto for timezones unpickled from different pickles – the nice identical-object caching used by pickle doesn’t work across pickles (for obvious reasons). And because you don’t guarantee that an unpickledZoneInfo
object contains the same information as one created locally from the same key (the latter being what’s in the cache) you can’t enter unpickledZoneInfo
objects in the cache either.
For the latter issue, I don’t see an easy way out other than adopted your rejected proposal of pickling only the key as state. I understand that this means sometimes unpickling will fail (in particular if there’s no key or if the key doesn’t exist in the tz database where it is being unpickled). I see this as little different from unpickling some pickle that contains a reference to a class or function (which is represented as the fully qualified name of its definition) if there is no corresponding definition.
In fact, this points towards a reasonable mental model for ZoneInfo
objects as similar to class or function definitions. ZoneInfo
objects created bypassing the cache (using nocache()
or from_file()
) are similar to dynamically created classes or functions – these don’t have a global name and cannot be pickled.
Thoughts?