python-internals

问题 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? 回答1:

问题 I was reading some code that looked basically like this: class Foo(object): class_name = __module__.replace('_', '-') To me, that looked really weird ( __module__ , what is that?) so I went and looked at the python data-model. A quick search shows that __module__ is a property of class objects and of function objects. However, there is no __module__ available in the global namespace (as can easily be verified by just trying to look at it and observing the NameError that results ...). I

问题 I've been playing with Python's hash function. For small integers, it appears hash(n) == n always. However this does not extend to large numbers: >>> hash(2**100) == 2**100 False I'm not surprised, I understand hash takes a finite range of values. What is that range? I tried using binary search to find the smallest number hash(n) != n >>> import codejamhelpers # pip install codejamhelpers >>> help(codejamhelpers.binary_search) Help on function binary_search in module codejamhelpers.binary

问题 Why does the following behave unexpectedly in Python? >>> a = 256 >>> b = 256 >>> a is b True # This is an expected result >>> a = 257 >>> b = 257 >>> a is b False # What happened here? Why is this False? >>> 257 is 257 True # Yet the literal numbers compare properly I am using Python 2.5.2. Trying some different versions of Python, it appears that Python 2.3.3 shows the above behaviour between 99 and 100. Based on the above, I can hypothesize that Python is internally implemented such that

问题 If I take a simply and empty numpy array i can see it has 96 bytes of overhead, >>> sys.getsizeof( np.array([]) ) 96 What is that 96 bytes storing? Where in the C source for numpy or Python 3 (cpython) is this set up? 回答1: Array is present in C sources in numpy/core/include/numpy/ndarraytypes.h See: https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/ndarraytypes.h Looks like it has several pointers, number of dimensions and PyObject_HEAD, which all may in total count to

问题 Apparently list(a) doesn't overallocate, [x for x in a] overallocates at some points, and [*a] overallocates all the time ? Here are sizes n from 0 to 12 and the resulting sizes in bytes for the three methods: 0 56 56 56 1 64 88 88 2 72 88 96 3 80 88 104 4 88 88 112 5 96 120 120 6 104 120 128 7 112 120 136 8 120 120 152 9 128 184 184 10 136 184 192 11 144 184 200 12 152 184 208 Computed like this, reproducable at repl.it, using Python 3. 8 : from sys import getsizeof for n in range(13): a =

问题 Apparently list(a) doesn't overallocate, [x for x in a] overallocates at some points, and [*a] overallocates all the time ? Here are sizes n from 0 to 12 and the resulting sizes in bytes for the three methods: 0 56 56 56 1 64 88 88 2 72 88 96 3 80 88 104 4 88 88 112 5 96 120 120 6 104 120 128 7 112 120 136 8 120 120 152 9 128 184 184 10 136 184 192 11 144 184 200 12 152 184 208 Computed like this, reproducable at repl.it, using Python 3. 8 : from sys import getsizeof for n in range(13): a =

问题 Why does Python return True when I compare int and float objects which have the same value? For example: >>> 5*2 == 5.0*2.0 True 回答1: It's not as simple as a type conversion. 10 == 10.0 delegates to the arguments' __eq__ methods, trying (10).__eq__(10.0) first, and then (10.0).__eq__(10) if the first call returns NotImplemented . It makes no attempt to convert types. (Technically, the method lookup uses a special routine that bypasses instance __dict__ entries and __getattribute__ / __getattr

问题 I read the official documentation of collections.namedtuple today and found _tuple in the __new__ method. I did not find where the _tuple was defined. You can try running the code below in Python, it does not raise any error. >>> Point = namedtuple('Point', ['x', 'y'], verbose=True) class Point(tuple): 'Point(x, y)' __slots__ = () _fields = ('x', 'y') def __new__(_cls, x, y): 'Create a new instance of Point(x, y)' return _tuple.__new__(_cls, (x, y)) # Here. Why _tuple? Update: What are the

问题 First, let me show a experiment I do: In [69]: dis.dis(lambda : 4 / 2 + 1.5 * 2 + (4 - 2)) 1 0 LOAD_CONST 1 (4) 3 LOAD_CONST 2 (2) 6 BINARY_DIVIDE 7 LOAD_CONST 4 (3.0) 10 BINARY_ADD 11 LOAD_CONST 5 (2) 14 BINARY_ADD 15 RETURN_VALUE As you can see in the output of dis.dis , 1.5 * 2 and 4 - 2 get compiled to LOAD_CONST instead of two LOAD_CONST followed by a binary operation. But 4 / 2 is not replaced with something like LOAD_CONST 4 (2) . I wonder why is division left out in the optimisation.