PEP 615: Support for the IANA Time Zone Database in the Standard Library

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 unpickled ZoneInfo 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 unpickled ZoneInfo 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?

1 Like