Python has the keyword.iskeyword method we can leverage for Python
keywords, but we also need to address Hy builtins like 'get' or
'slice'.
And to make behavior compatible with Python 2 or 3, we also make
a special case to prevent assignment to False, True or None as
well as the Hy versions: false, true, null, and nil.
For non-Hy modules, we also check to make sure the symbol is not
part of the compiler. This allows shadow.hy to override "+" but
prevents general use from re-defn-ing 'get' or 'do'.
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
As noted in #600, Python 3 allows a return inside a generator
method, that raises a StopIteration and passes the return value
inside the 'value' attr of the exception.
To allow this behaviour we simple set 'contains_yield' while compiling
'yield', thus allowing a return statement, but only for Python 3. Then
when compiling the try-except, we check for contains_yield to decide
whether there will be a return.
This allows code like:
(defn gen []
(yield 3)
"goodbye")
to compile in both Py2 and Py3. The return value is simply ignored in
Python 2.
hy2py in Python 2 gives:
def g():
yield 3L
u'goodbye'
while hy2py in Python 3 gives:
def g():
yield 3
return 'goodbye'
Turns out return in yield started in Python 3.3
This new core module allows us to shadow the builtin Python operators so
they may be passed to sequence functions that expect functions:
=> (map / [1 2 3 4 5])
[1.0, 0.5, 0.3333333333333333, 0.25]
Currently, defmacro/g! doesn't respond well when it comes across a
HyObject that doesn't respond to the instance method startswith (e.g.
HyInteger, HyFloat, etc.). This updates defmacro/g! to be a little
safer when searching for the gensyms it needs to create.
