Recharging the Python standard library
programming.oreilly.com
programming.oreilly.com
The title is link bait. The "batteries" work fine - some are venerable, but they are well tested and documented.
The author ignores stellar parts of the standard library such as: collections, itertools, contextlib, functools, itertools, sqlite3, hashlib, struct, json, elementtree, etc.
Essentially, the author is bashing the entire standard library because the urllib modules are somewhat dated. IMO, The rant is not worthy of being on the front page of Hacker News.
Still, the only thing I use with any frequency that is an outright replacement for standard library functionality is requests and beautifulsoup. Well, if you don't include ipython, which is an absolute necessity.
Or do you find Python's argument parsing to be especially notable for some reason?
* sys.argv
* argparse
* optparse
* getopt
There are, of course, additional third party modules (like opster) that also handle arguments.
optparse is deprecated (kept around for obvious backward-compat reasons)
getopt is just a different API for people who feel more comfortable with C's getopt API and don't want to learn something else
argparse is the CLI option parser for the future.
tl;dr: There is one way to parse command line arguments: sys.argv. But there are a few abstractions of doing that available in the stdlib.
os
sys
logging
os.path
re
subprocess
datetime
json
pickle
itertools
urllib2
signal
traceback
socket
To refer back to the "old batteries" argument, the included batteries may be the old lead acid type, but they're dependable in a lot of cases where newer lithium ion batteries would rather catch fire.
I just remember that datetime is the package, datetime.datetime is the class, and datetime.datetime.now() is a @classmethod that returns instances of that class. I do kinda wish it was datetime.now() for the constructor instead.
His complaints are essentially: 1. The 'sys' and 'os' modules require too much typing and aren't 'beautiful' enough. 2. 'Requests' isn't stdlib. (because obviously) 3. Rargh time zones are annoying. (not python's fault that we, as people, split time into arbitrary 'zones') 4. I prefer a different testing module.
And his solutions are: 1. To use a wrapper that requires a little less typing. 2. To complain about it. 3. To use a third party lib that 'solves' the issue because it gets updated more frequently. 4. To use a different testing module.
I don't see how any of this means that Python's stdlib has 'dead batteries.' What a garbage article.
On a side note, I feel this is a terrible idea:
>The proposal introduces a provisional stage that allows packages to go into the standard library without enforcing the hard guarantees of backwards compatibility and API stability that previously made standard library inclusion undesirable.
The standard lib should be made of things that are rock solid. You don't build a house on unreliable-but-so-fun-to-use materials, nor should Python mess with stability so that blog writers bitch less.
Sidenote: the json module lives in the stdlib now but started out as a third party module, simplejson. Not sure what that says vis-a-vis the author's fuzzy thesis.
Not to mention the fact that, in his code, he aliased path to p, so it's even more confusing as to what is going on there.
filepath = os.path.join('.', 'test_dirs)
os.makedirs(filepath)
with open(os.path.join(filepath, 'test.txt'), 'w') as f:
f.write('hello world')
Also, on the same topic, what about using the '+' operator with strings and lists/tuples for concatenation? Or the '|', '&' and '^' operator for sets (which I have to admit I never use because I can never remember which is which)?
If, and only if, you're familiar with how the path library works. I had to shift mental contexts away from python and into shell to understand that it was a "shortcut" for os.path.join(). The division operator is not typically associated with path joining in programming languages.
Frankly, it's not really offering any greater level of abstraction for paths; just shortcuts. You still have to call makedirs, open, write, etc. I don't find the minute improvements to os.path.join that terribly compelling.
The following is rather poor advice, though: "Python programmers should never restrict themselves to the standard library and should be open—even eager—to depend on third party packages that provide the APIs and functionality they need."
Really, you should not be "eager" to depend on things outside the standard library unless you have a good reason to. Every 3rd-party dependency you use adds complexity and you will have to make sure that the latest version doesn't change out from under you. If you are building an open source tool, for example, you may end up supporting multiple versions of the packages you depend on. Sure, use a 3rd-party library if it is worth that overhead, but you should never do it without good reason.
E.g. even in scala land I got the feeling ivy/maven dependency management weren't universally loved, but maybe I am wrong?
* it doesn't have virtual packages (in the sense, "'email-sender' is a package that provides a sendmail() function")
* it hardcodes a max of two dependency sets: runtime and dev. This maybe be better than a freeform Gemfile or a 6-scopes pom.xml but it seems quite arbitrary
I don’t believe it’s realistic to create a standardised toolbox when every new language come along and expect everything in it to still be a good way of doing things ten years later, as requirements change and new ideas come along. This is probably why so many languages today have at least a de facto standard place where you get other libraries when you need them: PyPI, CPAN, Boost, etc.
On the other hand, there are many recurring themes that appear in those libraries, particularly in the interface they offer and their overall design: basic data types and data structures, application-specific concepts like windows and database connections and file formats, architectural tools like publish-subscribe mechanics and test hooks. Standardising these common ideas, so it’s as easy as possible to connect up libraries from different sources or to replace one library with another, offers many benefits in efficiency and maintainability for a programming language’s ecosystem as a whole.
We already see examples of this being done: many languages have a somewhat standardised interface for connecting to SQL-based database engines, for example. We also see some unfortunate examples where it wasn’t done quickly enough, such as the myriad string types everyone defined in C++ because there was no standard type for so long.
I suspect the most successful programming languages of tomorrow may not have anything like as many tools available “out of the box” as Java and Python and C# do today. However, if I were a betting man, I’d wager they will all provide solid foundations for managing third party libraries and much better frameworks and conventions for interoperability between those libraries.
I can appreciate the need for higher level libraries in the std, but not at the expense of os, sys, and other 'dead' modules.
Do you want an excellent graph library? you have networkx. Do you need more speed? bind an existing C++ library with SWIG. If I want to use .NET or Java libraries there is IronPython and Jython. And you have two excellent IDEs: Visual Studio and PyCharm.
I agree that the breadth of high-quality python libraries is great... but in a language that believes
"There should be one-- and preferably only one --obvious way to do it,"
it'd be nice if we weren't also looking for replacements for the standard library.
From PyCrypto's website:
"Unfortunately, cryptography software is still governed by arms control regulations in Canada, the United States, and elsewhere. The controls are fairly loose for free/open-source software, but they exist nonetheless."