Sebastian,

> It seems to me that the original langauge is "static"/"descriptive"
> while Python is not.  Why not move to XML or JSON (former seems more
> common with Gentoo) instead of Python?  Think about how much easier it
> is to pull information from metadata.xml than from .ebuild files - it's
> the same difference in your case.

I considered XML/JSON in this decision and did not even discussed it
with my mentor. This is indeed not and abandoned idea as I explain
below.

> 
> You know much better where you want to go with this than I do, but
> please triple-check this move, as you cannot go back.
> 

I'm in no position to chose the path to take but for now python still
seems the chosen "vehicle". Remember that using XML/JSON for modules
would never need a re-write from uselect but would only be an extension
to the module system. Let us see.

In uselect everything are objects. 

Module is a class
Action is a class

Module(s) have Action(s)

Actions are interfaces to many kinds of actions, Sym, Path, Runnable

Sym and Path actions have Link(s)

Runnable actions have code and know how to execute it.

Therefore the backend scenario (object space) is the same as the new
suggested module syntax.

Basically this decision is not adding a feature. It is abandoning the
"uselect syntax" thus removing a feature.

This will help during development as parsing is the task that has been
more time consuming during uselect's development.

With this uselect will have an open interface for extension to any
markup language that comes in handy in module readability/programming.

> 
> Thanks for listening,
> 
> 
> 
> Sebastian
> 

I thank you. Will now add the markup language support to the to-do list,
not to implement right away but to have in mind while expanding the API.

Cheers,
Sérgio

-- 
Sérgio Almeida - mephx.x@...
mephx @ freenode