Possible regression on namespace-module symbol binding about libpython-clj HOT 3 CLOSED

This is possibly more correct behavior although I don't know. I switched to 'alias' instead of 'intern' as that is what the actual clojure require uses:

libpython-clj.python> (require '[tech.v2.datatype :as dtype])
nil
libpython-clj.python> dtype
Syntax error compiling at (*cider-repl cnuernber/libpython-clj:localhost:41687(clj)*:1:8006).
Unable to resolve symbol: dtype in this context 

from libpython-clj.

Hmm interesting point. The Python behavior is bind the module.

>>> import sys
>>> sys
<module 'sys' (built-in)>

The Clojure behavior is to NOT bind the namespace to a symbol

(require 'clojure.string)
clojure.string
Syntax error (ClassNotFoundException) compiling at (src/python/dev.clj:0:0).
clojure.string

I guess we'll need to make a determination about which behavior to choose.

from libpython-clj.

I think we should probably default to the Clojure behavior since we will eventually be bringing on other languages (R, Julia, JavaScript, Rust) etc, and each will have their own convention. So perhaps the default should be to stick to the Clojure convention (although personally I'd like to suggest a :bind-ns flag to avoid a redundant py/import-module call.

from libpython-clj.