Author belopolsky
Recipients ajaksu2, belopolsky, brett.cannon, doerwalter, eric.araujo, ggenellina, kawai, pitrou, rafe, vstinner
Date 2010-05-25.04:14:28
SpamBayes Score 0.000664784
Marked as misclassified No
Message-id <1274760870.5.0.40046272125.issue5094@psf.upfronthosting.co.za>
In-reply-to
Content
> We didn't do a singleton because I don't like singletons. =) Plus they
> muck with isinstance/issubclass if you don't expose the class.

I am not sure what you mean by "muck with."  Why would anyone want to subclass UTC?

> Basically there is no need to have it be a singleton, so why bother?

There are several advantages of having all datetime instances with tzinfo=UTC() referring to the same instance:

1. Comparison (and I believe subtraction) of aware datetime instances bypasses calculation of utcoffset if their tzinfo attributes refer to the same object.

2. With the current patch,

>>> set(UTC() for i in range(3))
set([<datetime.UTC object at 0x1015aac80>, <datetime.UTC object at 0x1015aad00>, <datetime.UTC object at 0x101a0e040>])

I don't think this is intended.  Basically UTC() instances cannot be meaningfully compared or used as dictionary or set keys.  You can fix it by providing custom __eq__ and __hash__, but this problem simply goes away if a singleton is exposed instead.

3. now(utc) is slightly more readable than now(UTC())

4. Singleton utc is familiar to pytz users.
History
Date User Action Args
2010-05-25 04:14:30belopolskysetrecipients: + belopolsky, doerwalter, brett.cannon, ggenellina, pitrou, vstinner, ajaksu2, kawai, eric.araujo, rafe
2010-05-25 04:14:30belopolskysetmessageid: <1274760870.5.0.40046272125.issue5094@psf.upfronthosting.co.za>
2010-05-25 04:14:29belopolskylinkissue5094 messages
2010-05-25 04:14:28belopolskycreate