Should we care about performance in not-so-updated Python3 (Python 3.2)?

[Vajrasky Kok]

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.

Cheers,
Vajrasky

[Russell Keith-Magee]

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 %-)