I do not think it's a "typing" improvement. I think what I like most in the proposal (which might be implemented differently - I am not too tied to this) is that it potentially brings huge optimisations in import times when currently a lot of imports are done unnecessarily early - slowing down startup times of tools that require parsing of python code.
There are few examples of those: * Airflow DAGs - this is one of the problems we have in Airflow (and this is I think one of the reasons why Malthe brought it) is nicely described here https://airflow.apache.org/docs/apache-airflow/stable/best-practices.html#top-level-python-code * Tools like click-complete (where autocompletion suggestions are generated based on the decorators of Python code) * Static Python Typing checks (mostly when you declare Type returned/used by function that is only used inside the function). In all those cases, you really do not care about some of the imported code that is in some kind of "internal scope" and your python parsing does not **really** need to perform the imports to do the job. * In Airflow DAGs - tasks which are defined as functions (and default arguments from the example from Malthe) are not executed at all when the DAGs are parsed by scheduler. The DAGs are parsed to get the structure of the DAG. In this case we could optimise the time it take to parse the DAG and generate the structure. * In Click-complete - we only really care about names of the parameters for functions, but static typing for the function parmeters or returned value are not needed at all to generate complete suggestions. In this case importing time is essential, because you want to provide autocomplete suggestions **really quickly** * In case of typing of parameters or return values, it leads quite often to circular imports generated. If - in your module - the only place you use a type is inside one or two functions, adding static typing involves adding top-level import for that type. And that has huge potential of generating circular imports. Before static typing in parameters or return values of those, local imports would do the job nicely, but with typing added to parameters and return values, you cannot do local imports in those functions that have those parameters or return values. This often leads to adding local imports elsewhere, but in fact a "logical" thing is that those imports should be local for the functions and any of the scopes that the functions are called. Top-level imports in this case are causing unnecessary cross-module dependencies and circular imports. And some of those problems can currently be solved with local imports - but not all (default_values case by Malthe cannot). I think this idea has really good "need" behind. Maybe the way to implement could be improved on, but I see clearly the use cases and needs the "general idea" aims to solve. _______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/ALXSM6753M7AT6MT7KVQULUCFX5G4XT7/ Code of Conduct: http://python.org/psf/codeofconduct/
