Pull to refresh

Comments 56

Последние абзацы холиварны. Связи между {язык программипрвания} и понятием качества, имхо, нет.
Качество в данном случае в широком смысле: это и скорость разработки, и большое сообщество разработчиков, и стоимость поддержки решения, и возможности самого языка и еще куча плюсов.
UFO just landed and posted this here
Смотря какой язык. Все они разные, не так ли? У кого-то может быть больше, у кого-то меньше.
UFO just landed and posted this here
Один из самых сильных языков, да. Но нужно еще смотреть на задачу. Для больших веб-проектов питон хорошо подходит в целом.
Утверждение «Вася — хороший программист» не означает, что все остальные поголовно являются плохими программистами. Это всего лишь означает, что Вася является хорошим программистом.
UFO just landed and posted this here
Хотел было попробовать Джанго с Питоном на зуб, но узрев код скрипта-установщика pip — убоялся… смотрите сами: raw.github.com/pypa/pip/master/contrib/get-pip.py. В скрипт строкой впилить архив… в общем, желания пробовать поубавилось.
Доисторическую эпоху напомнило…
А где связь языка/платформы с творением отдельно взятого разработчика на этом языке/платформе?
Это ведь не просто «отдельное творение отдельного разработчика», а средство установки, указанное в официальной документации. Соответственно, когда я вижу такой код по ссылкам из документации, падает уровень доверия к платформе в целом. Если бы это был «чей-то там скрипт» — такой реакции бы не было.
Ну, для начала, там сверху есть интересный комментарий:

> # Hi There!
> # You may be wondering what this giant blob of binary data here is, you might
> # even be worried that we're up to something nefarious (good for you for being
> # paranoid!). This is a base4 encoding of a zip file, this zip file contains
> # an entire copy of pip.
> #
> # Pip is a thing that installs packages, pip itself is a package that someone
> # might want to install, especially if they're looking to run this get-pip.py
> # script. Pip has a lot of code to deal with the security of installing
> # packages, various edge cases on various platforms, and other such sort of
> # «tribal knowledge» that has been encoded in it's code base. Because of this
> # we basically include an entire copy of pip inside this blob. We do this
> # because the alternatives are attempt to implement a «minipip» that probably
> # doesn't do things correctly and has weird edge cases, or compress pip itself
> # down into a single file.

Если такого объяснения недостаточно, то расскажите, как бы вы сделали такой бутстрап скрипт.
Так, как это сделали, например, с Qt. Я имею дело с Windows, соответственно, хотелось бы видеть просто setup.exe, без необходимости устанавливать что-то для установки чего-то. Ничего не мешало просто доделать работу до конца, не заставляя лишний раз думать того, кто будет использовать платформу.
Ох, я даже не знаю, с чего начать. Наверное, нужно начать с такой штуки как Unix way. Unix way — это неформальный набор правил, который использовался разработчиками одноимённой системы и затем был перенят многими несистемными программистами. Один из пунктов этих правил гласит: «Пишите программы, которые делают что-то одно и делают это хорошо». И если насчёт готовых программ ещё можно поспорить, то с тем же тезисом в отношении библиотек, наверное, согласятся все: если всё, что вам нужно — это разобрать JSON, то хочется иметь библиотеку именно для разбора JSON, а не тянуть за собой огромного монстра, умеющего работать с XML, HTML, YAML, сохранять результаты на диск и проводить по ним полнотекстовый поиск. Но тут возникает извечная проблема: поскольку библиотеки (или готовые программы в философии Unix) делают только что-то одно, они неизбежно начинают зависеть друг от друга. Когда количество зависимостей переваливает за десяток, установка их всех по отдельности становится проблемой. Если попробовать применить здесь вашу идею с setup.exe, то получится десять отдельных установщиков, которые все нужно вручную скачать, установить и сконфигурировать для работы друг с другом. В то же время, в Unix системах для этого давно придумали менеджеры пакетов: вы просто указываете имя нужного пакета, а менеджер сам определяет зависимости (вместе с версиями), находит их в репозитории, скачивает и устанавливает. Вам даже не обязательно при этом следить за процессом.

