Redo edgedb basic types to inherit from builtin types
- [x]
edgedb.Tupleistuple-
weakref.ref()will stop working onedgedb.Tupleobjects.
-
- [x]
edgedb.NamedTupleis a subclass oftuple- Actual named tuple objects will be an instance of a transient heap type
DerivedNamedTuple(subclass ofedgedb.NamedTuple) -
weakref.ref()will stop working onedgedb.NamedTupleobjects.
- Actual named tuple objects will be an instance of a transient heap type
- [ ]
edgedb.Setis a subclass oftuple - [ ]
edgedb.Arrayis a subclass oftuple - [ ] link and linkprop?
https://github.com/edgedb/edgedb-python/blob/dfb8c8b009838eec44a312d467edd4782197897f/edgedb/datatypes/array.c#L47
Will other types from stdlib such as arrays inherit from builtin?
Will other types from stdlib such as arrays inherit from builtin?
Yes, but array may just be a subclass of tuple because it's immutable.
Yes, but array may just be a subclass of
tuplebecause it's immutable.
Has it always been immutable? I thought EdgeQL supported mutation to the shape and size of arrays.
Has it always been immutable?
Oh this PR is the edgedb-python construct of arrays only in query results, it was and will be immutable.
Why can't we use the builtin tuple type for our tuples? The __repr__ is basically compatible, so maybe just drop our custom tuple implementation and use the builtin one? It has a freelist optimization.
Has it always been immutable?
Oh this PR is the edgedb-python construct of arrays only in query results, it was and will be immutable.
UPDATE: we decided to use plain Python list for edgedb.Set and edgedb.Array, so the query results will be partially mutable, but again that's just in user memory.
UPDATE: we decided to use plain Python list for edgedb.Set and edgedb.Array, so the query results will be partially mutable, but again that's just in user memory.
Does the builtin list object support the same optimisation as before? Does this improve querying perf?
UPDATE: we decided to use plain Python list for edgedb.Set and edgedb.Array, so the query results will be partially mutable, but again that's just in user memory.
Does the builtin list object support the same optimisation as before? Does this improve querying perf?
The main optimization is still here, which is using the C API PyList_SET_ITEM for fast initialization, but we lost the (cached) hashing function, which is not a critical use. Also we lost the freelist of array, which may have slight performance impact when arrays are frequently (re-)allocated. Other than that, query performance should not be affected, I’ll run benchmarks to test it.
I'd love to hear more about the benchmarks once they're available. This sounds like a great change if memory allocation doesn't prove to be too impactful for builtin inheritance. Great stuff @fantix ❤️
@i0bs benchmark updated