[ENH] Compilation does not support importing cython module from another module

[matusvalo]

Is your feature request related to a problem? Please describe.

Consider following situation:

######## py_module.py #######
import cython
####### cy_module.py ########
from py_module import cython

def main():
    a: cython.int = 5
    print(a + 1)

When compiling Cython ignores cython.int annotation because it does not recognise cython module even though from Python semantics the correct cython module is imported.

Describe the solution you'd like.

Importing cython module recognise cython module during compilation even not imported directly. The behaviour will match python semantics.

Describe alternatives you've considered.

I suppose implementing this issue 100% correctly is complex - cython needs to execute real import and check whether cython module is cython's one. Maybe the initial sufficient solution is just to consider cython module imported when cython name is present in import:

• from dummy import cython
• from dummy.subdummy import cython
• from dummy.cython import int

In all these cases, compiler will consider imported cython module even though it is never checked what is inside module.

Of coarse this logic will apply only for compilation and should be explicitly documented. Maybe this logic can be driven by a directive...

Additional context

This feature seems to be desired from users of cython - see:

• Migrate to "pure Python" Cython mode where applicable falconry/falcon#2189 (comment)
• https://github.com/sqlalchemy/sqlalchemy/blob/d3222a31b8df97a454b37a32881dd484a06e5742/lib/sqlalchemy/engine/_processors_cy.py#L16-L24

[da-woods]

I think https://github.com/sqlalchemy/sqlalchemy/blob/d3222a31b8df97a454b37a32881dd484a06e5742/lib/sqlalchemy/engine/_processors_cy.py#L16-L24 is more related to #1981

What they're really looking for is the ability to work uncompiled and in environments without Cython (where import cython will fail completely)

[da-woods]

Looking at the "Falconry" issue I think they're trying to do the same thing and essentially provide their own copy of "Shadow.py". I can see why they're doing it, but I still think the right solution is to distribute "Shadow.py" as a lightweight standalone package that people are happy to have as a runtime requirement rather than to try to follow imports through Python modules.

[scoder]

I agree that we should rather do #1981 than tracking arbitrary (runtime) imports across modules, including modules that are not even compiled, that might not be available at build time, or that happen to have the word cython in them.

[matusvalo]

Now when I am looking at it again, I agree with @da-woods and @scoder. I think closing #1981 will eventually close this issue.