pip — это классический менеджер пакетов, только не для ОС, а для конкретного языка. Вы можете работать и без него — скачивать исходники и руками раскладывать в нужные директории, или, в некоторых случаях, даже запускать готовые exe-шники (все десять). Но действительно ли вы считаете такой подход удобным, а менеджеры пакетов — недоделанной работой, заставляющей лишний раз думать?
Я не против менеджеров пакетов — я за предельную простоту установки. Download — Wait — Work, так скажем.
Что касается Windows, есть например Web PI — менеджер-пакетов для веб-платформ и MSVS, внутри самой MSVS есть NuGet — это всё замечательные вещи и, кстати, Web PI учитывает зависимости. А setup.exe, если он не учитывает зависимости, работу с реестром и прочие тонкости типа регистрации dll, это уже не setup, а просто архив с расширением exe…
pip install django
что может быть проще?
Во-первых, перед тем, как сработает ваша строка, нужно скачать этот самый get-pip.py, открыть его питоном, чтобы — в конце концов — получить такой вот вывод
в консоль...
Downloading/unpacking django
Downloading Django-1.6.2.tar.gz (6.6MB): 6.6MB downloaded
Running setup.py egg_info for package django
Traceback (most recent call last):
File "", line 3, in File «C:\Python27\lib\site-packages\setuptools\__init__.py», line 2, in <m
odule>
from setuptools.extension import Extension, Library
File «C:\Python27\lib\site-packages\setuptools\extension.py», line 5, in <
module>
from setuptools.dist import _get_unpatched
File «C:\Python27\lib\site-packages\setuptools\dist.py», line 15, in <modu
le>
from setuptools.compat import numeric_types, basestring
File «C:\Python27\lib\site-packages\setuptools\compat.py», line 19, in <mo
dule>
from SimpleHTTPServer import SimpleHTTPRequestHandler
File «C:\Python27\lib\SimpleHTTPServer.py», line 27, in class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):
File «C:\Python27\lib\SimpleHTTPServer.py», line 208, in SimpleHTTPRequest
Handler
mimetypes.init() # try to read system mime.types
File «C:\Python27\lib\mimetypes.py», line 358, in init
db.read_windows_registry()
File «C:\Python27\lib\mimetypes.py», line 258, in read_windows_registry
for subkeyname in enum_types(hkcr):
File «C:\Python27\lib\mimetypes.py», line 249, in enum_types
ctype = ctype.encode(default_encoding) # omit in 3.x!
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 0: ordi
nal not in range(128)
Complete output from command python setup.py egg_info:
Traceback (most recent call last):

File "", line 3, in File «C:\Python27\lib\site-packages\setuptools\__init__.py», line 2, in <modul
e>

from setuptools.extension import Extension, Library

File «C:\Python27\lib\site-packages\setuptools\extension.py», line 5, in <modu
le>

from setuptools.dist import _get_unpatched

File «C:\Python27\lib\site-packages\setuptools\dist.py», line 15, in from setuptools.compat import numeric_types, basestring

File «C:\Python27\lib\site-packages\setuptools\compat.py», line 19, in <module
>

from SimpleHTTPServer import SimpleHTTPRequestHandler

File «C:\Python27\lib\SimpleHTTPServer.py», line 27, in class SimpleHTTPRequestHandler(BaseHTTPServer.BaseHTTPRequestHandler):

File «C:\Python27\lib\SimpleHTTPServer.py», line 208, in SimpleHTTPRequestHand
ler

mimetypes.init() # try to read system mime.types

File «C:\Python27\lib\mimetypes.py», line 358, in init

db.read_windows_registry()

File «C:\Python27\lib\mimetypes.py», line 258, in read_windows_registry

