alpha-load-ns-classes upgrades about libpython-clj HOT 7 CLOSED

After some discussion, the current proposal is:

• (require-python 'module.class) will make module.class available in the calling *ns*,
• the default behavior of invoking (module.class/method object ...) will be the same as module.class.method(object, *args, **kwargs) in Python
• (require-python '[module.class :coerce]) will make all calls that follow the pattern (module.class/method object ...) coerce to ($a method object) to respect substitutionality OO principles
• (require-python '[module.class :strict]) will throw an error if a class method of class k is called on a subclass of k called k_sub, then (module.k/method o) would throw an exception if the appropriate invocation was (module.k_sub/method o)
• (require/with-coercion (require-python ...)) will be made available in order to not have to explicitly specify :coerce on every requirement,
• (require/with-strict ...) will be made available for the same purpose,
• classes will be loaded by default if (require-python 'module) or (require-python [module ...])` syntax is employed,
• modules will be loaded recursively so that if Python module a imports module b, and b imports c, and c has class d, then you should expect to be able use (a.b.c/d ...) and expect intellisense, metadata, and completion assistance.

from libpython-clj.

 I want to type (mxnet.modules.Module/forward item batch-data) and have intellisense help me out.

Could you try (require-python '(mxnet mxnet.modules))? I would expect that should let you do (mxnet.modules.Module/forward item batch-data).

from libpython-clj.

Regarding the rest, I'm going to suggest the following syntax, as I'm concerned getting overly clever with the require-python syntax and implementation will come back to bite me (as there's no way to tell a priori in (require-python 'a.b) if a is a module and b is a class in a or if a.b represents a module along a/b.py).

This same problem is probably related to why Clojure solved this problem with import, and I think maybe we could do the same trick. For instance:

(require-python '[builtins :as python])
(import-python '(python dict))

etc.
That would allow for more fine grained control without mucking stuff up too much.

On the other hand, it could be a lot more verbose. We could also potentially do

(require-python '[builtins :as python :import :all])

or

(require-python '[builtins :as python :import [(list :as pylist) dict])

which might be a little more concise

from libpython-clj.

On a little further consideration, I'm thinking:

(require-python '[builtins :as python :import [dict]])
will results in dict being a namespace distinct from python accessible by the current ns, whereas
(require-python '[builtins :as python :refer-classes :all])
and
(require-python '[builtins :as python :refer-classes [dict]])
will result in python.dict being a namespace.

from libpython-clj.

On a little further consideration, I'm thinking:

(require-python '[builtins :as python :import [dict]])
will results in dict being a namespace distinct from python accessible by the current ns, whereas
(require-python '[builtins :as python :refer-classes :all])
and
(require-python '[builtins :as python :refer-classes [dict]])
will result in python.dict being a namespace.

from libpython-clj.

The distinction between classes and modules seems oddly blurred to me. Why can I only require modules, which then end up as namespaces but I can't require classes, which also end up as namespaces?

The reason clojure has import is so you can have a type which you then use for things like type annotations and constructors. It specifically isn't used this way at all; if we are going to make namespaces out of python classes then I think that is a require, not an import.

It isn't always apparent when something is a submodule vs. when something is a class aside from capitalization. Classes have a constructor I guess and you could annotate their methods with an instanceof check maybe but we are blurring some lines here.

Basically, I feel that if you are creating a clojure namespace then you are doing a require pathway. If we statically code-gen these things then you would expect a normal require to work, not an import. So I would like the dynamic pathway to work the same as the code-gen pathway in most cases which means you need to be able to 'require' the class also and it can't be special syntax.

This actually makes me think that the :require-classes pathway in general and the :recurse pathway aren't necessary. If python-require worked with classes then you would just (require-python '[buildtins builtins.list]) and I think that is enough. What if we don't have the auto-method and just allow requiring directly of python classes?

from libpython-clj.

These have all been addressed

from libpython-clj.