Hitchhiker's Guide to Python(late.am)
late.am
Hitchhiker's Guide to Python
http://late.am/post/2011/12/29/hitchhikers-guide-to-python
14 comments
There's a hitchhiker's guide to packaging that covers all aspects of the package lifecycle very well: http://guide.python-distribute.org/
In fact I'm a bit annoyed at seeing this new effort reuse the name, because the hitchhiker's guide to packaging has great content and is getting some well-deserved name recognition. The official Python wiki is another good place to learn and write guides about the ecosystem.
In fact I'm a bit annoyed at seeing this new effort reuse the name, because the hitchhiker's guide to packaging has great content and is getting some well-deserved name recognition. The official Python wiki is another good place to learn and write guides about the ecosystem.
The names are both equally original (e.g. stolen from Douglas Adams).
The packaging guide is fantastic, and will be heavily linked to.
The packaging guide is fantastic, and will be heavily linked to.
I'd rather like to see the target slow down.
What's wrong with my comment? Yes, python has a very confusing landscape of package management tools and practices, and indeed it's a quickly moving target. But documenting this mess is not the best solution because than the very documentation becomes a quickly moving target. Package management is not the most difficult problem in the world, is it. The python community should just be a little bolder about breaking backward compatibility.
If your original comment was downvoted (I did not vote one way or another), it was probably because it contributed little. Saying you'd "like to see" something without saying why (as in your parent comment) doesn't tend to generate discussion.
Haskell has something similar: http://www.haskell.org/haskellwiki/How_to_write_a_Haskell_pr...
Totally awesome & insanely useful.
I'd really like to see a meta-wiki with many "How to write a _blank_ program" pages. It would be great for languages, but it could also be useful for things like "How to write a 3D simulation program" or "How to write a math-intensive program" that serve as opinionated starting points to save me some time during researching new projects.
Totally awesome & insanely useful.
I'd really like to see a meta-wiki with many "How to write a _blank_ program" pages. It would be great for languages, but it could also be useful for things like "How to write a 3D simulation program" or "How to write a math-intensive program" that serve as opinionated starting points to save me some time during researching new projects.
I definitely think Python needs more opinionated guides so this is a win. I feel like Python does have enough "do it this way because". I think it has to do with the community just wanting to remain neutral. But you don't often get the best viewpoints when you stay in the middle.
I agree. I feel like through Github the Ruby community forks, argues, and resolves problems faster than most Python projects do. Maybe I don't read enough mailing lists to see the angry posts, but maybe a bit more contention would be good to move things forward.
Is that a happy side effect because of the fact that Ruby has a gold standard package manager ?
I think so - Python would do well to figure out the distutils/packaging/pip/easy_install confusion.
I think so - Python would do well to figure out the distutils/packaging/pip/easy_install confusion.
Part of the reason that Python has no canonical package management is that it is rooted in Linux, where the distro is perfectly capable of handling the task of package installation. It's an unfortunate artifact of shitty software management in Windows and OSX that we even have language-centric package management at all.
An installed package has and fulfills dependencies, no matter what language you use. Requiring each language to reimplement aptitude or emerge or macports or homebrew or asdf or rpm or gems in its own quirky way is bad for both end users and library developers.
An installed package has and fulfills dependencies, no matter what language you use. Requiring each language to reimplement aptitude or emerge or macports or homebrew or asdf or rpm or gems in its own quirky way is bad for both end users and library developers.
Part of the reason that Python has no canonical package management is that it is rooted in Linux, where the distro is perfectly capable of handling the task of package installation. It's an unfortunate artifact of shitty software management in Windows and OSX that we even have language-centric package management at all.
Fantastic! Of course it's a bit of a bummer that as a dev I now have to handle setting up my python package so that it is acceptable to each of the major Linux distributions. And as a user, it does kind of suck, having to wait for said distributions to publish the package.
I see language-specific package managers as being complementary to system package management, not competition. A ruby gem to me is the equivalent of distributing a package written in C via a tarball/autotools, except it is much more user-friendly. As a developer, I can publish the gem myself, without having to fight with the distribution managers over the one true way to package up my software. In fact, that whole fight can be handled by the language package management system - so for example you only need rubygems to be compliant with Debian's rules, or Fedora's, and it will correctly install gems for your system, in much the same way that each distribution has its own implementation of pkg-config for autotools. Admittedly there have been many bitter battles when this has failed to be the case, but technically there is nothing stopping this from being a very effective, and flexible way of distributing software.
Fantastic! Of course it's a bit of a bummer that as a dev I now have to handle setting up my python package so that it is acceptable to each of the major Linux distributions. And as a user, it does kind of suck, having to wait for said distributions to publish the package.
I see language-specific package managers as being complementary to system package management, not competition. A ruby gem to me is the equivalent of distributing a package written in C via a tarball/autotools, except it is much more user-friendly. As a developer, I can publish the gem myself, without having to fight with the distribution managers over the one true way to package up my software. In fact, that whole fight can be handled by the language package management system - so for example you only need rubygems to be compliant with Debian's rules, or Fedora's, and it will correctly install gems for your system, in much the same way that each distribution has its own implementation of pkg-config for autotools. Admittedly there have been many bitter battles when this has failed to be the case, but technically there is nothing stopping this from being a very effective, and flexible way of distributing software.
I think you are conflating what is a people problem, with a technology one.
People make different naming choices - for example , take a look at distro specific installation information at http://code.google.com/p/neuroinfotoolkit/wiki/Installation
In ruby, I simply have to do gem install ABC and I have it regardless of distro.
I would accept your argument if python were giving library installation instructions in terms of distro-independent puppet configuration - but basically, you do have to build the abstraction somewhere.
Its not about technology - I think lisp has a bunch of different package managers and it is the same problem that ruby solves using gem (bad example?). Clojure has different package-management tools, but a single packaging format - that would have been a recipe for future disaster which hopefully has been averted (http://groups.google.com/group/clojure/browse_thread/thread/...)
People make different naming choices - for example , take a look at distro specific installation information at http://code.google.com/p/neuroinfotoolkit/wiki/Installation
In ruby, I simply have to do gem install ABC and I have it regardless of distro.
I would accept your argument if python were giving library installation instructions in terms of distro-independent puppet configuration - but basically, you do have to build the abstraction somewhere.
Its not about technology - I think lisp has a bunch of different package managers and it is the same problem that ruby solves using gem (bad example?). Clojure has different package-management tools, but a single packaging format - that would have been a recipe for future disaster which hopefully has been averted (http://groups.google.com/group/clojure/browse_thread/thread/...)
I think this is the opposite of what happened. Python packaging works perfectly — operating systems and external packaging managers have no business managing python packages.
The Gem system has endured its own share of controversy, but it's certainly helped Ruby that there's been "one way to do it" when it comes to package management for so long.
yes, it's the same story when someone asks for an IDE - most guides are just a list of 20 IDEs without any commentary or opinion - despite the fact that some of them represent centuries of developer effort, while others are one guy's 6 month project. It took me a while to find the one I like (Wing IDE)
Wow I really love the idea of a general guide to all things related to a language like this. One of the hardest parts of learning a new language is figuring out what are the best sources of information. I can't wait to see when this is a bit more fleshed out.
What's your language of choice? I don't see any reason there shouldn't be "Hitchhiker's Guide to X" for your favorite X.
Not even a "Don't panic!" on the first page of the guide? (http://docs.python-guide.org/en/latest/index.html) I'm disappointed.
http://docs.python-guide.org/en/latest/index.html
Link to actual guide
Link to actual guide
This is a really cool idea, but the name makes me wince.
The "real" Hitchhiker's Guide to the Galaxy is described as being a singularly unhelpful book. It "contains much that is apocryphal, or at least wildly inaccurate," but is profitable because of its affordability and the friendly words on the cover. It is as likely to lead you into danger as to help you out of it, which shouldn't be surprising since its editorial staff spend most of their time partying and making up facts to put in the book. Arthur (like the reader) is initially enamored of its space-age technology, but other characters refer to it as "oh, that thing". It's a tabloid rag-- more like a for-profit Encyclopedia Dramatica than Wikipedia.
I know, it's a silly nit to pick, but I often feel like people kind of miss the point of the series.
The "real" Hitchhiker's Guide to the Galaxy is described as being a singularly unhelpful book. It "contains much that is apocryphal, or at least wildly inaccurate," but is profitable because of its affordability and the friendly words on the cover. It is as likely to lead you into danger as to help you out of it, which shouldn't be surprising since its editorial staff spend most of their time partying and making up facts to put in the book. Arthur (like the reader) is initially enamored of its space-age technology, but other characters refer to it as "oh, that thing". It's a tabloid rag-- more like a for-profit Encyclopedia Dramatica than Wikipedia.
I know, it's a silly nit to pick, but I often feel like people kind of miss the point of the series.
The name makes me wince as well.
This is because Python is a rather simple and straightforward language. It's not the sort of language that makes you panic at all when you first see it. It doesn't fit. Python is not a "seat of your pants, what the hell is going on, what do you mean my house is being demolished today?, oh the plans on display in the disused lavatory with the sign marked "beware of the leopard"?, oh well may as well enjoy the ride" type of language. The Python community is co-opting the wrong name.
There's gotta be a million better names to use. Some Monty Python-related ideas:
* Yorkshireman's Python Guide: You've got it easy!
* Python Guide: It's wafer thin!
* Python Guide: I like it runny!
* Self-defense against fresh Python: A guide
* Python! Wink wink, nudge nudge, say no more!
* Spam-free guide to Python
* Python: Our chief weapon is simplicity ... simplicity and readability ... readability and simplicity ... Our two weapons are simplicity and readability ... and namespaces .... Our three weapons are simplicity, readability, and namespaces ... and an almost fanatical devotion to Guido .... Our four ... no ... Amongst our weapons .... Amongst our weaponry ... are such elements as simplicity, readability .... I'll come in again.
This is because Python is a rather simple and straightforward language. It's not the sort of language that makes you panic at all when you first see it. It doesn't fit. Python is not a "seat of your pants, what the hell is going on, what do you mean my house is being demolished today?, oh the plans on display in the disused lavatory with the sign marked "beware of the leopard"?, oh well may as well enjoy the ride" type of language. The Python community is co-opting the wrong name.
There's gotta be a million better names to use. Some Monty Python-related ideas:
* Yorkshireman's Python Guide: You've got it easy!
* Python Guide: It's wafer thin!
* Python Guide: I like it runny!
* Self-defense against fresh Python: A guide
* Python! Wink wink, nudge nudge, say no more!
* Spam-free guide to Python
* Python: Our chief weapon is simplicity ... simplicity and readability ... readability and simplicity ... Our two weapons are simplicity and readability ... and namespaces .... Our three weapons are simplicity, readability, and namespaces ... and an almost fanatical devotion to Guido .... Our four ... no ... Amongst our weapons .... Amongst our weaponry ... are such elements as simplicity, readability .... I'll come in again.
How about this as a compromise:
if they come up with a cover for the book, the cover will read, in large friendly letters, "Don't Panic! The python doesn't bite."
if they come up with a cover for the book, the cover will read, in large friendly letters, "Don't Panic! The python doesn't bite."
Eff yeah.
This is a great outline for building out your knowledge of Python (or any tech, really). Even where there are stubs, it still points to something you should learn about (and then possibly fill in the stub).
This is a great outline for building out your knowledge of Python (or any tech, really). Even where there are stubs, it still points to something you should learn about (and then possibly fill in the stub).
I should prefer books that include free source code, for example pro python doesn't.
when I got started with programming (c), I wondered why not use whitespace instead of curly braces. Then I found Python and its community and I fell in love. Love this idea as well. I will help with what I can.
Great idea. What do you think of the Mark Lutz books.
Is there anything like this for ruby?
I should prefer books that include source code, for example pro python doesn't.
Can you use Python for Android programming? Java is truly unbearable :(
Scripting Layer for Android supported by Google themselves ( http://code.google.com/p/android-scripting) that lets you program in Python among other scripting languages (Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell)
In almost any language community there is usually an established set of best practices and tools but this can be a quickly moving target, which leaves behind a confusing array of deprecated tools and frameworks that were once the community's preferred way of doing things. Having a running document that keeps everyone up to date helps immensely with adoption. I'd love to see something similar for other communities.