Le ven. 10 mai 2019 à 09:22, M.-A. Lemburg <m...@egenix.com> 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 used a smaller percentage of the use > cases, isn't warranted. Going from 64 bytes to 72 bytes also sounds > like this could have negative effects on cache lines. > > If you need a per object cache, you can either use weakref > objects or maintain a separate dictionary in dateutil or other > timezone helpers which indexes objects by id(obj). > > That said, if you only add a byte field which doesn't make the object > larger in practice (you merely use space that alignments would > use anyway), this shouldn't be a problem. The use of that field > should be documented, though, so that other implementations can > use/provide it as well.
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. Note: right now, creating a weakref to a datetime fails. Victor -- Night gathers, and now my watch begins. It shall not end until my death. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
