OK, this will be short. It's nearly sleep time, and I'm donning the
traditional flameproof ominous cloak of the Chaos Legionnaire. Ia, Ia!
I've been doing some coding for a project called Beiti, which uses Mercurial in its back-end code. To work with the kivy framework for cross-platform compilation, Beiti is written in Python. Since Mercurial is also written in Python, I would have thought Mercurial would expose a public API as a set of Python modules I can import. I could thus use Mercurial from my program directly without having to resort to the subprocess module.
No such luck. According to Mercurial's own documentation, it has an internal API in its Python modules of which it absolutely does not ever guarantee the API stability. The Mercurial folks explicitly document their lack of a public API in their own code's native language.
This would have been kind of understandable a decade or two ago and in C, but today and in Python? What the hell? I understand that Mercurial is a major project with ongoing development and improvement, but seriously, not exposing a public interface in native Python just seems.... like the Hg devs don't really care. Come on, isn't this how you structure good software? Did Steve Yegge not leak an entire rant about how they did this at Amazon onto Google+? If you're writing software in Python that needs to expose a command-line interface, wouldn't you want to stabilize a public API, expose that in Python, and then just write front-end modules that reference that stable interface? That would separate the evolution of your backend code from the interface seen by users, be we users on the command-line or users of your code as a library.
Instead, well, I've had to go ahead and write the calls to subprocess. Sons, I am disappoint.
I've been doing some coding for a project called Beiti, which uses Mercurial in its back-end code. To work with the kivy framework for cross-platform compilation, Beiti is written in Python. Since Mercurial is also written in Python, I would have thought Mercurial would expose a public API as a set of Python modules I can import. I could thus use Mercurial from my program directly without having to resort to the subprocess module.
No such luck. According to Mercurial's own documentation, it has an internal API in its Python modules of which it absolutely does not ever guarantee the API stability. The Mercurial folks explicitly document their lack of a public API in their own code's native language.
This would have been kind of understandable a decade or two ago and in C, but today and in Python? What the hell? I understand that Mercurial is a major project with ongoing development and improvement, but seriously, not exposing a public interface in native Python just seems.... like the Hg devs don't really care. Come on, isn't this how you structure good software? Did Steve Yegge not leak an entire rant about how they did this at Amazon onto Google+? If you're writing software in Python that needs to expose a command-line interface, wouldn't you want to stabilize a public API, expose that in Python, and then just write front-end modules that reference that stable interface? That would separate the evolution of your backend code from the interface seen by users, be we users on the command-line or users of your code as a library.
Instead, well, I've had to go ahead and write the calls to subprocess. Sons, I am disappoint.
0 commentaires:
Enregistrer un commentaire