On Wed, Nov 13, 2013 at 12:31 AM, Vajrasky Kok <[email protected]>wrote:
> Greetings, friends! > > We just added lru_cache in Django. > https://github.com/django/django/commit/9b7455e918a437c3db91e88dcbf6d9c93fef96f8 > > As you can see in django/utils/lru_cache.py, if Python is not shipped > with lru_cache (Python 3.1 for example), we provide lru_cache for them. > This lru_cache is just a backport from Python 3.3 lru_cache. > http://code.activestate.com/recipes/578078-py26-and-py30-backport-of-python-33s-lru-cache/ > > The problem happens if we use Python 3.2. Python 3.2 comes with lru_cache > which is inferior from our lru_cache. > http://hg.python.org/releasing/3.2.4/file/7680dbf5cb3f/Lib/functools.py. > Should we detect this corner case so if user uses Python 3.2, we overshadow > their "inferior" lru_cache? > > According to Raymond Hettinger (Python core developer) who wrote lru_cache: > > "The Python 3.3 version was also refactored, beautified, and optimized. It > consumes less memory than the 3.2 version. It makes half as many hash > calls." > > In my opinion, we should just use "inferior" version of lru_cache in > Python 3.2 I bet the difference would be unnoticeable. But I am just > curious what Django developers think about this. > Hi Vajrasky, As a library, Django is at the start of the Python 3 transition. Python 3.3 was released *before* Django 1.5 - the first release of Django that officially supported Python 3. Most Django users moving to Python 3 will be adopting Python 3.3, not earlier releases. Therefore the set of people we're talking about here is small to start with. In order to do what you're proposing, we're going to need a complex mechanism to implement this -- Ok, not unbelievably complex, but certainly more complex than the current implementation of "if it doesn't exist, you can get it here". And, at some point in the not too distant future, we're going to drop support for Python 3.2. So - we've got a moderately complex implementation, which will be used by a very small audience, which won't be needed in the near(ish) future. You're completely correct that there would be a performance boost for people using Python 3.2 if we overrode lru_cache. However, unless that performance boost is significant (by which I mean making the difference between Python 3.2 being a viable platform for deployment, not just a 2% performance bump) I'm just not sure it's worth the effort to build and maintain the feature for the set of people that need/want it. Yours, Russ Magee %-) -- You received this message because you are subscribed to the Google Groups "Django developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/CAJxq84-f%3DwT3TMqYFFgrqRQQoR6%3Dm0LNOSg%2B_xoaRY%2BWfg1gww%40mail.gmail.com. For more options, visit https://groups.google.com/groups/opt_out.
