Message107668
I have made my mind on subclassing timezone issue. I believe subclassing should not be allowed and here is the reason:
The new datetime.timezone class is a very specific implementation of tzinfo interface. It guarantees that utcoffset(dt) and friends return the same value for all times. Applications should be able to rely on this and a simple isinstance(tz, timezone) should be enough to deduce that tz is a fixed offset tzinfo instance. (Of course careful applications can check type(tz) == timezone instead, but making isinstance(tz, timezone) subtly wrong is not a good idea.)
There is also very little to be gained from subclassing timezone. It defines only 4 methods and each is entirely trivial. Any non-trivial tzinfo implementation will need to override all 4 of them anyways. It is much safer to derive from tzinfo directly and possible reuse timezone through containment (for example to format offsets in a standard way.)
The only immediate application of subclassing is to add dst() method returning a fixed offset rather than None. This is trivial to implement through containment and if such class becomes popular, I would prefer to add this functionality to timezone class itself. |
|
Date |
User |
Action |
Args |
2010-06-12 16:14:03 | belopolsky | set | recipients:
+ belopolsky, tim.peters, doerwalter, brett.cannon, mark.dickinson, ggenellina, pitrou, techtonik, ajaksu2, kawai, eric.araujo, r.david.murray, rafe, daniel.urban, l0nwlf, akira |
2010-06-12 16:14:03 | belopolsky | set | messageid: <1276359243.42.0.497069487211.issue5094@psf.upfronthosting.co.za> |
2010-06-12 16:14:01 | belopolsky | link | issue5094 messages |
2010-06-12 16:14:00 | belopolsky | create | |
|