It's really inexcusable that in 2012 (or 1992 even) a language that otherwise is well-suited for internet programming does not come with a first class httpclient.
Python for Humans
81–90 of 108 posts
Re: Python for Humans
#82Earlier quoted context omitted.
> It's great that it's improving, but many other languages have a much better library/API situation than Python has had for years already. As someone who has spent the last 5.5 years at a job where I didn't need anything but the standard library, I don't agree. What are these other languages that contain a better situation?
Well, Perl's CPAN has an uninstall feature. That's kind of nice.
cpan is very much not a std lib. PyPi is equiv.
Re: Python for Humans
#83The portion that explains of how subprocess shuns dev/ops guys in the beginning is so true. Perl/Bash colleagues at work would basically ask me how to perform output=`command`. Once they seen subprocess, they would continue writing their script in Bash/Perl.
Very true. I spent quite a while trying to learn subprocess, then gave up and just use os.popen() now. It's a shame -- there are certain subprocess features I really would like to have, but it's too hard to remember how to use it.
I've done a considerable amount of work in subprocess. It's API isn't amazing, but it does have quite a few great features and once you spend a little time with it really isn't too bad. Some of the piping features, along with shell arguments work quite well.
Re: Python for Humans
#84I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL. import smtplib s=smtplib.SMTP("localhost") s.sendmail("me@my.org",tolist,msg) note the absence of…
I've been programming python for nearly 10 years, but your comment just helped me clarify a thought that I've had for ages but have never been able to put in to words before: a well designed Python API is one that can be effortless used within the REPL. And that's why urllb2 sucks.
Re: Python for Humans
#85I was intrigued by the author's library "envoy", which is intended to provide a more intuitive interface to running processes from python. ( https://github.com/kennethreitz/envoy ) The back story is that the older APIs that Python comes with -- os.popen and os.system -- are deprecated. Programmers are urged to use the "subprocess" module instead. Although this doesn't have the problems of the original functions, it h…
> subprocess.call() accepts an array in the style of ["ls", "-l", "/mnt/My SD card"]. This has obvious advantages over having to deal with escaping shell characters. Unless you're running on Windows, in which case IME it will corrupt your carefully constructed parameters in completely inappropriate ways that can be debugged only at the cost of (a) changing the call() to execute a script that dumps the actual paramete…
On Unix, a new process is supplied argv[], an array that contains the executable name and invidual arguments. Clearly, supplying call() a list of arguments is the right thing to do.
I seem to remember that on Win32, all you get is an argument string, and the process is required to do the parsing itself. This is simply a different model, and the Unix way is cleaner and easier to work with. It seems to me reasonable to optimize for the saner (Unix) way of doing things instead. I confess I don't understand your analogy to Word.
Re: Python for Humans
#86Hangs on the first slide unless I'm doing something really wrong.
Am I weird if I say that such badly-written presentation make me much less enthusiastic about their content?
Re: Python for Humans
#87Earlier quoted context omitted.
Do you have some examples? I thought I knew a fair number of programming languages, and Python's got one of the most comprehensive. IMO, Python's stdlib beats C++, Ruby, Java, javascript and Perl....
Python's library is comprehensive "on paper". Vast amounts of it are actually incomplete or outright broken when you try to use it in practice. The reliable parts of Python's standard library are at a level little beyond C and C++ and far behind Perl/CPAN, Java, .Net and so on. And even then, as the article we're discussing points out, the APIs aren't actually very good a lot of the time.
Yep, basically my point. But you're formulating it better :-)
Re: Python for Humans
#88Why don't you just switch to Ruby?
I didn't find making moderately complex HTTP requests in Ruby to be much more fun than urllib2 in Python. Do you have a library you recommend?
I like httparty or mechanize, but feel free make your own choice over here https://www.ruby-toolbox.com/categories/http_clients
Re: Python for Humans
#89I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL. import smtplib s=smtplib.SMTP("localhost") s.sendmail("me@my.org",tolist,msg) note the absence of…
Your example with "MouseClick" succintly explains what I feel is wrong with much of software development today that tries to follow "modern" OO practices. Blame it on the language, or on people who try to mold the world into familiar casts at any cost by overusing patterns?
Re: Python for Humans
#90I blame GOF for making Python Standard Libs hard. The patterns described were for an OO system where functions were not first class. Python didn't need to be complicated. If you have a look at the older libraries, most of them were written in a procedural style. Not only that, it is very amenable to testing in the REPL. import smtplib s=smtplib.SMTP("localhost") s.sendmail("me@my.org",tolist,msg) note the absence of…
Your example with "MouseClick" succintly explains what I feel is wrong with much of software development today that tries to follow "modern" OO practices. Blame it on the language, or on people who try to mold the world into familiar casts at any cost by overusing patterns?
The problem with Java is because there aren't any strongly typed functions, only strongly typed classes.
Therefore to handle a mouseClick event requires a class. However, it doesn't make sense to have a IMouseClick interface that has only one method, right? That would seem too wasteful.
So the natural thing to do is to group all the mouse events into a single interface.
Before you know it, you have the abomination of MouseClickListeners, MouseAdapters, and anonymous classes.
About overusing patterns - GOF is really a book of anti patterns that is particularly useful for language designers, because it points out the glaring contortions that people have to do to get their work done.
On the other hand, being a good programmer requires learning and subsequent unlearning of GOF patterns. I'm reminded of Bruce Lee when he started with Wing Chun, but then found the "form" too rigid. Quote from http://www.cavendishscience.org/phys/brucelee/brucelee.htm
In describing his style, Bruce Lee made a clear
distinction between "having no form" and "having no
form." To have no form was to transcend form from a
position of mastery that enabled one to see when the
rules could be-in fact, needed to be-broken. No form
was highly disciplined in its execution. In essence,
to have no form was to have access to all forms; to
understand all forms at their most essential level
and to see and be able to act on the connections among
forms. On the other hand, "having no form" implied an
undisciplined approach, an inability to master any form.
Lee discovered that he could not teach no form directly
to novices in the martial arts. A student first had to
master the form of karate, tae kwon do, or some other
school; only from a position of mastery could the
student begin to experiment with abandoning the form.