Fortunately, you've left that madness behind, and entered the clean, happy, and safe Python world of transvestite lumberjacks and singing Vikings.
-- Quinn Dunkan, 17 Sep 2000

Regular expressions are among my most valued tools, along with goto, eval, multiple inheritance, preemptive multithreading, floating point, run-time type identification, a big knife, a bottle of bleach, and 120VAC electricity. All of these things suck sometimes.
-- Kragen Sitaker, 27 Sep 2000

The most successful projects I've seen and been on did rewrite all the code routinely, but one subsystem at a time. This happens when you're tempted to add a hack, realize it wouldn't be needed if an entire area were reworked, and mgmt is bright enough to realize that hacks compound in fatal ways over time. The "ain't broke, don't fix" philosophy is a good guide here, provided you've got a very low threshold for insisting "it's broke".
-- Tim Peters, 25 Oct 2000

Humour is a tricky thing. Some people can't even get the spelling right.
-- Richard Brodie, 30 Oct 2000
( Read more... )

Начало - http://vorushin.livejournal.com/205511.html
Источник - http://www.amk.ca/quotations/python-quotes/

Нашел подборку цитат от разработчиков языка Python (этакая история языка в цитатах):

I've seen Python criticized as "ugly" precisely because it doesn't have a trick-based view of the world. In many ways, it's a dull language, borrowing solid old concepts from many other languages & styles: boring syntax, unsurprising semantics, few automatic coercions, etc etc. But that's one of the things I like about it.
-- Tim Peters, 16 Sep 1993

Python is an experiment in how much freedom programmers need. Too much freedom and nobody can read another's code; too little and expressiveness is endangered.
-- Guido van Rossum, 13 Aug 1996

I mean, just take a look at Joe Strout's brilliant little "python for beginners" page. Replace all print-statements with sys.stdout.write( string.join(map(str, args)) + "\n") and you surely won't get any new beginners. And That Would Be A Very Bad Thing.
-- Fredrik Lundh, 27 Aug 1996

One of my first big programming assignments as a student of computer science was a source formatter for Pascal. The assignment was designed to show us the real-life difficulties of group programming projects. It succeeded perhaps too well. For a long time, I was convinced that source code formatters were a total waste of time, and decided to write beautiful code that no automatic formatter could improve upon. In fact, I would intentionally write code that formatters could only make worse.
-- Guido van Rossum, 31 Mar 1998

This is Python! If we didn't care what code looked like, most of us would probably be hacking in some version of Lisp -- which already covered most of Python's abstract semantics way back when Guido was just a wee snakelet frolicking in the lush Amsterdam jungle.
-- Tim Peters, 24 Apr 1998
( Read more... )

Источник - http://www.amk.ca/quotations/python-quotes/ (я прочитал пока только первые 5 частей :)))))

Одна из серьезнейших причин любить Python - это питонисты :)))) Вокруг этого языка собралось действительно интересное сообщество!!!

Вот сегодня обнаружил - http://pythonlabs.com/ (текст на английском, одна страничка, подымает в небеса и заставляет улыбаться!!!!!)

Upd. А вот тут можно полюбоваться на питонистов - http://www.flickr.com/photos/termie/sets/72157616044454732/

Посмотрел как правильно документировать проекты, написанные на Python, рассказываю:

Забудьте про javadoc-style (вы ведь поставляете исходники, а не скомпилированный модуль)

Используйте string literals в начале модуля, класса, функции для комментирования по сути - что это и зачем. Если написать нечего - ничего вообще вставлять не нужно, никаких пустышек-заменителей. Никаких особых символов использовать не нужно - обычный человеческий хорошо написанный текст. Параметры функций расписывать не нужно - разве что написать про некоторые особо важные. Вместо этого лучше сделать имена параметров самоописательными.

Используйте обычные комментарии # там где это полезно. Вообще правильно считать и string literals и # частью кода. Там где код говорит сам за себя, там вообще не нужны комментарии. Лучше упростить код и убрать лишние комментарии. Код должен быть простым и красивым. Писать на Python проекты - это как писать книгу.

Для design-level документации: либо используйте Sphinx, либо просто любимую wiki. Если документации много, много авторов и много версий проекта - лучше выбрать Sphinx. Он как wiki, которая хорошо понимает Python и текст документов которой хранится рядом с кодом в svn/mercurial/git/bazaar. Для примера - сайты с документацией к Python и Django генерируются при помощи Sphinx.

И всё :))))

Всем, кто пишет на Python и частенько вызывает всякие веб-сервисы, интересно будет узнать что вышла библиотека httplib2 версии 0.5

Версия 0.4 тоже работала неплохо, но не очень дружила с Python 2.6 и 3.0, а у этой версии уже всё с этим хорошо. Также добавлена поддержка Google Account Authentication

http://code.google.com/p/httplib2/

Напишите в консоли:

python
>>> import this

И получите:

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Люблю этот язык!