Suggestion: simplify string representation for module objects

[ikappaki]

Hi,

would it be possible to provide a shorter string representation (repr) for a module object, primarily when returned by the import function?

Currently, the repr includes the module's file path, which can be visually very annonying, especially when displayed in notebooks. For example, importing the pytest module in the REPL returns:

asilisp.user=> (import pytest)
<module 'pytest' from 'C:\\src\\basilisp\\.venv\\Lib\\site-packages\\pytest\\__init__.py'>

I think it would have been better to have it reprd keeping the start of the string only
<module 'pytest'>

or simply just the module name
pytest

This would improve readability and align better with user expectations in environments like notebooks.

It seems to me this could be achieved by overloading the module's class __repr__ method, though I'm not entirely sure how to implement this.

For comparison, Clojure imports already use a shorter and cleaner representation, which is easier on the eyes:

> clj
Clojure 1.12.0
user=> (import java.util.Date)
java.util.Date
user=> (import (java.util Date Calendar) (java.net URI ServerSocket))
java.net.ServerSocket

Thanks

[chrisrink10]

This is technically fairly easy to accomplish because Basilisp already has custom logic for emitting the Lisp representation of existing Python objects we don't control.

I'm leaning towards 👎 on this one just because it's changing something that Python is giving us for free and introduces more ambiguity at the REPL (particularly since Python modules and packages are named much more similarly to Clojure namespaces), but I could be convinced.

[ikappaki]

This is technically fairly easy to accomplish because Basilisp already has custom logic for emitting the Lisp representation of existing Python objects we don't control.

This is pretty cool indeed 🙌

I'm leaning towards 👎 on this one just because it's changing something that Python is giving us for free and introduces more ambiguity at the REPL (particularly since Python modules and packages are named much more similarly to Clojure namespaces), but I could be convinced.

Could you please provide an example of ambiguity, I can't think of one from the top of my head.

In my opinion, most users would likely never care about seeing or using the path of the imported module. Imports typically occur at the start of a session, where the user expects a clean start.

In Python, imports are silent by default:

> python
Python 3.11.4 (tags/v3.11.4:d2340ef, Jun  7 2023, 05:45:37) [MSC v.1934 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import os
>>>

Adding this long path in the output clutters the screen, especially in Jupyter notebooks, where showing local module paths looks ugly (IMO again). I don't want to share my notebook displaying the local path of my module import. Example:

I work around this by adding a nil next to the import to suppress the output, which is not ideal, especially when sharing notebooks.

Thanks 🙂

[chrisrink10]

Could you please provide an example of ambiguity, I can't think of one from the top of my head.

By this I mean that any Python module will appear indistinguishable from a Basilisp namespace object at the REPL.

In Python, imports are silent by default:

Indeed, but we always return something in Basilisp and that is not so for Python. You'd see this if you were inspecting the object:

>>> import attr
>>> attr
<module 'attr' from '/Users/christopher/Library/Caches/pypoetry/virtualenvs/basilisp-lKTp5Mxg-py3.12/lib/python3.12/site-packages/attr/__init__.py'>

I think you could possibly solve your problem with something like this:

(defmacro import*
  [& args]
  `(do
    (import ~@args)
    nil))

[ikappaki]

Thanks for the input! To clarify and focus the discussion:

I’m highlighting an aesthetic issue with the representation of the import return value on the REPL. Specifically, the module output includes the module file path, which is largely irrelevant to most users and clutters the output with Python module installation paths.

If we share a REPL session—via screenshot or more importantly via a notebook—these local paths will also be exposed when importing a module (which is very common in my experience to do so). This information isn’t useful to others and may unnecessarily reveal internal system details, which deviates from (what I consider to be) the norm. While the Python module representation includes the path by default, there’s no rule preventing us from formatting it differently to address potential inconveniences.

While we could use an import* macro (or append nil after the import statement) to suppress the output everytime we start a REPL session, this feels more like a workaround than a proper solution. It’s inconvenient for everyday usage and awkward in shared notebooks to add such logic solely for hiding import paths.

In terms of import aesthetics across runtimes:

• require in Clojure/Basilisp returns nil.
• import in Clojure returns the fully qualified class name (no paths).
• import in Python produces no output.

This contrast underscores the unnecessary path noise in the REPL import behavior.

Could you please provide an example of ambiguity, I can't think of one from the top of my head.

By this I mean that any Python module will appear indistinguishable from a Basilisp namespace object at the REPL.

Apologies, but I still don’t fully understand how could this be the case. Could you provide an actual example, even if it’s hypothetical, to help clarify?

[chrisrink10]

I’m highlighting an aesthetic issue with the representation of the import return value on the REPL. Specifically, the module output includes the module file path, which is largely irrelevant to most users and clutters the output with Python module installation paths.

I just don't really think I agree with this point. I think it is valuable information which I would like to be able to view when debugging.

Apologies, but I still don’t fully understand how could this be the case. Could you provide an actual example, even if it’s hypothetical, to help clarify?

The Lisp representation is used in debugging and output and will likely be used by other objects (such as maps or vectors) when inspecting their output.

If you were to place a module of any name in some Basilisp collection (for arguments sake we'll call it attr) it will appear as just attr: [attr]. What is that object without context? A namespace? A module? Something else?

In terms of import aesthetics across runtimes:

• require in Clojure/Basilisp returns nil.
• import in Clojure returns the fully qualified class name (no paths).
• import in Python produces no output.

Given that this is a Python-specific situation, I'm not especially convinced by arguments comparing runtimes. Clojure returns #object[user$eval134$fn__135 0x2787de58 "user$eval134$fn__135@2787de58"] for functions, which one could argue is just noise. Should Basilisp match that?

That being said, I could certainly be convinced that the import macro should return nil, which I think would solve your problem.

[ikappaki]

That being said, I could certainly be convinced that the import macro should return nil, which I think would solve your problem.

Indeed, this would be the most preferable outcome and I believe It addresses your concerns about shortening the module representation. Are there are any further concerns you might still have at this point? thanks

[chrisrink10]

No this seems fine to me. Are you able to put up the PR for that?

[ikappaki]

No this seems fine to me. Are you able to put up the PR for that?

Yes, will do. It is not as straightforward as one might think at first--just returning nil from the the import function-- because the return value is used internally by the ns macro, but nevertheless you can shape the PR during review.

[chrisrink10]

No this seems fine to me. Are you able to put up the PR for that?

Yes, will do. It is not as straightforward as one might think at first--just returning nil from the the import function-- because the return value is used internally by the ns macro, but nevertheless you can shape the PR during review.

I actually don't think it's that complicated. The way it's used in ns is just generating the calls, not actually using the results.

[chrisrink10]

Fixed in #1177