for subkeyname in enum_types(hkcr):

File «C:\Python27\lib\mimetypes.py», line 249, in enum_types

ctype = ctype.encode(default_encoding) # omit in 3.x!

UnicodeDecodeError: 'ascii' codec can't decode byte 0xc2 in position 0: ordinal
not in range(128)


Cleaning up…
Command python setup.py egg_info failed with error code 1 in c:\users\3c8a~1\app
data\local\temp\pip_build_╚трэ\django

Traceback (most recent call last):
File «C:\Python27\Scripts\pip-script.py», line 9, in load_entry_point('pip==1.4.1', 'console_scripts', 'pip')()
File «C:\Python27\lib\site-packages\pip\__init__.py», line 148, in main
return command.main(args[1:], options)
File «C:\Python27\lib\site-packages\pip\basecommand.py», line 169, in main
text = '\n'.join(complete_log)
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc8 in position 70: ordinal
not in range(128)

C:\WINDOWS\system32

… тогда как работа с предлагаемым установщиком сведётся к нескольким кликам, что явно проще, а здесь ещё надо думать о причинах возникших ошибок.

О, поздравляю! Вы поймали наверное самую распространённую проблему с Python 2.x. Если вкратце, строки в Python до версии 3 были байтовыми (вот такое вот наследие от C), поэтому работа со всеми кодировками, кроме ascii, всегда была той ещё занозой в заднице. С какой-то версии появился даже специальный тип — unicode, который как str, только поддерживает больше символов. В Python 3 это дробление наконец убрали, сделав все строки юникодовыми, а для байтовых массивов выделив отдельный тип.

Судя по стектрейсу, в вашем конкретном случае не-ascii символы пришли из реестра Windows и были неправильно обработаны модулем mimetypes. Самым простым (и правильным!) способом пофиксить это будет переход на Python 3. Тем более, что Django (как и большинство мажорных библиотек) давно его поддерживают. Если это по какой-то причине не подходит, то можно пойти в другую сторону и даунгрейдить Django до 1.5. Ну и, если уж совсем заморочиться, можно поставить try-except вокруг строки 249 файла mimetypes.py и посмотреть, что ж там за запись в не-ascii кодировке.

Пишите, если будут ещё проблемы. Если не считать пары-тройки заморочек типа кодировок, Python и Django очень даже удобные и приятные в использовании инструменты ;)
О третьем питоне я подумал. Тут уже, что называется, спортивный интерес включился. :) спасибо, в случае чего напишу, хотя обычно обходилось цитированием текста ошибки в гугл.
Дело совсем не в том, что мне лень разбираться или что-то там ещё. Дело именно в уровне доверия к платформе, которая, как можно видеть на практике, не заботиться о том, чтобы пользователям было просто удобно и хорошо. То есть когда сразу, прямо с лица видишь ошибки, то сразу задумываешься о том, ждать ли хорошего внутри.
Вот о чём речь.
Можно и на втором остаться.
Не хочу разводить холивар между вторым и третьим, но уж больно много наработок на втором, которые на третий до сих пор не портированы.
Ниже написано вкратце как можно решить вопрос, но я чуть поподробнее ссылку дам — может кому пригодится.

Чтобы на втором остаться, надо в исходниках чуть подправить (чем ведь ещё хорош питон, меж прочим :))
Вот ветка с разными вариантами решения этой проблемы.

UnicodeDecodeError: 'ascii' codec can't decode byte 0xe0 in position 0: ordinal not in range(128)
Да, есть ещё библиотеки, которые не портированы на Py3k, в том числе очень большие и важные. Лично для меня это Python обёртка вокруг OpenCV, и пока я не слышал ни про какие потуги по исправлению данной ситуации. Однако если начинать с нуля, да ещё и заниматься веб-программированием, то Py3k вероятно всё-таки даёт больше плюсов, чем минусов.
Ой, да придирки какие-то. В чем сложность скачать get-pip.py? Setup.exe тоже нужно будет скачивать. Открыть питоном? Ну так если человек собрался разрабатывать под питон, то он у него в любом случае установлен.

