Arguably, it's still not great. It's perhaps more terse than would be helpful. My goal for now is just to make sure that it's correct, and that it doesn't mislead with e.g. suggestions that these macros support only true lists, instead of arbitrary iterable objects.
- Removed links to non-updated code and badges.
- Compressed `quickstart.rst` into a few sentences at the very start of the docs.
- Added a "Why Hy?" chapter discussing Hy's features and comparing Hy to Python and other Lisps.
- Rewrote the tutorial to be more accessible to non-Python programmers and to be greater in breadth but lesser in depth.
- Cut down on the self-congratulatory manic tone and exclamation points, while keeping the jokes I liked best.
These changes make the Hy REPL more closely follow `code.InteractiveConsole`'s
class interface and provide minimally intrusive traceback print-out filtering
via a context manager that temporarily alters `sys.excepthook`. In other words,
exception messages from the REPL will no longer show Hy internal
code (e.g. importer, compiler and parsing functions).
The boolean variable `hy.errors._hy_filter_internal_errors` dynamically
enables/disables trace filtering, and the env variable
`HY_FILTER_INTERNAL_ERRORS` can be used as the initial value.
Python 3.x is patched in a way that integrates `.hy` source files into
Pythons default `importlib` machinery. In Python 2.7, a PEP-302 "importer"
and "loader" is implemented according to the standard `import` logic (via
`pkgutil` and later pure-Python `imp` package code).
In both cases, the entry-point for the loaders is through `sys.path_hooks` only.
As well, the import semantics have been updated all throughout to utilize
`importlib` and follow aspects of PEP-420. This, along with some light
patches, should allow for basic use of `runpy`, `py_compile` and `reload`.
In all cases, if a `.hy` file is shadowed by a `.py`, Hy will silently use
`.hy`.
