Hangs on the first slide unless I'm doing something really wrong.
Try the arrow keys
A clear sign that the one doing something wrong is the website's designer.
Also, it breaks the back button.
Python for Humans
41–50 of 108 posts
Re: Python for Humans
#42The 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.
from subprocess import check_output as qx
output = qx(['command', 'arg1'])Re: Python for Humans
#43This makes a lot of good points, but some bad ones. Esp. the "installing python" one. Just use your package manager to install all the versions you need. And for "Packaging and Dependencies", just use pip.
What's the package manager for windows? Mostly I agree with you, but installing python on windows is a PITA compared to *nix. PIP works until you need something that requires compiling extensions which is also a PITA on windows. IIRC easy_install can install binaries, but I could be wrong about that since I don't do windows development anymore and thus pip works for me 99% of the time. Regardless, my point is, though…
PIP works until you need something that requires compiling extensions
You could use *.exe installers such as http://www.lfd.uci.edu/~gohlke/pythonlibs/
Advanced users could use mingw to compile extensions.
Re: Python for Humans
#44python sucks!
Re: Python for Humans
#45I like the presentation, but for me it just underlines how it's smart to stay far away from Python. 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. Will Python catch up fast enough?
> 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?
Re: Python for Humans
#46Wow those libraries are indeed great, amazing compared to the standard libs. Hope they'll be included in the standard libs one day.
+1
I'd like to see some community effort to build a collection of similar "better than the standard" libs.
Which, at some point, could replace the standard libs. Or be the de facto standard, a pip install call away...
Re: Python for Humans
#47I guess I agree things could be simpler, although the cries of "garbage!" were a bit much. I wrote a wrapper function around urllib2 about 5 years ago and haven't looked back.
Re: Python for Humans
#48The 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 used subprocess in a program as recently as this afternoon and I'm quite baffled about the amount of negativity it attracts. Sure it's not quite as simple as `ls -l` but it's not too far off and in return it gives you far more control. Is there anything in particular that you found hard or confusing?
Re: Python for Humans
#49This presentation brings up a tangential point that has always confused me: how error-prone is starting a subprocess, really? I agree with the author's goals of making common tasks easier and more obvious. urllib2 is an easy target, as it was added to the standard library over a decade ago, long before REST was something people talked about. The best tools for packaging, versioning, and testing have always been a bit…
Creating a subprocess can be complex, at least if you expose all the different subtleties. If you've ever used Java's APIs to run processes, you know that Python's aren't the worst ;-)
There are lots of interesting corner cases, for example how to join stdout and stderr properly without blocking on one stream while the other is overflowing.
On the other hand, almost nobody ever needs this. Ruby's "output = `command`" probably covers 90% of the use cases with the most trivial API imaginable. The hard part obviously is exposing the advanced functionality without compromising on the simplicity.
Almost all programming communities can learn a lot from Ruby's "if it's too hard, you're not cheating enough" approach (dhh quote I believe). Yes, the process could return an exabyte of stdout data, but do you really care? Is that really the problem this API should try to solve, with all special cases? That's not good computer science practice, but surprisingly effective.
Re: Python for Humans
#50This presentation brings up a tangential point that has always confused me: how error-prone is starting a subprocess, really? I agree with the author's goals of making common tasks easier and more obvious. urllib2 is an easy target, as it was added to the standard library over a decade ago, long before REST was something people talked about. The best tools for packaging, versioning, and testing have always been a bit…
Creating a subprocess can be complex, at least if you expose all the different subtleties. If you've ever used Java's APIs to run processes, you know that Python's aren't the worst ;-) There are lots of interesting corner cases, for example how to join stdout and stderr properly without blocking on one stream while the other is overflowing. On the other hand, almost nobody ever needs this. Ruby's "output = `command`"…
The sad or happy truth is that thanks to advances in computing power, what used to be dummy toy programming is now not only a valid way of doing things but the correct one.
Using made up stats, slurping the entire output of a process in a big string would fail 99% of the times 30 years ago, 50% of the times 20 years ago, 1% of the times 10 years ago, but less than 0.01% of the time now. You'd waste your time doing it 'the right way'.
So it is with most simple data processing. If your goal is just to ship a product fast, you no longer need the old type of smart programmers; nowadays, smart means doing it fast and badly.