Writing API clients in Perl and Python
I recently released a couple of API clients for the Ge.tt file sharing service, one in Perl and one in Python. (I am just a fan of the service, not an employee or contractor.) I would judge myself an "intermediate" pythonista mostly due to inexperience.
It's a culture shock coming from a background of CPAN. The old joke is that Perl is just a life support system for CPAN and that is arguably true, but I am here to tell you: you may not appreciate how good Perl hackers have it with respect to CPAN and the culture around documenting, packaging and testing distros once they're on CPAN.
It's hard for me to be neutral vis a vis Perl and Python because I am much more comfortable writing Perl, but I felt like the release process for python was really not very straightforward. Learning how python projects write, package and release documentation took as long as writing major portions of code. And I'd take the simplicity of writing TAP vs. the inflexibility and opaqueness of the Python unittest library any day. Finally, there's the mess of installing a python distribution with all of its dependencies. I've heard plenty of complaining about how CPAN client X does this badly or client Y does this other thing poorly, but I felt like I was in cargo cult territory with respect to the various ways that python tools are distributed and installed.
But aside from being generally unfamiliar with the cultural mores of the Python world, working with Python was good for my Perl code in the sense that it really focused me on how objects within the client should interact with each other. This isn't a knock on Perl's OO (or perceived lack of OO) capabilities, but rather a realization that I used my Perl library as a "first draft" client with the API service itself - prioritizing "it just works" over "it's elegantly constructed."
Now that I'm feeling pretty good about how the python library works and is written, I can go back and refactor my Perl code that much more quickly.
Singer, dad, nerd, not necessarily in that order. @bytemeorg
Yes, I often wonder why Ruby and Python (both excellent languages) don't have better infrastructure in this area (build tools, automated testing farms, etc). There's actually no technical reason for this, plus there's already an excellent example (CPAN).
Or perhaps their definition of "better" is different, and we're living in an echo chamber.
I think it's a matter of timespan, as the CPAN exists for a big enough chunk of time for practices to take hold and for tools to evolve. Once this atmosphere of quality (or kwalitee) became the basic standard of module release, it was easier to integrate other ideas into it and there was more pressure to improve on existing tools (packaging managers, testing modules) etc.
I love to see these polyglottous projects by a single author. It provides a nice rosetta stone into languages known less to me than my longterm affaire de coeur of which we speak. If only TestML was actively maintained on Python, this would be an ideal use case.
By the way, see the "NAMES TO AVOID: Net" section in the "On The Naming of Modules" document.
http://pause.perl.org/pause/query?ACTION=pause_namingmodules
WebService::Gett is probably a better name for your module. As Nick pointed out, Net should be avoided, and everything on CPAN is already an API, so that part is redundant.