21–30 of 108 posts
After that use virtualenv with virtualenvwrapper.
I 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?
For example, the standard library already has urllib2, which provides HTTP support much better than most other languages' standard libraries. But Requests is a rewrite of it, taking ease of use to a whole new level without compromising any of the features. There is no equivalent in any other language.
This 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.
I agree that people should use a good package manager, but the reality of the corporate env world is that you'll be trying to use the latest Python on some ridiculously old unix install without root access, and you'll never be able to get IT to install the latest for all users.
Anybody have a text version of this? I got maybe 30 slides in before I got too annoyed to continue.
I 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 quite the opposite, actually. Python already has an extremely good and very capable standard library, arguably better than any other language. Python also has a community with a strong sense of what kind of API design best fits with the Python philosophy (which usually boils down to readability and consistency). So there are many efforts going on to improve the standard libraries. For example, the standard libra…
I don't know, LWP is pretty easy to use.
The 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.
And those functions are more convenient than the default behavior of backticks, because they handle for you raising an exception if the subprocess fails.
Python:
import subprocess
output = subprocess.check_output('command')
$output = `command`
die "failed: $output" if $?The slides don't fit vertically on my screen, so some of the content is cut off. There's no scroll bar so initially it was difficult to figure how to see the info cut off from the bottom. Chrome's text zoom out didn't work either. I had to highlight the text and drag downwards in order to see the content. But it was annoying having to do this for every slide with a lot of content. Otherwise, these libraries seem real…
Whats so wrong with just sticking a bunch of static slides on a page one after another?
The 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.
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 has a rather arcane interface, in particular if you want to read the output (stdout or stderr) of a subprocess.
"envoy" seems to aim at fixing this, by providing sane defaults and being optimized for the common case. However, these defaults have drawbacks of their own.
1. envoy defaults to keeping the process output in memory, as a giant string. This can be a bad choice with regard to memory usage and performance.
2. You can run several processes in a pipe using ("cat foo | grep bla"). But otherwise as far as I can see, run() ignores regular Shell semantics, such as quotes. I imagine this can lead to unexpected results. The amount of data passed from one process to the next is capped at 10 MB -- recipe for bugs that are hard to find.
3. 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. A good API should preserve this advantage over os.system().
4. The defaults cannot be overridden, and no preperations have been made to allow changing them. Of course this can be changed in the future. However, one of the reasons the subprocess.* API is convoluted is that it allows all kinds of flexibility, much of which is needed in many serious programs. It may be difficult to add this flexibility to envoy at a later stage. The point is that a flexible API is hard.
None of this is to discourage this initiative, which seems to me a much-needed improvement over Python's built-in API. Also, with a version number as low as 0.0.2, there is probably little need to worry about API compatibility.