Kenneth Reitz - Python for humans
Kenneth Reitz talks about Python for humans, at PyGrunn.
See the PyGrunn website for more info about this one-day Python conference in Groningen, The Netherlands.
Follow me on twitter: @kennethreitz_. I work at Heroku. I am a member of the Python software foundation. I created the requests library that makes is easier for humans to retrieve a web page in Python.
I want everything I build to be open source. I build for open source, pretend it is open source even when it will never be released to the public because it is too client specific. Add documentation, please, also to your internal tools.
Open your Python prompt and see the Zen of Python:
>>> import this
Beautiful is better than ugly: you don't need lots of curly braces in Python. Explicit is better than implicit.
Most importantly for today: there should be one - and preferably only one - obvious way to do it.
Welcome to paradise. You have found Python, a language with a beautiful zen philosophy and all is going to be fine. Lies!
Look at some Ruby code to download the contents of an https web page. Perhaps a bit too many lines, but it is pretty straight forward. Now you switch to Python. Which library? urllib, urllib2, something else? Okay, you use urllib2 and then you have to add some password manager and lots more lines that are unclear. You will leave and never come back.
This is a serious problem. I think HTTP should be as simple as a print statement. It is used so often! Our world is connected over HTTP right now so we need this to be simpler.
Python needs more Pragmatic Packages. Deal with things sensibly and realistically, in a way that is based on practical rather than theoretical considerations. Make it practical for humans, for the common case.
The requests library is HTTP for humans. A small set of methods with consistent parameters. Do this for more modules! Fit the ninety percent use case. Features, efficiency, performance, etcetera are important, but you should ignore them for such a practical package. Go for the common case. Write the README the way you think it is supposed to work.
"Cool story, bro, but why should I do with this?" It's worth your time and everyone else's time as a developer.
Some things that could be improved:
- File and system operations. We have the modules, sys, shutils, os, os.path, io. Which should you use for a task? It is really difficult to run external commands and this blocks dev+ops folks from using Python.
- For installing Python there are various ways. Use the Python that came with the system or compile your own? Python 2 or 3?
- XML hell. etree annoys people. lxml is awesome, but can be difficult to install.
- Packaging and dependencies. Pip or easy_install? How about an easy_uninstall? Distribute or setuptools? [Holger Krekel will talk about this topic later today in the keynote.]
- Dates, datetimes. Which module: datetime, date, time, calendar, dateutil, version 1.5? Timezones, they are ridiculous.
- Unicode. We'll just skip that one.
- Testing. Lots of different ways to create tests. Doctests and unit tests. Various test runner libraries, like nose and tox.
- Installing dependencies. Python-mysql, if you remember the exact name. (My solution: just use Postgres.) Python Imaging Library needs several system packages before you can install it. mod_wsgi: if you install this, which Python version are you using, the one from the system?
Hitchhiker's guide to Python: http://python-guide.org The goal of this project is to write down the tribal logic, documenting best practices. A guide book for newcomers. A reference manual for seasoned pros. It tries to document the one - and preferably only one - obvious way to do it. Please contribute documentation here. This lets of practice what we preach.
Lets fix our APIs and improve our documentation.
requests might get into core at some point.
requests started as a wrapper around urllib2. It was a nightmare. It now uses http to handle the lower level parts.
If I would have said 'yes' to all feature proposals for requests, it would have been too much. People can write a library around requests. Saying 'no' made it possible to create and maintain a good architecture.