xml yml and dependency hell

[Rustom Mody]

yaml by its indent-orientation is quite pythonic. In comparison xml
is cumbersome and laborious.

Strangely ruby supports yaml out of the box but python requires a
third party package PyYAML.

Now this may not seem like a big deal for us -- installing pyYAML
takes all of one minute -- but it may not be so to others as I
recently learned.

I conducted a python training for a corporate in which I showed among
other things that yaml is much neater than xml. They agreed that it
was neat but were reluctant to consider it because it adds dependency
headaches at a later point with their customers.



So is it likely that yaml will make it to the standard python library
at some point??

 

[Stefan Behnel]

yaml by its indent-orientation is quite pythonic. In comparison xml
is cumbersome and laborious.

Strangely ruby supports yaml out of the box but python requires a
third party package PyYAML.

Now this may not seem like a big deal for us -- installing pyYAML
takes all of one minute -- but it may not be so to others as I
recently learned.

I conducted a python training for a corporate in which I showed among
other things that yaml is much neater than xml. They agreed that it
was neat but were reluctant to consider it because it adds dependency
headaches at a later point with their customers.



So is it likely that yaml will make it to the standard python library
at some point??

That's up to the maintainers of PyYAML. If they want to get it in, there will
be ways to get there. If they do not want to - unlikely, unless someone else
takes up the work. But it's definitely easier if the authors decide to put it in.

Besides, why would you assume any dependency headaches? There's EasyInstall
and setuptools if you need them.

Stefan

 

[Rustom Mody]

Rustom Mody wrote:

That's up to the maintainers of PyYAML. If they want to get it in, there will
be ways to get there. If they do not want to - unlikely, unless someone else
takes up the work. But it's definitely easier if the authors decide to put it in.

Is this a general comment or specific to yaml? I mean can anyone add
anything they please to the python standard library?

 

[Bruno Desthuilliers]

Rustom Mody a écrit :

yaml by its indent-orientation is quite pythonic. In comparison xml
is cumbersome and laborious.

Strangely ruby supports yaml out of the box but python requires a
third party package PyYAML.

Now this may not seem like a big deal for us -- installing pyYAML
takes all of one minute -- but it may not be so to others as I
recently learned.

I conducted a python training for a corporate in which I showed among
other things that yaml is much neater than xml. They agreed that it
was neat but were reluctant to consider it because it adds dependency
headaches at a later point with their customers.

So is it likely that yaml will make it to the standard python library
at some point??

"dependency headaches" ? AFAICT from the project's site, pyYAML is a
pure Python package, and the only requirement mentioned is Python 2.3.
Compared to some products often in use in "corporate" environment, I
wouldn't call this a "dependency headaches".

Not that I disagree with the idea of including pyYAML in the standard
lib - this would be in pahse with the "batteries included" philosophie
IMHO - but then, what about python-json ? FWIW, JSON being another
pretty good alternative to XML, and probably more used than YAML, thanks
to the Ajax/Web2.0 madness.

But anyway, the inclusion of a package in the standard lib is a somehow
formalized process (cf pep 0002 [1]), supposed to be initiated by the
package's maintainers. So if you want this to happen for pyYAML, you'll
first have to talk about it with the project's leaders.

[1] http://python.org/dev/peps/pep-0002/

 

[Bruno Desthuilliers]

Rustom Mody a écrit :

Is this a general comment or specific to yaml? I mean can anyone add
anything they please to the python standard library?

No, definitively. But the process is supposed to be initiated by the
maintainers. Have a look at pep 0002 for more informations.