

How Hy backported “yield from” to Python 2 - aroberge
http://dustycloud.org/blog/how-hy-backported-yield-from-to-python2/

======
wzdd
They wrote a Lisp, and added a feature to the Lisp, which they can do really
easily because Lisp has macros.

Their choice of runtime environment (Python 2) doesn't impact anything. They
didn't port "yield from" to Python 2 the language, they ported it to Python 2
the bytecode interpreter.

~~~
agentultra
You don't _need_ macros in Python. In Maslo's Hierarchy of Programming you can
get by with first class functions and an AST module just fine. But it is a
fine day when you can generate code using the same primitives you would use on
plain old data.

It's not the most interesting example of macros but it does illustrate one
small point: we can use _yield-from_ in an expression as if it were any other
symbol in the language. This is what Lispers mean when they say that you can
program the language with macros. They're mini-compilers. It's when you start
layering them together that things start to get interesting. You can use the
_yield-from_ symbol in any valid place within an expression... and since Hy is
all expressions and has no statements it gets expanded out and put in the
right place and just works.

In languages without macros you have design patterns. The lack of facility for
linguistic abstraction forces us to use primitives to describe more
sophisticated phenomenon than our language provides by default. So Twisted has
had sub-generators in Python 2 for a while and they work rather well via its
Deferred abstraction. It works well and I was glad to have it... however its
implementation is much more complex than the macro described in this blog
post. We had to wait for Python 3 to have them integrated into the language.
Macros can bypass that which is the point the OP was trying to make.

The point I'm making here is that you can do pretty much everything you want
to do without macros. You'll just have to write quite a bit more code and come
up with many more metaphors and analogies in order to get it to work. Macros
just let you get straight to the point by extending the language.

~~~
kazinator
We can look at it like this.

You essentially _have_ macros in Python: they are hard-coded in the form of
phrase structure rules in its grammar.

Macros are essentially this: new phrase structure rules in your
interpreter/compiler that you program yourself and stick into your
application.

What you're really saying is actually that you don't need any new macros
beyond the phrases which the benevolent dictator for life has bestowed upon
you in the parser.

Whenever a programmer upgrades to a newer Python which has new syntactic
transformations in its updated grammar, and then uses these new things, that
programmer contradicts his or her earlier claims that no new macros were
needed.

~~~
pekk
I don't need everyone else in my shop making horrible sloppy messes at an
unnecessarily high level of abstraction using macros. I'll be picking up after
their cute shit at the end of the month, under emergency conditions. There's
currently no problem with them recompiling Python to make weird one-off syntax
because that's clearly crossing a line. I could add my own syntax and
recompile, but I legitimately don't need or want to. No, I _don 't_ need a
general runtime macro capability in Python. It's not a good idea and it
doesn't buy anything I actually need.

~~~
orbifold
Take OCaml for comparison: It has a more or less reasonable way of extending
the language with an extensible parser camlp4 that ultimately yields a fixed
AST. No one would get the idea to use it just for fun, or one-shot
abstractions, but it is integrated into the toolchain well enough that you can
reliably distribute libraries that use syntax extensions. The general attitude
that "coders are dumb, we need to protect them from themselves" lead to the
development of mediocre languages like Java. Compare that to something like
Racket, where despite some flaws most of the macros provide an obvious and
very real benefit, without overcomplicating the compiler (for example the
match macro, or the macros that constitute the C-FFI). Ideally in my eyes a
language should provide the programmer with maximal possible expressiveness
without compromising a core simple design.

------
agf
Chris gave a great talk about Hy at ChiPy (Chicago Python) last year:
[http://pyvideo.org/video/1869/hy-a-lisp-that-transforms-
itse...](http://pyvideo.org/video/1869/hy-a-lisp-that-transforms-itself-into-
the-python)

You should also check out his work on MediaGoblin. "MediaGoblin is a free
software media publishing platform that anyone can run. You can think of it as
a decentralized alternative to Flickr, YouTube, SoundCloud, etc."
[http://mediagoblin.org/](http://mediagoblin.org/)

------
jarcane
I really should play more with Hy someday. I discovered it when I was still
too new to Lisps to make sense of such a new project (and such new and
experienced-user-oriented documentation).

------
rnnr
Nothing to see here. Even the PEP of yield from contains code simulating a
'yield from' with plain 'yields'. The thing is, you are just simulating it
with the expense of switching generators back and forth.(like a trampoline)

------
plq
inspect module offers isgenerator and isgeneratorfunction. the author should
have used that.

[https://docs.python.org/2/library/inspect.html#inspect.isgen...](https://docs.python.org/2/library/inspect.html#inspect.isgeneratorfunction)

~~~
the_mitsuhiko
Which does exactly the same as what the code in the example does.

------
emiljbs
Looks like they use defmacro/g! from let over lambda.

