Hi Stuart.  Hope all is well.

When last we spoke, we got the UTC timezone to be picklable. I'd like to let pytz timezones pickle also (so we can persist a user's preferred timezone). While I could keep the timezone name around, I'd prefer to keep the timezone object itself.

Adding a reduce to tzinfo.py's BaseTZInfo, a la

class BaseTzInfo(tzinfo):
    # Overridden in subclass
    _utcoffset = None
    _tzname = None
    zone = None

    def __str__(self):
        return self.zone

    def __reduce__(self):
        return self.__class__.__name__

accomplishes this for all of the included timezones. It would break if someone tried to use the __init__ arguments in DstTzInfo, but grep tells me that nothing is doing that right now in the package.

Therefore, I propose the following:

- add a __reduce__ as shown above

- eliminate the __init__ arguments in DstTzInfo since they are not used and would break pickling if they were

- document and test the contract that the timezones may be pickled, and that loading the pickle returns the same original instance (i.e., it's a singleton)

On a somewhat unrelated note, I noticed that dst() and tzname() were not implemented per the standard library's spec; upon reflection, I decided that this might be because the Olson database made this difficult or impossible. Feel free to clarify or not; the point is that I would like to use a name for the timezone, and the 'zone' attribute seems to do enough what I want, even though it is not daylight-savings aware.

Therefore I further propose that the zone attribute be exposed in docs as a reliable attribute of the pytz timezones, and the key through which it is accessible from pytz.timezone.

If that is a contract, BaseTZInfo's __reduce__ could instead

    return pytz.timezone, (self.zone)

, which might be more forward compatible (and not require DstTzInfo's __init__ signature to change).




Zope3-dev mailing list
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com

Reply via email to