Le ven. 10 mai 2019 à 09:22, M.-A. Lemburg <mal at 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.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4