This commit adds -E support for Hy. Similar to Python, hy will ignore
all PYTHON* environment variables, e.g. PYTHONPATH and PYTHONHOME,
that might be set.
* with-decorator: Allow a `setv` form as the form to be decorated
This feature is of dubious value by itself, but it's necessary to allow `defn` to create a lambda instead of a `def`.
* Make `fn` work the same as `lambda`
That is, allow it to generate a `lambda` instead of a `def` statement if the function body is just an expression.
I've removed two uses of with_decorator in hy.compiler because they'd require adding another case to HyASTCompiler.compile_decorate_expression and they have no ultimate effect, anyway.
In a few tests, I've added a meaningless statement in `fn` bodies to force generation of a `def`.
I've removed `test_fn_compiler_empty_function` rather than rewrite it because it seems like a pain to maintain and not very useful.
* Remove `lambda`, now that `fn` does the same thing
Give `require` the same features as `import`
You can now do (require foo), (require [foo [a b c]]), (require [foo [*]]), and (require [foo :as bar]). The first and last forms get you macros named foo.a, foo.b, etc. or bar.a, bar.b, etc., respectively. The second form only gets the macros in the list.
Implements #1118 and perhaps partly addresses #277.
N.B. The new meaning of (require foo) will cause all existing code that uses macros to break. Simply replace these forms with (require [foo [*]]) to get your code working again.
There's a bit of a hack involved in the forms (require foo) or (require [foo :as bar]). When you call (foo.a ...) or (bar.a ...), Hy doesn't actually look inside modules. Instead, these (require ...) forms give the macros names that have periods in them, which happens to work fine with the way Hy finds and interprets macro calls.
* Make `require` syntax stricter and add tests
* Update documentation for `require`
* Documentation wording improvements
* Allow :as in `require` name lists
Previously, Hy scripts that raised a subclass of IOError would be caught
by code intended to deal with IOErrors raised when Hy couldn't import
the script itself, resulting in either a misleading "Can't open file"
error message, or a misleading TypeError traceback from not being able
to format the "Can't open file" message (for IOErrors for which the
errno attribute was None). This commit (a straightforward implementation
of the idea proposed by @slimetree in #714) introduces a new HyIOError
class, raises that when `import_file_to_hst` can't open the file path,
and catches it in the `cmdline_handler`.
This is believed to fix#513, #714, and #727.
If there are Unicode symbols in the hy2py output (as in
tests/native_test/language.hy) and the user is on Windows, and
the user is using Python3 and the user doesn't have an appropriate
codepage in the terminal for Unicode, then hy2py will fail at
encoding the output.
This fix makes sure that if encoding fails, the bytes output is shown
instead of throwing an exception and failing completely. This also
allows the hy2py tests to pass on Windows.
If the user does activate an appropriate codepage, for example,
chcp 65001
then the Unicode output will show correctly.
Converted printing code to small function to eliminate some duplicate code
There's no reason why one would need to choose between --spy and -i, so
pass down options.spy to run_icommand, and then to HyREPL, so we can
have both.
Signed-off-by: Gergely Nagy <algernon@balabit.hu>
This version is much simpler.
At the point that the exception is raised, we don't have access to
the actual source, just the current expression. but as the
exception percolates up, we can intercept it, add the source and
the re-raise it.
Then at the final point, in the cmdline handler, we can choose to
let the entire traceback print, or just the simpler, direct error
message.
And even with the full traceback, the last bit is nicely formatted
just like the shorter, simpler message.
The error message is colored if clint is installed, but to avoid
yet another dependency, you get monochrome without clint.
I'm sure there is a better way to do the markup, the current method
is kludgy but works.
I wish there was more shared code between HyTypeError and LexException
but they are kind of different in some fundamental ways.
This doesn't work (yet) with runtime errors generated from Python,
like NameError, but I have a method that can catch NameError and turn it
into a more pleasing output.
Finally, there is no obvious way to raise HyTypeError from pure Hy code,
so methods in core/language.hy throw ugly TypeError/ValueError.
By default, calling the Python REPL without arguments causes
sys.argv to be a non-empty list with an empty string, and some
modules (e.g., pyNN) rely on that.
There was a couple of duplicate imports and type checkings in the
codebase. So I added a new module to unify all Python 2 and 3
compatibility codes.
Also, this is a somewhat common pattern in Python. See Jinja2 for
example:
https://github.com/mitsuhiko/jinja2/blob/master/jinja2/_compat.py
This adds real command line handling to 'hyc' for issue #256
This fix catches missing/unreadable files and prints a nice
error message instead of a nasty stack trace when trying to
compile a non-existent file.
Also add this non-existent file check to hy to prevent the
current stack trace from something like "hy foobarbaz" when
"foobarbaz" doesn't exist.
also changes the failure return value to 2 to match Python.
Summary: This update does away with the scripts in bin and changes
setup.py to use entry_points in cmdline.py for the scripts 'hy' and
'hyc'.
This fixes installing and running on Windows.
The tests are updated to run the 'hy' script produced by setup.py
and not from bin/hy. This is more correct and makes the tox tests
run on both Window and *nix.
For running hy or nosetests directly in the source tree, you do have
to run 'python setup.py develop' first. But since tox runs and builds
dists, all tox tests pass on all platforms.
Also, since there is no built-in readline on Windows, the setup.py
only on Windows requires 'pyreadline' as a replacement.
Switched from optparse to argparse in cmdline.py
Instead of trying to manually separate args meant for
hy from args meant for a hy script, this switches from
optparse to argparse for the CLI.
argparse automatically peels out args meant for hy and leaves
the rest, including the user hy script in options.args.
This fixes the issue @paultag found running "hy foo" where
foo is not a real file. Also added a test that makes sure
trying to run a non-existent script exits instead of dropping
the user into the REPL.
Added argparse as setup.py resource (and removed from tox.ini) as well as removed uses of deprecated setf
