python-internals

Fowler's Extract Variable refactoring method, formerly Introduce Explaining Variable , says use a temporary variable to make code clearer for humans. The idea is to elucidate complex code by introducing an otherwise unneeded local variable, and naming that variable for exposition purposes. It also advocates this kind of explaining over comments.. Other languages optimize away temporary variables so there's no cost in time or space resources. Why doesn't Python do this? In [3]: def multiple_of_six_fat(n): ...: multiple_of_two = n%2 == 0 ...: multiple_of_three = n%3 == 0 ...: return multiple_of

PEP 424 mentions in the "Rationale" that: Being able to pre-allocate lists based on the expected size, as estimated by __length_hint__ , can be a significant optimization. CPython has been observed to run some code faster than PyPy, purely because of this optimization being present. So I asked myself the question that I'm now asking here: Is it possible to speed up some iterable class processing an iterator (when it's possible to correctly predict it's "length") based on this knowledge? Setting aside the generator/iterator terminology confusion, the __length_hint__ method is a really minor

I am trying to embed a python program inside a C program. My OS is Ubuntu 14.04 I try to embed python 2.7 and python 3.4 interpreter in the same C code base (as separate applications). The compilation and linking works when embedding python 2.7 but not for the python 3.4. It fails during the linker stage. Here is my C code (just an example not real code) simple.c #include <stdio.h> #include <Python.h> int main(int argc, char *argv[]) { PyObject *pName, *pModule, *pFunc, *pValue; char module[] = "get_version"; char func[] = "get_version"; char module_path[] = "."; Py_Initialize(); PyObject *sys

Recently I read the "Fluent python" and understood how == operator works with python objects, using __eq__() method. But how it works with int instances in python2? >>> a = 1 >>> b = 1 >>> a == b True >>> a.__eq__(b) Traceback (most recent call last): File "<stdin>", line 1, in <module> AttributeError: 'int' object has no attribute '__eq__' in python3 all a.__eq__(b) returns True Blender Python prefers to use rich comparison functions ( __eq__ , __lt__ , __ne__ , etc.), but if those don't exist, it falls back to using a single comparison function ( __cmp__ , removed in Python 3): These are the

In the past, when I've needed array-like indexical lookups in a tight loop, I usually use tuples, since they seem to be generally extremely performant (close to using just n-number of variables). However, I decided to question that assumption today and came up with some surprising results: In [102]: l = range(1000) In [103]: t = tuple(range(1000)) In [107]: timeit(lambda : l[500], number = 10000000) Out[107]: 2.465047836303711 In [108]: timeit(lambda : t[500], number = 10000000) Out[108]: 2.8896381855010986 Tuple lookups appear to take 17% longer than list lookups! Repeated experimentation

Consider: >>> timeit.timeit('from win32com.client import Dispatch', number=100000) 0.18883283882571789 >>> timeit.timeit('import win32com.client', number=100000) 0.1275979248277963 It takes significantly longer to import only the Dispatch function rather than the entire module, which seems counter intuitive. Could someone explain why the overhead for taking a single function is so bad? Thanks! That's because: from win32com.client import Dispatch is equivalent to: import win32com.client #import the whole module first Dispatch = win32com.client.Dispatch #assign the required attributes to global