Repository navigation
Consider Abstract Base Classes for Quantity and Unit #3650
Description
Activity
To be clear, I didn't suggest a _meta_class, just an abstract base class.
By the way, if we created an ABC for Quantity-like, you can define something like:
@classmethod def __instancecheck__(cls, inst): if hasattr(inst, 'unit') and isinstance(inst.unit, Unit): return True else: return super(QuantityLike, cls).__instancecheck__(inst)
That way
isinstance(obj, QuantityLike)will work even for objects of classes that don't explicitly inherit fromQuantityLike(as long as they've been registered withQuantityLike.register()). If you want to require a.to()method that's fine too, though you would also want to define that as an abstractmethod.And yeah, if you wanted to extend the concept to optionally support other unit frameworks that might work too.
- changed the title
[-]Consider Meta-classes for Quantity and Unit[/-][+]Consider Abstract Base Classes for Quantity and Unit[/+]on Apr 1, 2015 @embray - don't know what it is that I keep mixing up the Meta and Abstract Base Classes; they really have nothing to do with each other! Maybe it is just that I never had to think about Meta classes yet. Anyway, now updated the title and first entry, so that it is clear what this is about.
I think for units there is a bit more of a need: I rather dislike the duck-typing I had to use in #1894.
👍 I think this would make things clearer.
Issue #6517 reminded me that this is still useful. As @maxnoe wrote:
"""
The base siunits are of classIrreducibleUnit, which does not inherit fromUnit, which leads to some highly unexpected results.>>> isinstance(u.m, u.Unit) False >>> isinstance(u.cm, u.Unit) True >>> isinstance(u.V, u.Unit) True >>> isinstance(u.A, u.Unit) False"""
An ABC would not necessarily solve this directly, but at least we could tell people whatisiinstanceto use.Reacted by Nathaniel StarkmanOne larger comment, perhaps for @mhvk. Our unit system doesn't have a singular base class. We often write UnitBase, but not everything inherits from it. Perhaps we should add a base class from which all unit classes (including UnitBase) inherit. I would suggest calling it AbstractUnit as it's an ABC and this follows the abstract/concrete naming distinction. This will enable correct typing without impacting existing code. I don't think this should impact this Pull Request as it's very easy to do a find-replace on : UnitBase
I think it would be easy to write an ABC with nothing on it, then add abstractmethods as we encounter them while typing. e.g. as noticed in @eerovaher's PR.
Following discussion on how to let
Timeinteract with units without relying overly on ducktyping, @embray suggested (#3648 (comment)) aQuantityabstract base class, with which objects could register to let other code know they can be treated as quantities with a unit. ForUnititself, this would also be useful, in particular for things like functional units which share many but not all of the properties of normal units (see#1894 (comment)). This issue is to remind us of these thoughts.
p.s. Such a base class might also go quite a long way towards ensuring interoperability with other unit implementations (such as that by
amuse).