6 ms·

Strictly speaking, lists are not arrays. I'm not aware of what the specification for a list would be, this is the closest I'm aware of: https://docs.python.org

Strictly speaking, lists are not arrays. I'm not aware of what the specification for a list would be, this is the closest I'm aware of: https://docs.python.org/3/reference/datamodel.html#objects-values-and-types https://docs.python.org/3/reference/datamodel.html#objects-v..., 3.2 > Sequences > Mutable Sequences > Lists, "The items of a list are arbitrary Python objects. Lists are formed by placing a comma-separated list of expressions in square brackets" CPython implementation is here: https://github.com/python/cpython/blob/e42b705188271da108de42b55d9344642170aa2b/Include/listobject.h#L23-L40 https://github.com/python/cpython/blob/e42b705188271da108de4... If I'm talking about arrays with someone else, I would expect us to be thinking of arrays in the sense of C. Both C++ and Java use the same definition. Other languages that I'm aware of (e.g. Javascript, Go) have their own notions of arrays that you can't conflate with the C notion of an array. From the C11 spec, §6.2.5.20: "An array type describes a contiguously allocated nonempty set of objects with a particular member object type, called the element type."

webmaven 8y ago
Lists are very often used in the way arrays are, though. The heterogeneous use-case (that in C, etc. is usually a struct) is often filled by either tuples or (ordered) dictionaries in Python. If you really want something a bit closer to a C array, you can fairly easily create a UserList that enforces the non-empty requirement and only allows items of a particular type.
- dorfsmay 8y ago
  If you want some closer to C arrays, you can use Python array.array, which is part of the standard library. https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html https://stackoverflow.com/questions/176011/python-list-vs-array-when-to-use https://stackoverflow.com/questions/176011/python-list-vs-ar...
  - webmaven 8y ago
    Thanks! I had forgotten about that module.
eatitraw 8y ago
I think you have a point about C or C++ notion of arrays having the same type. I'll probably rewrite that paragraph, since the main point is to tell people unfamiliar with Python that lists aren't actually linked lists.
- Waterluvian 8y ago
  So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Then in cpython the actual list contents are Python objects sitting on the heap in a non-contiguous manner? And when the list needs to be resized and doubles itself, it's just doubling the space for object references?
  - haikuginger 8y ago
    > So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Yes. Every Python object is held by the interpreter as a pointer to a PyObject struct on the (C) heap.
    - aggerdom 8y ago
      Not something I would put into production, but had a fun application of this on a side project. I had the `id` of a function (but not the function object itself) and needed to recover the function. In CPython, `id` of a function corresponds to it's memory address (not sure if that can be overridden). By casting the id to a PyObject, I was able to recover the original. func = ctypes.cast(int(address), ctypes.py_object).value Was kinda cool actually seeing that work.
  - eatitraw 8y ago
    > Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Yep, it is an array of pointers: https://github.com/python/cpython/blob/3.7/Include/listobject.h#L23 https://github.com/python/cpython/blob/3.7/Include/listobjec... > And when the list needs to be resized and doubles itself, it's just doubling the space for object references? Basically yes. The growth pattern is not as aggressive as doubling though: https://github.com/python/cpython/blob/3.7/Objects/listobject.c#L55 https://github.com/python/cpython/blob/3.7/Objects/listobjec...

webmaven 8y ago

Lists are very often used in the way arrays are, though. The heterogeneous use-case (that in C, etc. is usually a struct) is often filled by either tuples or (ordered) dictionaries in Python. If you really want something a bit closer to a C array, you can fairly easily create a UserList that enforces the non-empty requirement and only allows items of a particular type.

dorfsmay 8y ago
If you want some closer to C arrays, you can use Python array.array, which is part of the standard library. https://docs.python.org/3/library/array.html https://docs.python.org/3/library/array.html https://stackoverflow.com/questions/176011/python-list-vs-array-when-to-use https://stackoverflow.com/questions/176011/python-list-vs-ar...
- webmaven 8y ago
  Thanks! I had forgotten about that module.

eatitraw 8y ago

I think you have a point about C or C++ notion of arrays having the same type. I'll probably rewrite that paragraph, since the main point is to tell people unfamiliar with Python that lists aren't actually linked lists.

Waterluvian 8y ago
So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Then in cpython the actual list contents are Python objects sitting on the heap in a non-contiguous manner? And when the list needs to be resized and doubles itself, it's just doubling the space for object references?
- haikuginger 8y ago
  > So... Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Yes. Every Python object is held by the interpreter as a pointer to a PyObject struct on the (C) heap.
  - aggerdom 8y ago
    Not something I would put into production, but had a fun application of this on a side project. I had the `id` of a function (but not the function object itself) and needed to recover the function. In CPython, `id` of a function corresponds to it's memory address (not sure if that can be overridden). By casting the id to a PyObject, I was able to recover the original. func = ctypes.cast(int(address), ctypes.py_object).value Was kinda cool actually seeing that work.
- eatitraw 8y ago
  > Because lists are dynamically typed and heterogeneous, does that mean the underlying C is basically a contiguous segment of memory of python object references? Yep, it is an array of pointers: https://github.com/python/cpython/blob/3.7/Include/listobject.h#L23 https://github.com/python/cpython/blob/3.7/Include/listobjec... > And when the list needs to be resized and doubles itself, it's just doubling the space for object references? Basically yes. The growth pattern is not as aggressive as doubling though: https://github.com/python/cpython/blob/3.7/Objects/listobject.c#L55 https://github.com/python/cpython/blob/3.7/Objects/listobjec...