It doesn't make sense in an structural way to be using things undefined in the parent class. However, I made it into an attribute of the parent class. This keeps it as an attribute and still makes sense in the inheritance hierarchy.
COO uses a property, whereas DOK uses an attribute. We could make COO use an attribute as well, however that seems bad since it might not match data.dtype. I chose the lowest common denominator and went for a property.
I want to have a base class that can be used to access common things. If I turn it into an attribute on DOK then I have to take it out of the base class... Which I don't want to do. Anything that is common should be in the base class.
Anything that is common should be in the base class
I would agree with this to the extent that it's convenient. It looks like by trying to make these two subclasses adhere to the same interface we're forced to increase the level of technology used by one of the subclasses. I have a (probably irrational) aversion to using more advanced features than are necessary, mostly on the grounds of avoiding complex situations and increasing maintainability.
What is dict here in Python 2? It's not a normal builtin dict object?
Ah, ok, I'm now reading about the future package. I have to admit that I am a bit hesitant to add it as a new dependency just because I haven't heard of it before. Happy to deal with this in the future though.
On Python 2.7+:
D.items() -> a set-like object providing a view on D's items
On Python 2.6:
D.items() -> an iterator over D's items
if ver == (2, 7):
elif ver == (2, 6):
elif ver >= (3, 0):
What if some other infrastrucural library (like cloudpickle, Cython, PyPy, Numba, ...) has an optimiziation that works well on objects where type(obj) is dict (this is almost certainly the case in all of those projects). Then presumably that optimization won't apply to the DOK class.
This library is aimed to be infrastructural for the ecosystem. I think that it is important that we be as non-fancy as possible. As another point, if you ever want to see this upstreamed into scipy then you'll need to convince them about this point as well and they are, in general, far more conservative than I am.
Yeah, it's a nice trick, don't get me wrong. I've just seen many many things go wrong once code like this interacts with 1000 other libraries (which again, I think is our intention). I would definitely use a library like this in application code, but for core ecosystem code I tend to be more conservative. I think that many other maintainers of core ecosystem code also hold this belief.
I would wait for someone to arrive with a memory issue before optimizing for memory constraints in this way. I don't expect this to be a significant issue in common use. Also, I don't mind Python 2 being less efficient.
* Implement inheritance hierarchy.
* Implement inheritance hierarchy.
* Make shape an attribute and move it to the base class.
* Delete useless properties.
* Make dtype into a property of the parent class.
* Removed six dependency and added some basic memory
Py 2/3 optimisations.
* Documentation for SparseArray.
* Make dtype into an attribute for DOK.
* Rename py23 to compatibility
This is a more common name for this file in standard projects.
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.