type hinting backward compatibility with python 3.0 to 3.4
On Sun, May 21, 2017 at 2:38 AM, Chris Angelico <rosuav at gmail.com> wrote:
> On Sun, May 21, 2017 at 7:29 PM, bartc <bc at freeuk.com> wrote:
> > They might be /created/ at runtime, but it's a pretty good bet that the
> > A in this declaration:
> > class A...
> > is the name of a class. The question in Python, as always, is whether an
> > used as the name of a type in a type, is still this same A. And
> > such a type hint can precede the declaration of A.
> > In fact the declaration of A might be in a different module from its use
> > a type hint, which means that, in the CPython byte-code compiler anyway,
> > is not visible at compile-time, when type hints could best be put to good
> > effect.
> That isn't a problem - mypy follows imports. It'd be pretty useless if
> it didn't :)
> > Furthermore, both A, and the type-hinting code, might be conditional. So
> > that on Tuesdays, A is a class, the rest of the week it's the name of a
> > module.
> Or, more plausible example: on platforms that have a system-provided
> source of entropy, random.random is an instance of SystemRandom, but
> on those that don't, it's an instance of DeterministicRandom with an
> arbitrarily-chosen seed. The two will have slightly different APIs.
> > Python doesn't make things easy.
> Python makes things flexible, which has a cost.
Perhaps a good way to distinguish between a class that can be used as a
type and a class
that cannot be used as a type would be to require some sort of dunder
defined on the type class. At first I was thinking `__type__`, but then I
already in use. maybe something as simple as `__hint__`.
That or only allow classes that inherit from `type` to be used in type
I'm just spit balling ideas here.