jump to navigation

Give PycURL a Chance March 9, 2016

Posted by PythonGuy in Uncategorized.
add a comment

I stumbled, almost randomly, upon the fact that cURL publishes libcurl, and provides bindings for over 40 languages, Python being one of them.

From their website:

PycURL is targeted at an advanced developer – if you need dozens of concurrent, fast and reliable connections or any of the sophisticated features listed above then PycURL is for you.

The main drawback of PycURL is that it is a relatively thin layer over libcurl without any of those nice Pythonic class hierarchies. This means it has a somewhat steep learning curve unless you are already familiar with libcurl’s C API.

To sum up, PycURL is very fast (especially for multiple concurrent operations) and very feature rich, but has a somewhat complex interface. If you need something simpler or prefer a pure Python module you might want to check out urllib2, requests and urlgrabber.

If you’re like me, and you always reach for requests, then perhaps it is time to take a look at PycURL. Your next project might need it!

BTW, I am not at all deterred by the fact that cURL is almost as old as the world-wide web. In fact, such stable projects tend to deliver superior results. Don’t discount the old! In fact, it is up to the newer projects to explain why you should use them.

And remember: Use the right tool for the job. If you don’t need the advanced features of PycURL, don’t use it. I recommend requests as the default tool in Python. I would never recommend urllib2 for anything, as it is pathetic and almost useless, even though it is part of the standard library.

If you want to build tools, your architecture is too complicated March 8, 2016

Posted by PythonGuy in REST.
add a comment

It struck me, reading about Flasgger and Swagger and such, one of the reasons I detest REST API. (I can write a lot about why you should never, ever do REST, but I doubt you will be interested.)

This reason is the same reason I detest Java and pretty much any IDE. It’s a rather simple reason: Complexity. Or rather, giving up in the face of it.

If you’re building a system that is so complicated that it requires a computer to explain it to you, then you’re doing it wrong. If the computer can make your job easier, just let the computer do your job for you. Go up a higher level of abstraction by writing a library that will solve the problem once and for all, and then move on with your life.

REST APIs are artificially and unnecessarily complex. Every other API, or at least the good ones, follow a simple paradigm: Publish a function that takes parameters and returns results. This function-centric model is apparent in all but the most ambitious object-oriented frameworks. Even then, what you’re really looking at is a model where certain functions, such as object instantiation and get/set attributes, are assumed or hidden rather than exposed.

The truth is that I have little need for things like Sphynx. Wonderful as they are, you should get more out of reading my code first-hand with a plain old text editor than you will ever get by looking at a bunch of beautifully formatted HTML pages. And I try to minimize my comments. I subscribe to the philosophy that if you have to explain it, you’ve failed. This idea comes from The Design of Everyday Things. Things should declare what they are and what they do by their very shape and existence. It should be so simple that a child can use it. People shouldn’t be scared of doing the wrong things with it because doing the wrong thing should be very difficult to do.

This isn’t always possible, of course. When faced with complexity which you cannot seemingly overcome, you have a couple of choices. For me, it always boils down to (1) make it simpler by more problem solving and a deeper understanding of the problem, of (2) document it and ship it. As you can probably tell, I keep choosing (1) until the project is due. When I am forced to choose (2), there is usually not much left to document so the path to deployment is pretty clear.

When people write software which takes complicated things and automatically documents it, I cringe inside. We shouldn’t be dealing with those sorts of things, especially when they are trivial enough that a computer can understand it and create documentation for us. We should be dealing at a higher level of abstraction. We can bury complexity behind abstractions. Humans handle abstractions really well. We should find the simplest abstractions that still work and make that our interface with humans.

So please, stop writing REST APIs. They are needlessly complex. Instead, write functions that get exposed.