Namespace mappings

[Antony Lee]

Instead of continually opening new issues, I thought it would be better just to summarize my plans here.
Comments are welcome.

# Clojure-Py enhancement proposal
# Namespace mappings

## Proposed forms

Namespaces can map symbols to either Vars or Python objects.

* (refer ns-sym & filters)
    For each Var in the `ns-sym` ns, subject to filters, add a mapping in the current ns.
    Allows :exclude syms, :only syms, :rename syms-map.
* (import package-sym & filters)
    For each Python object in the `package-sym` python package/module, subject to filters, add a mapping in the current ns.
    Allows the same flags as refer, with the same semantics.
* (require & args)
    Loads libs, creating corresponding namespaces.
    Allows :as sym, :refer [syms|:all] in libspecs, :reload, :reload-all, :verbose as flags.
* (use & args)
    Requires, then refers *AND* imports.  Relevant flags are passed to each form separately.
* (intern ns name), (intern ns name val)
    Same as clojure-jvm.

## Translation

import foo =>           (require 'foo)
from foo import * =>    (use 'foo)
from foo import bar =>  (use '[foo :only [bar]]) ; backwards incompatible change!
import foo as bar =>    (require '[foo :as bar])

## Work to do

* (require '[foo :as bar]) will become legal instead of (require 'foo :as 'bar).
* Because \*ns\* does not exist yet, refer and import will be macros (to expand \_\_name\_\_ at the proper time) instead of fns.
* Namespaces will no longer refer clojure.core by default (right now this is done in namespace.py), thus allowing the implementation of the :refer-clojure clause in the ns macro (however, the ns macro will add a :refer-clojure clause if none is given, as clojure-jvm does).
* Support for :only in require will be dropped.

[Laurie Clark-Michalek]

You say that namespaces map to either python objects or clojure vars, how does this affect python to clojure-py interop? Having to deal with clojure vars when importing a namespace from python isn't very nice, having to deal with more stuff (I.e. some special import mechanic) would just make things worse.

[Antony Lee]

The idea of mapping to either Vars or Python objects directly come from clojure-jvm's namespaces, which can map either to Vars or to Classes.
If we decide to only map to Python objects, interop is simpler, but we lose, well, clojure's Var semantics.  Things as simple as (def some-var some-value) currently break (as expected) if some-var is already a Python object and not a Var, so we would need new semantics here.
We can also decide to only map to Vars, wrapping Python objects into Vars as necessary upon import.  Basically:

(ns 'abc)
(use 'numbers) (or any Python package/module)
=>
Create a numbers namespace (not the same object as the numbers module!)
For each name in dir(numbers), create a Var that wraps it, intern that var to the numbers namespace, and refer it in the current namespace.
Or we can decide to skip the first step and intern directly into the current namespace, but that would be different semantics than clojure-jvm's.  For example, the var would probably have to be marked as private (as Number is not expected to be exposed when abc.clj is imported itself by someone else).

All the wrapping seems a bit excessive to me, but if I had to choose between one of the two options, I would probably still choose the latter
Antony

2012/5/9 Laurie Clark-Michalek <lclarkm...@gmail.com>

[Antony Lee]

I went ahead and implemented the new semantics for refer and import in the new-ns branch of my repo:
https://github.com/anntzer/clojure-py/tree/new-ns
Please have a look and give me your opinion on it.
Antony

2012/5/9 Antony Lee <anton...@berkeley.edu>