For the --spy commmand line option, it currently says '''Print equivalent Hy code...'''. Now, I haven't actually gotten around to installing Hy on my computer yet, so I haven't had a chance to test this out to make sure, but from the looks of the code example, it looks as though it is printing out the equivalent Python code of the executed Hy code, not the other way around. This would certainly make more sense. As such, I have changed the word 'Hy' to 'Python' so that the documentation more accurately reflects what (one assumes) is going on.
With this patch, every identifier is split up along dots, each part gets
separately mangled, and then it is all joined back together. This allows
for fun stuff like (.foo? (Foo)), and even more contrived examples.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
As a refactoring step, move the identifier mangling done in t_identifier
into a separate def.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
The hy2py tool has been very useful for me, but most of the time, it's
only a part of its output that one is interested in. The whole output,
with source code, AST and python code together is one big monstrosity.
So instead of printing all that, lets have a few handy command-line
options to control which part gets printed.
By default, only the generated python source is, as that's what the name
of the tool implies.
Also, don't run it. That's what hy is for.
Signed-off-by: Gergely Nagy <algernon@madhouse-project.org>
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>
* hy/core/language.hy:
-Added a simple coll? function that checks whether the given argument
is an iterable and not a string,
- Also replaced the check in `flatten` by coll?
* tests/native_tests/core.hy: Tests updated for checking coll?