Исключение бросается из-за кириллицы в ключах виндового реестра и инсталлятор pip тут не при делах. Он отлично работает на всех платформах от макоси до винды. Ну а то, что миметайпс валится от (не)православной кодировки, то инсталлятор тут не виноват. Проблема решается буквально за минуту: либо добавляем print ключа реестра и смотрим, что нужно поправить в своем реестре, либо допиливаем мимитайпс, для работы с соответствующей кодировкой или просто просто обрабатываем исключение. В любом случае, если не нравится такой подход к инсталляции, то ничто не мешает поставить pip через easy_install — традиционное и кошерное решение.
Всё на самом деле очень просто: если пользователю продукта неудобно использовать продукт, по абсолютно любой причине, не суть важно, какой именно, — пользователь продукта скорее всего устанет от заморочек и не будет использовать продукт.
Всё, чего я хочу, как пользователь — это чтобы то, что должно работать, просто работало.
И пускать в продакшн такие продукты для программистов… ну, это всё равно, что портному продавать не одежду, а схему кройки и ткань — сам мол разберётся, он же портной. Да и то, сам факт существования таких ошибок говорит о том, что ткань не качественная.
Иными словами это не я должен думать о том, какой у меня реестр, в данном конкретном случае. Это они должны думать о том, чтобы мой реестр — каким бы он ни был — не помешал установке продукта.
Вот тут вы не правы — вам никто ничего не должен. Равно как и вы ничего не должны создателям. В этом суть любого опен сорса (ну ок, почти любого): люди объединяются для того, чтобы вместе сделать то, что будет полезно всем. Если у кого-то из них возникают проблемы, другие пытаются ему помочь (в Python, кстати, одно из самых дружелюбных сообществ). Но никаких гарантий, естественно, никто давать не будет.

В вашем конкретном случае совпало сразу несколько обстоятельств:

1. Вы пользуетесь Windows. Python по большей части кроссплатформенный, но реальную мощь он обретает именно под Linux. А под Windows многие вещи просто не тестируются или тестируются поверхностно.

2. Вы начали сразу с фреймворка высокого уровня, не научившись пользоваться более простыми инструментами. Если бы вы попробовали обработать длинный текстовый файл, или скачать веб-страницу, вы бы наверняка нарвались на ошибку с кодировкой гораздо раньше и не пугались бы так из-за выскачившего сообщения.

3. Вам повезло взять именно ту версию Django, в которой возник этот баг: Google подсказывает, что откат до Django 1.5 действительно полностью решает проблему даже для Python 2.7.

В остальном же, в Python ну очень низкий порог вхождения.
Здесь речь не о том, что я умею и чего нет. Здесь речь о том, что мне нравится и что не нравится. Так вот, мне не нравится делать ту работу, которую должен делать разработчик продукта. Это не значит, что я этого не умею. Можете считать это наглостью, а я называю это «назвался груздем — полезай в кузов». Уж если разработчик продукта хочет, чтобы его использовали массово, то сделать его максимально удобным для людей — забота разработчика. Что касаемо сообщества, я туда направил письмо следующего содержания:

