Alexander Belopolsky <belopol...@users.sourceforge.net> added the comment:
> 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue5094> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
