<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<p>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.</pre>
</blockquote>
<br>
One idea that we can put out there (though I'm hesitant to suggest
it, because generally Python avoids this sort of language
lawyering anyway), is that I think it's actually fine to allow the
situations under which `tzidx()` will cache a value could be
implementation-dependent, and to document that in CPython it's
only integers in [0; 254].<br>
<br>
The reason to mention this is that I suspect that PyPy, which has
a pure-python implementation of datetime, will likely either
choose to forgo the cache entirely and always fall through to the
underlying function call or cache <i>any</i> Python object
returned, since with a pure Python implementation, they do not
have the advantage of storing the tzidx cache in an unused padding
byte.<br>
<br>
Other than the speed concerns, because of the fallback nature of
datetime.tzidx, whether or not the cache is hit will not be
visible to the end user, so I think it's fair to allow interpreter
implementations to choose when a value is or is not cached
according to what works best for their users.<br>
</p>
<div class="moz-cite-prefix">On 5/13/19 7:52 PM, Victor Stinner
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+3bQGHjCJ83TSP4c_H4S7-kPR=BrR2FPa3SJFjXOuUJFJ+Sog@mail.gmail.com">
<pre class="moz-quote-pre" wrap="">Le ven. 10 mai 2019 à 09:22, M.-A. Lemburg <a class="moz-txt-link-rfc2396E" href="mailto:mal@egenix.com"><mal@egenix.com></a> a écrit :
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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
</pre>
</blockquote>
</body>
</html>