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.Source: http://blogs.perl.org/users/mark_allen/2011/12/writing-api-clients-in-perl-and-python.html