Заголовок
Доброго времени суток.
Очень бы хотелось в разделе загрузок на сайте Django видеть предельно простой standalone установщик для Windows, работа с которым сводилась бы к нескольким кликам. Я думаю, это способствовало бы популяризации фреймворка среди Windows-разработчиков, которым психологически более комфортно работать с GUI, а не командной строкой.
К тому же я имел неосторожность попытаться поставить последнюю версию Django на python 2.7 при помощи get-pip.py. Хотелось бы, чтобы скрипт установщик, кроме прочего, анализировал переменную среды PATH, по итогам анализа определяя установленную версию питона и при необходимости устанавливал ту версию питона, в которой интерпретация скрипта-установщика не вызовет юникод-ошибок (в моём случае ошибка была вызвана кириллическими символами в реестре и здесь возникает справедливое замечание о том, что это не я должен думать о том, какой у меня реестр, а разработчики должны думать о том, что нужно делать, чтобы мой реестр — каким бы он ни был — не мешал установке), закрывал файл установщика и открывал заново в корректной версии. После получения абракадабры про ошибки, желание работать с платформой не прибавляется… иными словами при виде таких ошибок прямо с лица платформы, желание работать с ней пугается самого себя и доверие к платформе резко падает.
Спасибо за внимание.
P.S. Де-юре в Microsoft Web PI присутствует Django, но де-факто размер пакета — 0 Мб, его там просто нет, насколько понял я.


Дают гарантию, что письмо будет прочитано человеком в течение нескольких дней, гарантию ответа, конечно, не дают. Посмотрим — увидим.
Можете считать это наглостью, а я называю это «назвался груздем — полезай в кузов». Уж если разработчик продукта хочет, чтобы его использовали массово, то сделать его максимально удобным для людей — забота разработчика.

1. Django — это не продукт. Вы за него не платите, а разработчики не берут на себя никаких обязательств.
2. У разработчиков нет непосредственной цели сделать так, чтобы их фреймворк использовался массово. По большому счёту, всё пишется для себя, чтобы использовать в своих проектах.
3. Добавление новых фич чаще всего работает так: появляется человек, которому это надо, он решает эту проблему для себя и выкладывает код для всеобщего доступа. Django (как и большая часть open source проектов) пишется не отдельными компаниями, а сообществом. Если хотите, чтобы появилась какая-то фича, просто сделайте её.
А setup.exe, если он не учитывает зависимости, работу с реестром и прочие тонкости типа регистрации dll, это уже не setup, а просто архив с расширением exe…

Возможно, я слишком давно не работал под Windows, но насколько я помню, большинство установщиков «учитывают зависимости» тупо засовывая их все в дистрибутив. Ну или, в крайнем случае, показывают сообщение о том, что нужно скачать то-то и то-то, и ссылку на страницу.

Я не против менеджеров пакетов — я за предельную простоту установки. Download — Wait — Work, так скажем.

Вам нужно понять, что «предельная простота» у разных людей ассоциируется с разными вещами. В том же Linux (по крайней мере в популярных дистрибутивах) идея о том, что зайти на сайт, согласиться с лицензионным соглашением, скачать библиотеку и пройти все пункты установщика — это просто, звучит довольно кощунственно. Хотя бы потому что у вас может не быть графического интерфейса ОС, браузера, и вообще вся установка должна делаться скриптом на 20+ машинах.
К счастью, я не жертва пропаганды Майкрософта: терминал Linux в своё время очень понравился в том числе по той самой причине, что не нужно идти на сайт качать дистрибутив, соглашаться с соглашением, которое зачастую почти не читаешь, если только речь не идёт о специальном и очень важном продукте [вводить серийный номер], (именно что набрал в лучшем случае пару строк и работай), но в данном конкретном случае речь идёт об установке веб-фреймворка, а значит об отсутствии браузера, а вместе с ним и GUI, речи быть не может.
Что касаемо установщиков, предлагается три естественных варианта загрузки: с сайта поставщика компонента, с собственного URL и да, из того, что запихали сразу. MSVS 2013 поставляется с возможностью загрузки специальной редакции InstallShield: learn.flexerasoftware.com/content/IS-EVAL-InstallShield-Limited-Edition-Visual-Studio?lang=1033&ver=pro.
А что касается установки какой-либо на энное количество серверов Linux — тут хочешь не хочешь, а надо с консолью работать, конечно…
но в данном конкретном случае речь идёт об установке веб-фреймворка, а значит об отсутствии браузера, а вместе с ним и GUI, речи быть не может.

