51–60 of 75 posts
The thing with python standard library is that it is crapily documented imho. I often can't make heads or tails of it, while I have a much simpler time with any other language (you name it: Java, Ruby, PHP, C, Scala, Lisp, ...).
The Python standard library has great documentation. Except for some of the "batteries included" stuff. urllib2? Ouch.
Earlier quoted context omitted.
I think you've really just been unlucky. I've had the same experience before, but chiefly with Ruby. Interestingly, my problems with this in both Python and Ruby have evaporated once I got in the habit of using virtualenv/rb-env/rvm for my development environment. Python is about the cleanest/nicest experience I have in any language, for the record. Only language that comes close is Clojure. Leiningen is...legendary.
I would argue that Python's approach is FAR better than Clojure/Leiningen's "no batteries included" approach. Suppose you want to do a very common task like parse some XML. In Clojure, the workflow is: 1. Go to Github or Clojars, find the latest version number of clojure.data.xml 2. Add this version number to your project.clj 3. Lein deps and restart the repl 4. Re-acquire whatever REPL data you had In Python, it's:…
_domains_text = requests.get(API_URL + "/domainlist.xml").content
_domains_db = pyquery.PyQuery(_domains_text)
DOMAINS = [d.values()[0] for d in _domains_db('domain')]This has kind of happened in Ruby, too. Fortunately, Ruby gems are super easy to install and the standard library got some much-needed spring cleaning in 1.9. Python could use the same. There have been many times where I've wanted to do some simple task that would be made easier with an external library (like Requests) but I'm not going to bother dealing with the Python module install pain for a one-off task.
Python has had a lot of cleaning in 3, but everyone is screaming about how 3 doesn't work just like 2 so I guess you just can't satisfy everyone.
Earlier quoted context omitted.
I think you've really just been unlucky. I've had the same experience before, but chiefly with Ruby. Interestingly, my problems with this in both Python and Ruby have evaporated once I got in the habit of using virtualenv/rb-env/rvm for my development environment. Python is about the cleanest/nicest experience I have in any language, for the record. Only language that comes close is Clojure. Leiningen is...legendary.
I've had the same experience before, but chiefly with Ruby. Tell me about it: http://lee-phillips.org/badruby/
The fact that the standard library is well-maintained, carefully debugged, and backward-compatible is a far stronger indicator of Python's awesomeness than the existence of shiny, new libraries. Hackers naturally gravitate toward high-visibility projects with brave horizons and bold scopes. By contrast, it is incredibly hard to find the motivation to update, for the umpteenth time, a warty API -- and that's precisely…
Hardly. Backward-compatible? Ok, I'll agree to that one.
But seriously, if you want to see an example of a not-so-well-maintained or carefully-debugged standard library. I challenge you to go look at 'shutil'.
That's just one example of many in the standard library that needs some serious TLC. Want another? Go look at tarfile or subprocess.
And don't even get me started on the lack of documentation for many parts of the standard library; the source code is the only real documentation.
Earlier quoted context omitted.
I've had the same experience before, but chiefly with Ruby. Tell me about it: http://lee-phillips.org/badruby/
Is it reasonable to expect packages to maintain compatibility with a version of Ruby from 2004? I don't know many Python libraries that still work with Python 2.2. Not sure about Perl 5.8, but I couldn't even find a link to download a binary.
So many of the language features have changed in ruby programmer will have to edit every file in her project, and upgrade every single dependency, just to get her application running on a new ruby interpreter. Add that to the culture of "let's use as much 3rd party code as possible!" and the library writers emulating the core developers and changing their APIs all the time ... the process of upgrading an interpreter converges on "rewrite the entire application"
Which is what we do. And some percentage of those rewrites are in languages that don't have this problem.
Earlier quoted context omitted.
I've had the same experience before, but chiefly with Ruby. Tell me about it: http://lee-phillips.org/badruby/
Is it reasonable to expect packages to maintain compatibility with a version of Ruby from 2004? I don't know many Python libraries that still work with Python 2.2. Not sure about Perl 5.8, but I couldn't even find a link to download a binary.
The problem is that the various packaged versions of Ruby are a shambles. RVM has a number of significant problems and difficulties (rbenv is both better and worse).
Right now getting a good, modern Ruby version on a standard modern computer is a big pain in the ass.
As long as that stays true, we will be dinged for not supporting old (but common) versions.
Years from now, when everybody has good 1.9 compatibility, things may be better. At least, if 2.0 doesn't have the same problems...
(The current article link goes to the front page of the author's blog.)
The fact that the standard library is well-maintained, carefully debugged, and backward-compatible is a far stronger indicator of Python's awesomeness than the existence of shiny, new libraries. Hackers naturally gravitate toward high-visibility projects with brave horizons and bold scopes. By contrast, it is incredibly hard to find the motivation to update, for the umpteenth time, a warty API -- and that's precisely…
Well-maintained? Carefully debugged? Hardly. Backward-compatible? Ok, I'll agree to that one. But seriously, if you want to see an example of a not-so-well-maintained or carefully-debugged standard library. I challenge you to go look at 'shutil'. That's just one example of many in the standard library that needs some serious TLC. Want another? Go look at tarfile or subprocess. And don't even get me started on the lac…
I've rarely heard anyone say this. Do you have an example of an area that is severely lacking in documentation? Maybe I don't use a wide array of modules, but I can't remember the last time as a user I had to dive into the source code.
I know the stdlib lacks examples in a lot of areas, often going for purely API coverage, which is welcome to change.
Earlier quoted context omitted.
> the Python module install pain for a one-off task. "pip install requests" ?
Unfortunately, it seems the official documentation on installing Python modules[0] makes absolutely no mention of pip or even easy_install. Seems like something that should be there, right? [0]: http://docs.python.org/install/