python-internals

Which approach is better? Using a tuple, like: if number in (1, 2): or a list, like: if number in [1, 2]: Which one is recommended for such uses and why (both logical and performance wise)? The CPython interpreter replaces the second form with the first . That's because loading the tuple from a constant is one operation, but the list would be 3 operations; load the two integer contents and build a new list object. Because you are using a list literal that isn't otherwise reachable, it is substituted for a tuple: >>> import dis >>> dis.dis(compile('number in [1, 2]', '<stdin>', 'eval')) 1 0

I've been trying to learn how CPython is implemented under the scenes. It's great that Python is high level, but I don't like treating it like a black box. With that in mind, how are tuples implemented? I've had a look at the source (tupleobject.c) , but it's going over my head. I see that PyTuple_MAXSAVESIZE = 20 and PyTuple_MAXFREELIST = 2000 , what is saving and the "free list"? (Will there be a performance difference between tuples of length 20/21 or 2000/2001? What enforces the maximum tuple length?) As a caveat, everything in this answer is based on what I've gleaned from looking over

A reasonably common operation is to filter one list based on another list . People quickly find that this: [x for x in list_1 if x in list_2] is slow for large inputs - it's O(n*m). Yuck. How do we speed this up? Use a set to make filtering lookups O(1): s = set(list_2) [x for x in list_1 if x in s] This gives nice overall O(n) behavior. I however often see even veteran coders fall into The Trap ™: [x for x in list_1 if x in set(list_2)] Ack! This is again O(n*m) since python builds set(list_2) every time, not just once. I thought that was the end of the story - python can't optimize it away

I understand that ".pyc" files are compiled versions of the plain-text ".py" files, created at runtime to make programs run faster. However I have observed a few things: Upon modification of "py" files, program behavior changes. This indicates that the "py" files are compiled or at least go though some sort of hashing process or compare time stamps in order to tell whether or not they should be re-compiled. Upon deleting all ".pyc" files ( rm *.pyc ) sometimes program behavior will change. Which would indicate that they are not being compiled on update of ".py"s. Questions: How do they decide

I have inherited some Python code which is used to create huge tables (of up to 19 columns wide by 5000 rows). It took nine seconds for the table to be drawn on the screen. I noticed that each row was added using this code: sTable = sTable + '\n' + GetRow() where sTable is a string. I changed that to: sTable += '\n' + GetRow() and I noticed that the table now appeared in six seconds . And then I changed it to: sTable += '\n%s' % GetRow() based on these Python performance tips (still six seconds). Since this was called about 5000 times, it highlighted the performance issue. But why was there

This message is a a bit long with many examples, but I hope it will help me and others to better grasp the full story of variables and attribute lookup in Python 2.7. I am using the terms of PEP 227 ( http://www.python.org/dev/peps/pep-0227/ ) for code blocks (such as modules, class definition, function definitions, etc.) and variable bindings (such as assignments, argument declarations, class and function declaration, for loops, etc.) I am using the terms variables for names that can be called without a dot, and attributes for names that need to be qualified with an object name (such as obj.x