On Mon, Oct 14, 2019 at 10:14 PM Steve Jorgensen
Assuming `Scalar` can't clean up every case we can imagine for this kind of ambiguity can come up with doesn't mean it's not potentially very helpful. After the discussion so far, I happen to still feel like this is a compelling idea that I'd like to see implemented.
The problem with special-casing is when interfacing between different bodies of code. That is to say, using libraries or writing libraries for others to use. Having a central `Scalar` class that different bodies of code can register their classes to be provides a clean way for bodies of code to share this information without having to actually know ahead of time which other bodies of code in an integrated application might need to use that information.
You're assuming that everyone's definition of Scalar will be the same, though. I haven't seen that proven. In many cases, the correct check is "is iterable but is not str". In others, it's "is iterable but is not (str,bytes)". Some will see an os.stat() result as atomic, some won't. Some will see a tuple as atomic, some won't. Which ones should be registered as Scalar? What exactly is the type's definition? ChrisA