О, видимо вы никогда не занимались развёртыванием веб-приложения на сервере через голый ssh ;)
Не часто появляется возможность указать питонщикам посмотреть на реализацию в пхп =) Но в данной ситуации это подходит. В похапе мире придумали «исполняемый архив» phar, который по сути является тар архивом с бутстрапом на пхп. В итоге очень удобно распространять скрипты со сложной структурой и поддерживается нативно пхп интрепретатором. Хотя с другой стороны выглядит он почти как и этот файл, лишь двоичные данные в конце а не в начале =)
Не хочется вас разочаровывать, но в Python есть довольно много способов упаковать приложение :) Например, вы можете создать zip-архив с файлом __main__.py на верхнем уровне и затем запустить его так:

python app.zip


Другой вопрос, что такое обилие вариантов не всегда идёт на пользу. Вот тут довольно хорошо расписаны варианты упаковки Python программ, и почему все они в некоторой степени отстойны :)
=) я знал что питониста нельзя словить на чем-то чего нет в питоне, но попробовать стоило
UFO just landed and posted this here
Если нечто делает свою работу хорошо, и вы не собираетесь лезть внутрь — пусть там хоть асемблер будет.
1. Остаётся только порадоваться за Python и пожелать дальнейшего развития.
2. Увы, но в Казани наблюдаю картину примерно следующую: есть проекты на Python, но питонистов мало, поэтому эти проекты переделывают на РНР.
3. Вы меня извините, но ужасно неудобно для просмотра сделана таблица. По ссылке на большую таблицу, ожидал действительно большой вариант, а там, увы, не то.
Да, специалистов катастрофически не хватает.
Таблица огромна, на влазит. Я бы её и сюда запихнул, но тоже не влезла.
Удаленку в Казани не любят? У нас 5 программеров со всех уголков Украины, сидят дома, общаемся по скайпу, всех устраивает
Не могу отвечать за всех, но у нас в компании удалёнщики есть, но мало.
Видимо, проще/дешевле взять местного рнр-шника, чем искать по всему миру питон-щика.
питонщики стоят на порядок дороже пхпешников
Я в переносном значении. Если уточнять, то зп на 20-50% выше у питонов. Это мое мнение на вскидку.
Возможно потому что удаленщикам уже лучше сразу работать с Odesk/Elance.
(многих сдерживает психологический фактор)
По моему мнению, если находишься не в 4х — 5ти крупнейших городах РФ, то западный фриланс логичный выбор.
Идея отличная, за статью спасибо.
Но все же есть неточности:
– Disqus частично перешел на Go, blog.disqus.com/post/51155103801/trying-out-this-go-thing
– Instagram еще на PyCon US 2013 рассказывали, что ушли с Gearman на RabbitMQ (+ Celery), us.pycon.org/2013/schedule/presentation/106/

Теперь ждем статью об python-проектах в рунете (Яндекс, Mail, Rambler, RBC, Островок, Lamoda, etc)
Подскажите побольше сайтов в рунете на питоне, мы подготовим материал.
d3.ru, price.ru. А больше я не знаю :)
«Уходить» с питона частями проекта — это нормальная практика.
Питон хорош для быстрого старта и прототипирования, но хайлоад все-таки лучше оставить компилируемым языкам.
Благо питон для этого заточен хорошо: можно переписать любой модуль на Си, прокинуть бинды и вуаля — остальной код менять не надо (обычно).
Ну и печалит, что на вашем же сайте 3 вакансии PHP и ни одной python.
У нас исторически отдел PHP во много раз больше отдела Python. Все будет, но не все сразу ;)
Всё ждал, когда же будет упомянут BitBucket? Тоже работает на Python и Django, и довольно популярен.
Reddit изначально был на webpy, позже, видимо, после смерти Арона Шварца команда решили пересесть на Pylons
Все переписывается рано или поздно. Тот же Twitter тоже переписывали с Ruby
Only those users with full accounts are able to leave comments. Log in, please.