> From Marc-Andre Lemburg, I understand that Paul's PR is a good
> compromise and that other datetime implementations which cannot use
> tzidx() cache (because it's limited to an integer in [0; 254]) can
> subclass datetime or use a cache outside datetime.
One idea that we can put out there (thoug
Le ven. 10 mai 2019 à 09:22, M.-A. Lemburg a écrit :
> Given that many datetime objects in practice don't use timezones
> (e.g. in large data stores you typically use UTC and naive datetime
> objects), I think that making the object itself larger to accommodate
> for a cache, which will only be us
On 10.05.2019 02:58, Paul Ganssle wrote:
> This is only "only" for dateutil in the sense that no one other than
> dateutil implements tzinfo with the interface provided. If dateutil were
> /not/ already implemented with a list of offsets and their indexes, I
> would still propose this, and just re-
This is only "only" for dateutil in the sense that no one other than
dateutil implements tzinfo with the interface provided. If dateutil were
/not/ already implemented with a list of offsets and their indexes, I
would still propose this, and just re-write dateutil to take advantage
of it. From a cu
Hi Paul,
The change is basically an optimization. I'm uncomfortable to design
it "only" for dateutil. What if tomorrow someone has to store an
arbitrary Python object, rather than just an integer (in range [0;
254]), into a datetime for a different optimization?
Moreover, I dislike adding a *publ
