
Hello, On Tue, 19 Jan 2021 14:31:49 +1300 Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 19/01/21 1:13 pm, Inada Naoki wrote:
I don't want to import modules used only in type hints. I don't want to import even "typing".
How about having a pseudo-module called __typing__ that is ignored by the compiler:
from __typing__ import ...
would be compiled to a no-op, but recognised by type checkers. If you want to do run-time typing stuff, you would use
Please don't limit it to just "typing". There's a need for a module which would handle "language-level" features, to not put newly added things in the global namespace. By analogy with __future__, such a module could be named __present__. Alternative names would be "lang" or "python". But analogy with __future__ is helpful, as there should be a place for "pragma imports", which would change behavior of the programs, like imports from __future__ do, except that features in __future__ are destined to be "switchable" only temporary and become default later. Breaking backward compatibility with each version has already become a norm, but going further, even more radical changes would be required, and so it should be possible to either enable or disable them, as part of the standard, not temporary, language semantics, hence the idea of __present__ as alternative to __future__.
from typing import ...
-- Greg
[] -- Best regards, Paul mailto:pmiscml@gmail.com