* the site module, which is imported by default and is what is responsible for setting up the default sys.path. You can skip 'import site' by running python with the -S switch. the site module is written in python, so you can scan through it and understand how python starts up and inits.
* PYTHONSTARTUP env variable, which points to a python file that is run (like a bashrc, or AUTOEXEC.BAT, if you prefer) on interactive prompt startup. I use this to import custom paths and modules that I want to access from the REPL, such as Google App Engine
* I use pip with local repositories. clone the repos of the libs you need, and then pip install in the virtualenv from that local clone:
$ pip install git+file:///Users/nik/.python-packages/tornado
$ pip install git+git://email@example.com/nikcub/tornado
* don't store the actual project inside the virtualenv. the virtualenv provides the execution context (setup and torn down using the virtualenvwrapper helper scripts). a common practice is to place all your virtualenvs into a directory like ~/.virtualenvs. you should never have to cd into this dir, access it using the wrappers and pip. (edit: also agree with comment below that you shouldn't be sudo'ing).
* just a quick add, I think it is definitely worth learning how to install python from source.
* coloured prompt
* persistent history
It might be matter of taste but recommendations given starting from "Understanding the packages" and to "Install packages that need compiling" are almost harmful.
* you should not care what is your `sys.path` looks like. You need it for debugging if something goes horribly wrong. A tutorial might mention it but things like `sys.path.insert(0,..)` should be avoided or accompanied with a big disclaimer (don't use nuclear weapons if you care about the future)
* the same goes for `PYTHONPATH`. It is a hack that rarely
* don't use `sudo pip`. System packages should be managed by a system packager. Use `pip --user` or create a `virtualenv`
* `pip` can handle tarballs there is no need for `python setup.py install` in this case.
"Code Like a Pythonista: Idiomatic Python" is worth mentioning
Some third-party packages that could be listed (it is subjective):
bpython - interactive prompt; something for tests e.g., pytest, tox, selenium; sphinx - docs; lxml - xml/html, werkzeug - if you talking about web-development; SQLAlchemy - sql; Cython - C extension, ~ Python syntax; async. libs e.g., gevent, Twisted.
In general, your feedback is very good and important. Idiomatic Python specifically is an important resource and should have been included.
I will incorporate your feedback as soon as I can squeeze out some time.
What are your reasons for preferring pylint?
You shouldn't be using the system Python. Should compile from source and put in /opt/<name of company>/. And that shouldn't be owned by some random user. So, you should be using sudo.
I'm pretty sure a "Ruby Ecosystem, An Introduction" guide is exactly what I need.
- Use http://beginrescueend.com/ to install ruby itself
- Use http://gembundler.com/ to manage project-level dependencies
Both of those sites have good examples, but if no one steps up I might just write something like the linked guide when time frees up.
It seemed to cover everything that I wanted, coming from a familiar Python background of pip/virtualenv/etc. For reference here's the associated HN commentary:
The post was extracted from our internal wiki, the content in which has evolved over past 2 years and spread all over.
It took me about 20-25 hours, spread over 3 weeks, to put it in the shape of a single post/tutorial.
It looks like you're covering a lot of the same ground.
I would apply the "if you need to" part to Python 2. "3 if you can, 2 if you must"
Novice: "I want to do X"
Internet advice: "Use package Y"
Novice: "Okay <install, install>, wtf nothing is working"
<long frustrating debugging session>
Novice: "Oh, wow, this doesn't support Python3 yet. Now I have to ignore all the internet advice and forge my own path, OR port all my code back to 2.7! This language sucks!"
The alternative seems preferable:
Stuff works, but occasionally you don't get a whiz-bang feature (you "only" get 2.7's feature set, poor you). Five years pass, you learn the language. Now you've gotta learn a bunch of new habits, which sucks, but it's not as bad because now you're pretty good at Python, so the easy parts are easy.
More and more questions have problems that can be solved by Python 3, but it's probably a pain in the ass if you start with 3 then work out how to solve your problem.
tl;dr "If 3 does everything you need, great. However, there's a good bit of things that still don't work with 3, in which case 2 is the safer choice. Here's a pretty long list of reasons why 2 is probably better for you. ..."
But I bet within a year, that's no longer true. (This is dependent on package migration, but there's been a lot of progress lately, and the chances of a novice needing a sophisticated package day one is slim anyway.)
There are a few items that Python 3 fixes that will make this a no-brainer when the vast majority of major packages are ported to 3. Specifically, floating point results of integer division, and print as a function are two that come to mind.
I can't tell you how many times I cursed at the same bug as a beginner (back before division was importable from __future__). 1/2 + 1/2 = 0. Uggh!
And the beginner may as well get in the habit day 1 of using parentheses in statements like print("Hello World").
That said, I try to use any backported 3.0 features such as .format for string formatting. And for beginners, I heartily recommend using the 'six' module. That way when you need to move to 3.0, porting your code or your skills, will be easy-peasy.
Actually, it is :)
pip install pep8
I am indebted to HN community for the great feedback so far.
You should not mix multiple packaging system on your operating system.
And more you can dammage it pip provide more recent package than your distro. And if you upgrade a lib that have an incompatibility with a part of the system, you can corrupt it. I have no example to give but I am sure you can find it... Ubuntu now have many tools written in python.
You should use pip inside a virtualenv only.
And, fortunatelly when you create a virtualenv, pip is installed in it, and you don't need to use the --distribute to have it.
But for app development, get your own Python, manage it yourself and install 'distribute' so that you have both easy_install and pip to work with. I've taken that to extreme by making a portable Python distro that comes in a tarball and runs on any Linux distro, but even if you only untar the source and run ./configure --prefix=/home/python;make
That will build a default Python with support for any shared libraries for which you have a development version installed ( -dev version on debian/ubuntu, -devel version on redhat/suse)
sudo make install will install it, assuming that you have write permissions on the target prefix that you specified. You can even hide it in your home directory with --prefix=~/tools/python272
If you do not, you also have those tools.
I would only add iPython - a must for any console adventures.
There used to be a problem with certain statements being executed as expressions and printed, but I'm told that's been fixed.
The encoding is always Latin-1. Always. Hope you don't use Unicode literals.
It's not Python. It's Python plus other things. That's always a Bad Thing because it precludes taking results from the interpreter and using them in plain Python contexts. web2py also has this problem.
Or even better, give them a stackoverflow search like this one http://stackoverflow.com/search?q=%5Bpython%5D+%22install+py...
P.S. I think that your wiki page is a great idea and I'm going to write a custom one for our developer wiki.
Also The Zen of Python can always be accessed by this Easter egg
>>> import this
IMHO this is more useful in the long run ...
As per the Pragmatic Programmer, I thought I would learn Python this year. It's been a tremendously frustrating experience getting a workable stack installed.
I wish the famous "One -- and preferably only one -- obvious way to do it" Python design philosophy extended to actually installing everything :(
If you're on Ubuntu LTS you should install PIP from PyPI (easy_install pip), since the system package management version is outdated and it doesn't have the (very useful, since PyPI likes to go down) --use-mirrors install option. That would be my only recommendation.
It's the Python version of RVM. It is higher level than even virtualenv, and in my opinion, the most seamless way to manage Python environments.
I should say I still love python. Its the most fun I've had programming next to Scheme, and well, NodeJS is kind of fun too (in an algol way).
Also, I wouldn't like to install some packages system-wide (a friend's personal project from a github repository) so I use pip and virtualenv in a similar manner as the article recommends to maintain a per project dependency library.
That's how I see it :)
That way you can get started with coding instead of having to install everything by yourself.