It might look like `ayrton`'s development has stalled. First, yes, a little. Last
week I barely put any time on it. Second, development will be less release centered,
and only because I have three things in mind that are very interesing to me that
I want to implement, and it seems that more or less I will be doing them on a «I
want to hack on this right now» basis.

One is to replace `sh`. So far I have been tiptoeing around it to make output go
to the terminal by default, which forces the intoroduction of `Capture`, and to
not raise an exception if the command fails. But recently I tried to make an
`ayrton` script to more or less automatize releases and I found out that `sh`
really messes with the subprocess' view of the terminal. In short, editors are
not usable if they're launched from `sh`. I could not say that this is the last
straw; I still think that `sh` is very good at what it does, but this definetely
is like a sequoia trunk after a few straws. This is called
[issue #15](https://github.com/StyXman/ayrton/issues/15).

Another is to try to make several changes on the way output is captured, piped and
redirected. I find this thing of messing with `_out` too annoying. Piping could
be handled by `|`, but currently is not possible to do it. Redirections could be
handled with `>`, but as long as I don't have `|`, it doesn't make much sense.
I'm already playing with checking the AST produced by the source, because I'm
trying to minimize the situations in which unknown names are resolved into
executables, and these things also require AST handling, so it should be more or
less easy to achieve.

There is another, more ambitious thing. So far I've been using Python3's syntax,
but this imposes some restrictions. I like [`sh`'s keyword
arguments](http://amoffat.github.io/sh/#keyword-arguments), but the syntax doesn't
allow you to put positional arguments after keyword arguments, like:

```python
rsync (archive=True, src, dst)
```

So the goal is to use another parser. As this is the only modification in mind,
it only makes sense to take Python3's parser, modify what I want, and ship with
that. But the question is, where is the parser code?

The answer is not simple, but at least exists besides, the source code. I mean,
I tried to untangle how this works, but as [Eli Bendersky](http://eli.thegreenplace.net/)
shows [in this post](http://eli.thegreenplace.net/2010/06/30/python-internals-adding-a-new-statement-to-python/),
it is not a simple thing. Luckily, what I plan to change is not implemented in
the parser itself, but in the syntax checker, which is implemented in the file
`ast.c`. So, by simply copying that one and `ast.py`, modifying the latter so it
uses my modified syntax checker, and modifying the `setup.py` file, I should be
done. Let's see how it goes...