Для широкой общественности доступен (http://wombat.org.ua/AByteOfPython) перевод на русский язык свободной книги "A Byte of Python" (http://swaroopch.com/notes/python/), которая может служить учебным пособием или руководством по программированию на языке Python для начинающей аудитории.
Перевод доступен в форматах HTML (http://wombat.org.ua/AByteOfPython) и PDF (http://wombat.org.ua/AByteOfPython/AByteofPythonRussian-2.0.pdf).Книга распространяется на условиях лицензии Creative Commons Attribution-Share Alike 3.0 Unported, позволяющей копировать, распространять и передавать материал другим, использовать фрагменты книги в своих текстах, в том числе в коммерческих целях. Все фрагменты программ/сценарии, представленные в книге, распространяются на условиях Модифицированной лицензии BSD4, если явно не указано обратное. При распространении книги во введении или на титульной странице должно быть указано первичное авторство в форме ссылки на страницу http://www.swaroopch.com/notes/Python с ясным
указанием на то, что исходный текст книги может быть найден по этому адресу. При продаже электронных или печатных версии книги в описании
должно быть явно указано, что книга распространяется не от имени её первоначального автора.URL: http://wombat.org.ua/AByteOfPython
Новость: http://www.opennet.me/opennews/art.shtml?num=37719
Python это единственный язык, который по максимуму использует все бонусы скриптовых языков, например отсутствие скобок, точек входа в программу, автоматические переменные, короткие выражения, малое число строк кода. Правда нужно отметить что в Python 3.X было обнаружено отступление от этих позиций.
>Python это единственный язык, который по максимуму использует все бонусы скриптовых языковТак уж и единственный. Можно вспомнить тот же Perl.
конечно, нужно было уточнять. "... во благо, или с профитом для разработчика". в перле же всё наоборот.
> разработчика".Вы сделали несколько ошибок в слове "быдлoкодер".
>>Python это единственный язык, который по максимуму использует все бонусы скриптовых языков
> Так уж и единственный. Можно вспомнить тот же Perl.Perl — это тот язык, который одинаково выглядит как до, так и после RSA шифрования.
Keith Bostic
Ну, для кого-то и арабская вязь - детские каракули. Если не умеешь её читать, то для тебя и то и другое будет не различимо.
Кроме print(), в чем еще было обнаружено отступление?
Кстати в Ruby, можно даже для функций не писать скобки, если смысл остаётся однозначным. Я как-то раз, увлёкшись, попробовал. Это ад! Я в итоге сам перестал понимать собственный код - всё в каше, ничего не понятно.
> Кстати в Ruby, можно даже для функций не писать скобки, если смысл
> остаётся однозначным. Я как-то раз, увлёкшись, попробовал. Это ад! Я в
> итоге сам перестал понимать собственный код - всё в каше, ничего
> не понятно.В Perl тоже можно не писать скобки, если у подпрограммы есть прототип. Если не знаеешь, сколько параметров принимает функция, то программу прочитать невозможно. Поэтому лучше их всё же ставить. Считается допустимым не ставить скобки только у встроенных подпрограмм.
отсутствие скобок????!!!!(5+2)*(3+7) = 70
5+2*3+7 = 18---
if ( a == b )
calc()
if (a ! = b )
not_calc()
При не правильном расположении пробэлов и случае a != b, not_calc() никогда не выполнится!
Нахер такой йзык!!!
> отсутствие скобок????!!!!
> (5+2)*(3+7) = 70
> 5+2*3+7 = 18Да, пусть на обратную польскую переходят, чо. Ещё есть брейнфак, немало поисследовавший тему значащего использования пробелов.
> Ещё есть брейнфак, немало поисследовавший
> тему значащего использования пробелов.только malbolge, только хардкор!
> При не правильном расположении пробэлов и случае a != b, not_calc() никогда не выполнится! Нахер такой йзык!!!А про какой язык вы говорите? В вашем примере явно не питон.
> if ( a == b )
> calc()
> if (a ! = b )
> not_calc()
>отсутствие скобок????!!!!Да.
if a == b: calc()
else: not_calc()
> Да.
> if a == b: calc()
> else: not_calc()calc() if be or not to_be else not_calc()
>calc() if be or not to_be else not_calc()Шекспир?
>>calc() if be or not to_be else not_calc()
> Шекспир?И тернарный оператор.
Капча: 45454
> if ( a == b )
> calc()
> if (a
> ! = b )
>
> not_calc()
> При не правильном расположении пробэлов и случае a != b, not_calc() никогда
> не выполнится!
> Нахер такой йзык!!!Удивительное дело - форматирование оступами вообще никак не мешает (а тольк помогает) тем, кто использует python, но ПОЧЕМУ-ТО очень мешает тем, кто его не использует...
Под этим эпиграфом мы начнём сеанс понимания python для малышей.
Во-первых, этот код не верен, и дело даже не в ":":
if a == b:
calc()
if a ! = b:
not_calc()не будет работать в принципе. и возможно только два варианта:
if a == b:
calc()
if a ! = b:
not_calc()if a == b:
calc()
if a ! = b:
not_calc()Всё, других вариантов нет. не имеет значения, сколько там табов-пробелов, важно только одно - стоят они на одной линии или нет. Если стоят - значит блок продолжается, если не стоят - значит блок закончился. Всё. И заметить, стоят ли они на одной линии или нет, смогут даже малыши... да и вообще все, кроме совсем слепых, совсем глупых или пыхеров...
> Всё, других вариантов нет.Ну всё, теперь горе-копипастеры статей про питон даже бровью не поведут, когда нечаяно похерят отступы.
>не имеет значения, сколько там табов-пробелов, важно только
> одно - стоят они на одной линии или нет.PEP с вами не согласен.
> Если стоят
> - значит блок продолжается, если не стоят - значит блок закончился.
> Всё. И заметить, стоят ли они на одной линии или
> нет, смогут даже малыши...Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.
Пример:
if a == b:
...
if b == c:
...
try:
...
except:
...
else:
if c == 4:
...
...
if d <> 8:
...
elif d <> c:
...
if not d:
...
# И тут неожиданность
...Когда начало уехало далеко-далеко вверх, тут так сразу и не поймёшь, какой там блок закончился: искомый или какой-то другой? Пробелы считать, делить на четыре? А вдруг писал какой-то оригинал вроде вас, который про PEP не слышал и пишет вперемешку - где таб, где два пробела, где три.
Это, конечно, плохой пример, хорошие программисты такие глубоко вложенные блоки стараются выделить в отдельную подпрограмму. Но в случае со скобочками и при использовании хорошего стиля, когда закрывающая скобочка стоит на одной линии с открывающей скобочкой (или if), сориентироваться гораздо проще, потому что воображаемую линию можно построить не только сверху, но и снизу - от закрывающей скобки.
>да и вообще все, кроме совсем слепых,
> совсем глупых или пыхеров...Людям свойственно ошибаться. Не ошибаются только исправные автоматы. Поэтому даже не слепой и не глупый человек запросто может допустить ошибку. Разумные меры защиты от ошибок помогают программисту. Чрезмерные - мешают, отсутствующие - по крайней мере не помогают.
В Python средств защиты от ошибок очень мало, он слишком гибкий. Это хорошо, когда на языке можно сделать что-то сложное, но плохо, когда эта гибкость настолько легко доступна, что ей можно воспользоваться нечаянно, по ошибке. Лучше было бы, если бы гибкость была, но она была бы изолированной, так чтобы воспользоваться ею можно было только осознанно. Поэтому мне больше нравится Perl.
>>не имеет значения, сколько там табов-пробелов, важно только
>> одно - стоят они на одной линии или нет.
> PEP с вами не согласен.Речь идёт не о PEP, речь идёт о восприятии человеком. Пробелы считать не нужно - достаточно видеть блоки. Разумеется, PEP-8 это благо, и только следование ему (хотя бы по большинству пунктов), делает человека человеком разумным. :)
Кстати, в данной книге я посмотрел начало: автор рекомендует использовать 4 пробела или tab. Я так и не понял, то ли он PEP-8 не читал, то ли осуждает.
> Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в
> конце блока есть несколько вложенных блоков - на взгляд так сразу
> не определишь, сколько там блоков закончилось."Если что-то не работает или не понятно - см. PEP-8". Это как Нагорную проповедь перечитывать - чем больше перечитываешь, тем большее открывается - потому что ситуации всегда разные...
> Когда начало уехало далеко-далеко вверх, тут так сразу и не поймёшь, какой
> там блок закончился: искомый или какой-то другой? Пробелы считать, делить на
> четыре? А вдруг писал какой-то оригинал вроде вас, который про PEPне pep, а pep-8, большинству пунктов которого я следую и использую 4 пробела.
> выделить в отдельную подпрограмму. Но в случае со скобочками и при
> использовании хорошего стиля, когда закрывающая скобочка стоит на одной линии с
> открывающей скобочкой (или if), сориентироваться гораздо проще, потому что воображаемую
> линию можно построить не только сверху, но и снизу - от
> закрывающей скобки.Так и строй линию от последней линии до первой. Я не понял вообще никакой разницы со скобочками, кроме того, что скобочка МОЖЕТ там стоять, а строка - ОБЯЗАНА там стоять, иначе парсер не будет работать. Таких проблем у меня не было НИКОГДА, и я даже не могу представить, как они могут возникнуть. Со скобочками есть одна проблема, но очень большая - они МЕШАЮТ.
>>да и вообще все, кроме совсем слепых,
>> совсем глупых или пыхеров...
> В Python средств защиты от ошибок очень мало, он слишком гибкий. Это
> хорошо, когда на языке можно сделать что-то сложное, но плохо, когда
> эта гибкость настолько легко доступна, что ей можно воспользоваться нечаянно, по ошибке.Такие ошибки практически маловероятны. У меня было больше инциндентов с установленной не там скобочкой, чем с неверным отступом. А вариантов всего три:
1. Если элемент с :, то +1 отступ, и никаких других вариантов (кроме краткой записи однострочника) быть не может.
2. Если элемент не с :, то остаёмся на той же строчке
3. Если элемент не с :, то блок закончен, и отступы уходят назад
все остальные варианты дадут ошибку парсера. поэтому в реальных (а не надуманных) задачах что-то испортить - минимум шансов.
> Речь идёт не о PEP, речь идёт о восприятии человеком. Пробелы считать
> не нужно - достаточно видеть блоки.Вот я о том и говорю - не видно конца блоков, когда несколько блоков заканчивается сразу. Приходится ориентироваться на отступ того, что идёт дальше, что не столь удобно.
А ещё есть одно неудобство, когда нужно временно закомментировать блок try, так чтобы его внутренности продолжали работать. Бывает нужно понять, какое там исключение возникает, но для этого каждый раз приходится отступы исправлять - не удобно. В Perl закомментировать eval и фигурные скобки, не меняя отступов, проще.
> Разумеется, PEP-8 это благо, и
> только следование ему (хотя бы по большинству пунктов), делает человека человеком
> разумным. :)
> "Если что-то не работает или не понятно - см. PEP-8". Это как
> Нагорную проповедь перечитывать - чем больше перечитываешь, тем большее открывается -
> потому что ситуации всегда разные...Ну, если вам так нравится читать, то читайте. Я - как чукча из анекдота, не читатель, а писатель. По мне, чем реже приходится прибегать к чтению и чем проще необходимую информацию уместить в голове, тем проще - программа быстрее пишется и отлаживается.
Синтаксис Perl очень разнообразен, поэтому легко запоминается и (не удивляйтесь, но это бывает) читается. Мне конструкция вида $a->{$b}->[$c] говорит о большем, чем a[ b][c]. Мне проще запомнить операторы m// и s/// и пользоваться переменными $1, $2 и т.п., нежели лезть в документацию по модулю re и выискивать там описания методов, которые позволяют делать ровно то же самое, для чего в Perl мне не приходится заглядывать в документацию.
Мне проще найти что-то годное на CPAN, чем в pypi, потому что на CPAN можно сразу читать документацию на модуль и она, как правило, будет написана для людей, а не для машин. В Perl есть общепризнанные годные модули для большинства нужд, которые, к тому же, давно устаканились: DBI (DBD::mysql, DBD::Pg, DBD::Sybase), Net::SNMP, Net::Ping, Net::DNS, Net::LDAP, HTML::Template (дубово, но я предпочитаю логику не размазывать по шаблонам), JSON и JSON::XS, XML::Simple, LWP, чего не скажешь о Python, где ни для пинга ни для SNMP ничего толкового не найдёшь, а все варианты подключения к MS SQL требуют огромных усилий для того, чтобы просто заставить их работать.
> не pep, а pep-8, большинству пунктов которого я следую и использую 4
> пробела.Не лампочка, а матовая лампочка.
>> выделить в отдельную подпрограмму. Но в случае со скобочками и при
>> использовании хорошего стиля, когда закрывающая скобочка стоит на одной линии с
>> открывающей скобочкой (или if), сориентироваться гораздо проще, потому что воображаемую
>> линию можно построить не только сверху, но и снизу - от
>> закрывающей скобки.
> Так и строй линию от последней линии до первой.От какой последней линии? Кончается сразу несколько блоков, а начала блоков не видно. Не понятно на глаз, какие блоки уже закончились, а какие - нет.
>>>да и вообще все, кроме совсем слепых,
>>> совсем глупых или пыхеров...
>> В Python средств защиты от ошибок очень мало, он слишком гибкий. Это
>> хорошо, когда на языке можно сделать что-то сложное, но плохо, когда
>> эта гибкость настолько легко доступна, что ей можно воспользоваться нечаянно, по ошибке.Насчёт гибкости у меня такая проблема - я хочу чтобы интерпретатор ловил опечатки в именах переменных. В Perl есть прагма strict и родственная ей fields - от таких нелепых ошибок спасает, просто не даёт запустить программу с такими ошибками. В Python если программа запустилась, то это ещё не значит, что в программе нет опечаток. Иногда так поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за опечатки. Куча времени теряется впустую.
> А ещё есть одно неудобство, когда нужно временно закомментировать блок try, так
> чтобы его внутренности продолжали работать. Бывает нужно понять, какое там исключение
> возникает, но для этого каждый раз приходится отступы исправлять - не удобно.Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.
> Ну, если вам так нравится читать, то читайте. Я - как чукча
> из анекдота, не читатель, а писатель. По мне, чем реже приходится
> прибегать к чтению и чем проще необходимую информацию уместить в голове,
> тем проще - программа быстрее пишется и отлаживается.PEP8 - это КРАЙНЕ РЕКОМЕНДУЕМЫЙ СТАНДАРТ. И, встретя код другого "живущего по pep8 и pep20", я его легко пойму. Более того, на более-менее простой задаче два "живущих по pep8 и pep20" решат её абсолютно одинаково. :)
Наличие стандарта - это большой плюс. А позиция "я тут самый умный, и мне наплевать, кто там что будет читать, моё дело - писать" - очень усложняет поддержку.
> От какой последней линии? Кончается сразу несколько блоков, а начала блоков не
> видно. Не понятно на глаз, какие блоки уже закончились, а какие - нет.- Люся, я на кладбище
- Кто-то умер?
- Ты не поверишь, ТУТ ВСЕ УМЕРЛИ!
То ли у нас разные русские языки, то ли разные восприятия. Если ничего снизу не торчит, то все блоки закончились. И это нормально, это самая популярная практика, просто пишешь сверху вниз, а потом не нужно задумываться о том, что где закрывать. Если такой условный пример разбавить скобочками, то сразу возрастёт сложность - их нужно будет где-то закрывать, либо }}}}, либо четыре строчки в ряд, либо "превращать perl в python, но со скобочками", ставя их ровно на линии, и получая ровно те же самые блоки, но с ни-к-селу-ни-к-городу скобочками.
> Насчёт гибкости у меня такая проблема - я хочу чтобы интерпретатор ловил
> опечатки в именах переменных. В Perl есть прагма strict и родственная
> ей fields - от таких нелепых ошибок спасает, просто не даёт
> запустить программу с такими ошибками. В Python если программа запустилась, то
> это ещё не значит, что в программе нет опечаток. Иногда так
> поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за
> опечатки. Куча времени теряется впустую.dict, locals, globals. Всё есть словарь, и каждый словарь можно контролировать, если очень хочется. И, опять же, какие-то странные позывы - добавил кода, но не проверил, а через полчаса оно вывалилось? А если оно вывалилось не из-за опечатки, а из-за кривого алгоритма или лексически грамотной, но технически ошибочной конструкции? Такие вещи встречаются намного чаще - как можно не проверять то, что написал?
Короче говоря, python - это для разработчиков, которые хотят сделать код, который был бы понятным другим разработчикам, чтобы развивать его вместе и придумывать новое на его основе. А perl - для программистов (не знаю, для кого как, а для меня это слово ругательное, и лично я могу за него и в дыню дать), которые написали и свалили, и ничего их не колышет, работает - и ладно, а прочие тонкости и прочие люди уже никак не волнуют. Лично я КАЖДУЮ строчку проверяю на предмет того, "а понятно будет ли это пыхеру, которого я на улице отловлю за руку, и посажу это читать?". Могу использовать и менее эффективные и более громоздкие конструкции только для того, чтобы они были понятнее, чтобы с этим можно было реально работать, менять и дополнять (даже тем людям, которые в python понимают слабо), чтобы у написанного была дальнейшая жизнь.
И в мире, где opensource стало царицей полей - это очень важно. Поддерживаемость - это основной козырь ранее написанного кода, чтобы не пришлось его переизобретать. Именно на этом основывается преимущество opensource.
>Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.А по существу-то есть что сказать?
Есть блок:
try:
...
except a as e:
...
except b as e:
...
except:
...
else:
...Когда в третий except попадает какое-то непонятное исключение, не a и не b и нужно понять, что это такое, как быть?
>Наличие стандарта - это большой плюс. А позиция "я тут самый умный, и мне наплевать, кто там что будет читать, моё дело - писать" - очень усложняет поддержку.
Это была самоирония (вы не заметили упоминание анекдота про чукчу?).
А вообще - есть такое практическое правило, что люди не могут выполнять инструкции больше четырёх страниц. Они стараются уяснить смысл и делают так, как поняли, а не по пунктам инструкции. Поэтому чем меньше инструкция - тем больше от неё толку. От больших же инструкций пользы будет не больше, чем от маленьких.
>И это нормально, это самая популярная практика, просто пишешь сверху вниз, а потом не нужно задумываться о том, что где закрывать.
Это хорошо, когда можно писать-писать, а потом бросить. Автоматическую сборку мусора тоже не дураки придумали. Проблема бывает, когда нужно ПРОДОЛЖИТЬ блок - не удобно ориентироваться, сколько там отступов нужно вправо сделать. Закрывающие фигурные скобки в этом случае помогают.
Вообще, не стоит уделять столько внимания такому не принципиальному вопросу как использование отступов и использование скобочек для группировки кода. Это не принципиальный вопрос, это просто наблюдение, почему людям не нравятся отступы. Всего лишь не нравятся.
>dict, locals, globals. Всё есть словарь, и каждый словарь можно контролировать, если очень хочется.
Можно. Но опять-таки - в процессе работы программы, а не перед её запуском, как в Perl. И в Perl это почти ничего не стОит.
>И, опять же, какие-то странные позывы - добавил кода, но не проверил, а через полчаса оно вывалилось? А если оно вывалилось не из-за опечатки, а из-за кривого алгоритма или лексически грамотной, но технически ошибочной конструкции? Такие вещи встречаются намного чаще - как можно не проверять то, что написал?
Проблема в том, что именно на это и должны уходить умственные усилия, а не на борьбу с опечатками. У мозга ресурс ограниченный (правило 7+-2 и всё такое). Когда нужно думать ещё и об опечатках, меньше внимания достаётся алгоритму. Поэтому лучше, когда опечатки контролируются компилятором-интерпретатором на автомате. Не хочу я возлагать на себя тупую работу, с которой в состоянии справиться компьютер.
>>Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.
> А по существу-то есть что сказать?Нет. Я так и не увидел этого мифического существа.
> А вообще - есть такое практическое правило, что люди не могут выполнять
> инструкции больше четырёх страниц. Они стараются уяснить смысл и делают так,
> как поняли, а не по пунктам инструкции. Поэтому чем меньше инструкция
> - тем больше от неё толку. От больших же инструкций пользы
> будет не больше, чем от маленьких.Да какая разница? Какая разница, когда люди дойдут до стандарта - своим умом, или когда я их в коридоре палкой изобью? Главное - что он есть, и что многие его соблюдают, и что те, кто его не соблюдают по всем показателям, становятся белыми воронами.
Как минимум, 4 пробела - это обязательное условие. Для всех, независимо от сусликов.
> не дураки придумали. Проблема бывает, когда нужно ПРОДОЛЖИТЬ блок - не
> удобно ориентироваться, сколько там отступов нужно вправо сделать. Закрывающие фигурные
> скобки в этом случае помогают.НИХРЕНА они не помогают. Найти визуально отступ (даже geany может чёрточку вниз рисовать, или можно линейку к экрану привести), ГОРАЗДО ПРОЩЕ, ЧЕМ В:
if (a) {
if (b) {
if (c) {
.....
}
...
}
...
}найти, кто кого харлал.
Ну а если писать:
if (a) {
if (b) {
if (c) {то тогда логичный вопрос - а нахрена это дублировать ещё и скобочками?
"Ты в зоопарке быль? Там питон видель?" Или это только вымышленные проблемы, не проверенные практикой?
> Проблема в том, что именно на это и должны уходить умственные усилия,
> а не на борьбу с опечатками. У мозга ресурс ограниченный (правило
> 7+-2 и всё такое). Когда нужно думать ещё и об опечатках,
> меньше внимания достаётся алгоритму. Поэтому лучше, когда опечатки контролируются компилятором-интерпретатором
> на автомате. Не хочу я возлагать на себя тупую работу, с
> которой в состоянии справиться компьютер.Когда у тебя в итоговом коде получается гораздо меньше строк, гораздо меньше конструкций и гораздо меньше лишних символов, отвлекающих внимание, МОЗГУ ДУМАЕТСЯ НАМНОГО ПРОЩЕ:
Возьмём примеры:
def factorial(x):
if x == 0:
return 1
else:
return x * factorial(x - 1)
sub factorial {
my $n = shift;
if ($n==0) {
return 1;
} else {
return $n*factorial($n-1);
}
}
и посчитаем конструкции, которые нужны компьютеру, но не человеку, все эти ;, $, (, {Вот на что внимание расходуется больше.
>[оверквотинг удален]
> if (a) {
> if (b) {
> if (c) {
> .....
> }
> ...
> }
> ...
> }
> найти, кто кого харлал.Тоже мне, проблема. Найти какой-нибудь форматтер исходников, потом работать как обычно. Без всяких geany, хоть в "Блокноте". Кстати, как писать программы на Python'е не в редакторе, а на неразлинованной бумажке? :)
> Ну а если писать:
> if (a) {
> if (b) {
> if (c) {
> то тогда логичный вопрос - а нахрена это дублировать ещё и скобочками?
> "Ты в зоопарке быль? Там питон видель?" Или это только вымышленные проблемы,
> не проверенные практикой?Я пишу и на Perl и на Python, поэтому у меня есть что и с чем сравнивать.
>[оверквотинг удален]
> my $n = shift;
> if ($n==0) {
> return 1;
> } else {
> return $n*factorial($n-1);
> }
> }
> и посчитаем конструкции, которые нужны компьютеру, но не человеку, все эти ;,
> $, (, {
> Вот на что внимание расходуется больше.Пример надуман.
sub factorial {
my $n = shift;
return 1 unless $n;
return $n * factorial($n - 1);
}Настоящие эстеты могут вообще всё упаковать тернарным оператором.
Иногда простота - хуже воровства. Когда я вижу $a->{$b}->[$c], я понимаю больше, чем когда вижу a[ b][c]. Когда я вижу $a eq $b я понимаю больше, чем a == b. Когда я вижу:
if ($s =~ m/^0x([[:hexdigit:]]+)$/)
{
$a = hex($1);
}Я понимаю больше и пишу это быстрее, чем в Python с его библиотекой re. Даже пример писать не хочется, потому что придётся сейчас в документацию лезть.
> А perl - для программистов (не знаю,
> для кого как, а для меня это слово ругательное, и лично
> я могу за него и в дыню дать),Это ваши личные комплексы. Хотя я тоже предпочитаю называться инженером.
> которые написали и
> свалили, и ничего их не колышет, работает - и ладно, а
> прочие тонкости и прочие люди уже никак не волнуют. Лично я
> КАЖДУЮ строчку проверяю на предмет того, "а понятно будет ли это
> пыхеру, которого я на улице отловлю за руку, и посажу это
> читать?".Действительно. Работает - и ладно. Хуже было бы, если бы не работало. Конечно, срач кому-то оставлять не нужно, ведь и тебе тоже может остаться чей-то срач. Но, какое это имеет отношение к теме?
А, кажется понимаю. Это, значит, когда нужно будет обновить ОС в системе или задеплоить проект в другое окружение, когда Python 2.7 уже будет не канать, нужно будет всё адаптировать на Python 3.x, соображая как обойтись без модулей, которые на Python 3.x так и не перевели. То ли дело Perl - программы, написанные в девяностых годах под CGI до сих пор работают и внимания не требуют. Python - отличный выбор для тех, кто хочет поднасрать своим преемникам.
> И в мире, где opensource стало царицей полей - это очень важно.
> Поддерживаемость - это основной козырь ранее написанного кода, чтобы не пришлось
> его переизобретать. Именно на этом основывается преимущество opensource.Идеологическая промывка засчитана. Любому сотруднику, которому предстоит дорабатывать программу, дают доступ к исходникам. Срач в исходниках недопустим в любом случае, будь то опенсорс или проприетарщина.
Поддерживаемость у проприетарных продуктов кагбэ значительно выше, проприетарщики деньги зарабатывают, ценят свою репутацию, а потому не могут кинуть клиента. В мире свободного софта люди приходят и уходят, работая за интерес, в большинстве случаев. Стало не интересно поддерживать - взял и ушёл. Или взял, и придумал ради оживления интереса сделать всё глобальнее и надёжнее, положив болт на поддержку того, что уже было. Примеров тыщи - HAL, Gnome 3, KDE 4. Тот же Python 3.x, кстати (и вообще, слишком часто там выходят новые версии, не совместимые со старыми).
Почитайте вот: http://translatedby.com/you/the-problems-of-open-source/into-ru/
>> И в мире, где opensource стало царицей полей - это очень важно.
>> Поддерживаемость - это основной козырь ранее написанного кода, чтобы не пришлось
>> его переизобретать. Именно на этом основывается преимущество opensource.
> Идеологическая промывка засчитана. Любому сотруднику, которому предстоит дорабатывать
> программу, дают доступ к исходникам. Срач в исходниках недопустим в любом
> случае, будь то опенсорс или проприетарщина.
> Поддерживаемость у проприетарных продуктов кагбэ значительно выше, проприетарщики деньги
> зарабатывают, ценят свою репутацию, а потому не могут кинуть клиента."Идеологическая промывка засчитана".
> "Идеологическая промывка засчитана".А вы почитайте, почитайте. Наиболее сложные и хорошие программы, _как_правило_ (не всегда, конечно), начинались как коммерческие проекты. По стечению обстоятельств их просто подарили радетелям за свободу.
> Наиболее сложные и хорошие программы, _как_правило_ (не всегда, конечно), начинались как коммерческие проекты.Кхм... Linux,Nginx и даже ваш любимый Perl. Из обратного могу только вспомнить Blender.
>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера допустим, зачем приводить спагетти код как аргумент.
>>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.
> Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера
> допустим, зачем приводить спагетти код как аргумент.Затем, что это лишь иллюстрация. Книжка по рефакторингу этот неудачный момент Python'а не исправит, потому что речь о свойствах языка, а не о свойствах программы, которая на нём написана.
>>>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.
>> Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера
>> допустим, зачем приводить спагетти код как аргумент.
> Затем, что это лишь иллюстрация.Иллюстрация чего?
>Книжка по рефакторингу этот неудачный момент Python'а
> не исправит, потому что речь о свойствах языка, а не о
> свойствах программы, которая на нём написана.Ну хватит чушь нести.
>[оверквотинг удален]
>
> if d <> 8:
>
> ...
>
> elif d <> c:
>
> ...
>
> if not d:Отличный пример. Просто прекрасный. Его можно превратить в неприятную задачу, после которой код будет выглядеть намного ужаснее, всего лишь просьбой "а теперь расставь скобочки!"
В том то и дело, что в python нужно следить только за текущим и предыдущим уровнём. Всё. Потом просто бросаешь код, не нужно думать, где его закрывать.
Даже если в python не было бы тех супервозможностей, которые у него есть, и которые реально облегчают и написание и прочтение - одно только форматирование уже было бы достоинством, позволяющим предпочесть этот язык. Хотя, конечно, у того же ruby есть много приятностей, которых в python нет.
> Хотя,
> конечно, у того же ruby есть много приятностей, которых в python
> нет.например?
>> Хотя,
>> конечно, у того же ruby есть много приятностей, которых в python нет.
> например?Я так сразу и не вспомню, потому что это возникает в процессе использования, а так просто я такие вещи в памяти не храню. :)
Ну, например, .flatten
Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн (ладно бы, у list-ов было бы .get, так и его почему-то нет).
Вставки удобнее и нагляднее, чем .format / %
Не помню, но помню, что их там немало.
>Ну, например, .flattenЭто который к array? В numpy круче.
>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн
Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.
> (ладно бы, у list-ов было бы .get, так и его почему-то нет).
Есть .pop и срезы.
>>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн
> Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.Я не говорил про None. Был бы какой-нибудь ListNone...
>> (ладно бы, у list-ов было бы .get, так и его почему-то нет).
> Есть .popЭто всё не очень удобно.
> и срезы.
Ты гений! Реально работает, вовзращает то, что нужно!
>>>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн
>> Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.
> Я не говорил про None. Был бы какой-нибудь ListNone...Вводить новый тип, зачем, except IndexError: someaction вполне рулит.
>>> (ладно бы, у list-ов было бы .get, так и его почему-то нет).
>> Есть .pop
> Это всё не очень удобно.
>> и срезы.
> Ты гений! Реально работает, вовзращает то, что нужно!Я не гений, это азы.
>> Я не говорил про None. Был бы какой-нибудь ListNone...
> Вводить новый тип, зачем, except IndexError: someaction вполне рулит.Однострочники - это удобно, его можно запульнуть в значение-параметр, его можно легко впихнуть в шаблон, сделав маленькое удобство, которое сделает проект ещё удобнее. Если такие удобства делать большими вставками, то и тратится лишнее время, и добавляется лишний код, который будет под ногами путаться... а однострочник всунул, и порядок, висит в углу, считает калории или ещё что-нибудь, и никак не мешает.
>>> Я не говорил про None. Был бы какой-нибудь ListNone...
>> Вводить новый тип, зачем, except IndexError: someaction вполне рулит.
> Однострочники - это удобно, его можно запульнуть в значение-параметр, его можно легко
> впихнуть в шаблон, сделав маленькое удобство, которое сделает проект ещё удобнее.
> Если такие удобства делать большими вставками, то и тратится лишнее время,
> и добавляется лишний код, который будет под ногами путаться... а однострочник
> всунул, и порядок, висит в углу, считает калории или ещё что-нибудь,
> и никак не мешает.Давайте я вам озвучу вашу проблему. Вы путаете типы ruby и python. Тип array в ruby и list в python означают совсем разные сущности. В python даже в стандартной библиотеки перечисляемых типов ну просто завались, похоже вы выбрали не тот тип. Вам нужно было выбрать словарь, возможно посмотреть на кучу(heapq), bisect или типы из collection.
> Давайте я вам озвучу вашу проблему. Вы путаете типы ruby и python.
> Тип array в ruby и list в python означают совсем разные
> сущности. В python даже в стандартной библиотеки перечисляемых типов ну просто
> завались, похоже вы выбрали не тот тип. Вам нужно было выбрать
> словарь, возможно посмотреть на кучу(heapq), bisect или типы из collection.Во-первых, в json есть только list-ы и dict-ы, и даже если вешать хук, то тип должен приводиться к list. А у меня почти все данные - родом из json.
Во-вторых, в list есть срезы.
В-третьих, можно, конечно, вместо dict-ов в list-ах использовать dict-ы в dict-ах, но лично для меня list-ы выглядят эстетичнее. Для меня удобство и приятность поглощения моим восприятием - это самое главное, что-то неприятное или сложное я просто не буду воспринимать. Изначально я именно dict в dict и использовал, какие-то неприятные ощущения остались. К тому же, в json ключи строковые, даже если в словаре они int. Может быть, есть хук, чтобы это при лодинге исправлять?
>[оверквотинг удален]
> хук, то тип должен приводиться к list. А у меня почти
> все данные - родом из json.
> Во-вторых, в list есть срезы.
> В-третьих, можно, конечно, вместо dict-ов в list-ах использовать dict-ы в dict-ах, но
> лично для меня list-ы выглядят эстетичнее. Для меня удобство и приятность
> поглощения моим восприятием - это самое главное, что-то неприятное или сложное
> я просто не буду воспринимать. Изначально я именно dict в dict
> и использовал, какие-то неприятные ощущения остались. К тому же, в json
> ключи строковые, даже если в словаре они int. Может быть, есть
> хук, чтобы это при лодинге исправлять?Увы и ах, без приведения кода ничем не могу вам помочь, если хотите напишите сюда python.su поможем решить вашу проблему.
> Увы и ах, без приведения кода ничем не могу вам помочь, если
> хотите напишите сюда python.su поможем решить вашу проблему.на python.su я пишу, и помогают :) а проблемы, как таковой нет, если не считать небольшой зависти к рубистам :)
>> Увы и ах, без приведения кода ничем не могу вам помочь, если
>> хотите напишите сюда python.su поможем решить вашу проблему.
> на python.su я пишу, и помогают :) а проблемы, как таковой нет,
> если не считать небольшой зависти к рубистам :)Так сформулируйте что хотите, и вдруг окажется, что все гораздо лучше.
>[оверквотинг удален]
>> ...
>>
>> elif d <> c:
>>
>> ...
>>
>> if not d:
> Отличный пример. Просто прекрасный. Его можно превратить в неприятную задачу, после которой
> код будет выглядеть намного ужаснее, всего лишь просьбой "а теперь расставь
> скобочки!"Эта проблема, как раз, возникает только у питонистов, когда они копипастят свои программы. В других языках эта конструкция изначально будет написана со скобочками. В Perl, кстати, даже для одного оператора в блоке if нужно ставить фигурные скобки. Не запутаешься, в отличие от.
> Эта проблема, как раз, возникает только у питонистов, когда они копипастят свои
> программы. В других языках эта конструкция изначально будет написана со скобочками.
> В Perl, кстати, даже для одного оператора в блоке if нужно
> ставить фигурные скобки. Не запутаешься, в отличие от.Опять придумали проблему, которая как раз у питонистов НЕ возникает, но возникает у тех, кто им не пользуется, или кто им пользуется, как перлом, не понимая, что такое pythonic.
Я даже больше скажу - если у меня в программе удалить все отступы, я их на глаз восстановлю минут за 5. Ибо сказано "Явное лучше неявного". Боязливых же и неверных участь одна... :)
> Я даже больше скажу - если у меня в программе удалить все
> отступы, я их на глаз восстановлю минут за 5. Ибо сказано
> "Явное лучше неявного". Боязливых же и неверных участь одна... :)В своей программе и я могу без фигурных скобочек и без отступов сориентироваться :) Вы в чужой сориентируйтесь.
> В Python средств защиты от ошибок очень мало, он слишком гибкий.Это... как бы начиная от строгой типизации, кончая doctest,unittest из коробки.
>Поэтому мне больше нравится Perl.
Хм... это где слабая типизация? И ключики между разными версиями могут запросто различаться?
>> В Python средств защиты от ошибок очень мало, он слишком гибкий.
> Это... как бы начиная от строгой типизации, кончая doctest,unittest из коробки.В Perl типизация менее строгая, но зато более статическая (если использовать strict, что считается общепринятым). Объявил массив - обращаться как с хэшем ты с ним не сможешь, а предупреждение об этом будет выдано ещё ДО запуска программы. Не объявил переменную или опечатался в её имени - узнаешь об этом ещё ДО запуска программы. Экономит время.
И слабая типизация в Perl не ощущается как недостаток, потому что во многих случаях трудно толковать какую-то операцию двояко: в Python a + b может означать как сложение чисел, так и конкатенацию строк, в Perl такой проблемы нет, потому что есть отдельные операции - $a + $b и отдельная - $a . $b. Ну и соответствующие операции сравнения: $a == $b и $a eq $b. Не нужно держать в голове контекст, в какой из переменных сейчас строка с числом, а где - просто число и не нужно соображать, какую из переменных приводить к нужному типу. Просто пишешь: сравни их как строки, и любая комбинация строк с числами и собственно чисел приведётся к нужному типу. Особенно удобно, когда регулярными выражениями выделяешь число - в Python я часто забывая привести число к строковому типу перед сравнением или вычислением и получаю ошибку уже в процессе работы программ, когда она отработает значительное время. Лишние потери времени, больше нужно держать в голове - не удобно.
Спрашивается - зачем мне эти модули для тестирования, когда в случаях с опечатками в именах переменных можно вообще без них обойтись? Зачем мне эта строгая типизация, если она заставляет меня держать в голове больше контекста?
>>Поэтому мне больше нравится Perl.
> Хм... это где слабая типизация? И ключики между разными версиями могут запросто
> различаться?Не знаю, о каких ключиках речь.
> Не нужно держать в голове контекст, в какой из переменных сейчас строка с
> числом, а где - просто число и не нужно соображать, какую
> из переменных приводить к нужному типу. Просто пишешь"Скажи мне, на каком языке ты пишешь, и я скажу, какая каша у тебя в голове"
Приплыли. ЗАЧЕМ сравнивать две переменных, если ты даже не знаешь, ЧТО В НИХ, и не прослеживаешь контекст? Как это вообще объяснить? Типа, встал утром спозаранку, почесал яйцо, и подумал "а почему бы не сравнить a с b"?
> Зачем мне эта строгая типизация
Она дисциплинирует. Как и оступы. Потому что в этом случае писать НЕПРАВИЛЬНО становится больно. Лучше потратить больше времени на проектирования, но написать 4 хороших строчки, чем не думая написать 50, а потом за это всю жизнь расплачиваться.
> Приплыли. ЗАЧЕМ сравнивать две переменных, если ты даже не знаешь, ЧТО В
> НИХ, и не прослеживаешь контекст?Я знаю, что я регуляркой выделил из строки число. Я знаю, что там число. Не понимаю, зачем мне ещё и приводить этот текст с числом к типу "число", если я это и так знаю?
> Как это вообще объяснить? Типа, встал
> утром спозаранку, почесал яйцо, и подумал "а почему бы не сравнить
> a с b"?Дурак вы, батенька.
>> Зачем мне эта строгая типизация
> Она дисциплинирует. Как и оступы. Потому что в этом случае писать НЕПРАВИЛЬНО
> становится больно.Ну так бы сразу и сказали, что вы - мазохист. Я люблю писать, потому что мне это приятно. И люблю писать правильно, но не люблю, когда ко мне мой же инструмент придирается по пустякам, да ещё и с опозданием, не перед запуском программы, а в процессе работы. Ленивый язык, работает на отъебись, а не для того, чтобы помочь программисту.
> Лучше потратить больше времени на проектирования, но написать 4
> хороших строчки, чем не думая написать 50, а потом за это
> всю жизнь расплачиваться.Надо прожить жизнь так, чтобы потом не было мучительно больно за бесцельно прожитые годы. Нужно не строчки написать, а задачу решить. Какой толк от красивых строчек, которые не решают задачи?
> Ну так бы сразу и сказали, что вы - мазохист. Я люблю
> писать, потому что мне это приятно. И люблю писать правильно, но
> не люблю, когда ко мне мой же инструмент придирается по пустякам,
> да ещё и с опозданием, не перед запуском программы, а в
> процессе работы. Ленивый язык, работает на отъебись, а не для того,
> чтобы помочь программисту.Бред, далёкий от реальности. На python писать легко и просто, мешает там намного больше вещей, чем в perl. Если взять обычного человека, далёкого от кодирования, и попросить его решить задачу, то в perl он даже до 'hello, world' не дойдёт.
>> Лучше потратить больше времени на проектирования, но написать 4
>> хороших строчки, чем не думая написать 50, а потом за это
>> всю жизнь расплачиваться.
> Надо прожить жизнь так, чтобы потом не было мучительно больно за бесцельно
> прожитые годы. Нужно не строчки написать, а задачу решить. Какой толк
> от красивых строчек, которые не решают задачи?Не-не-не. Вы именно кодер, который пишет код ради кода, а не для решения задач. Для разработчика идеальное число строк, которое должно быть написано - 0. Если совсем надо, то 4. И по логу коммитов этих строчек всё всем становится понятно, если оно спроектировано грамотно. И они решают реальные задачи, а не задачи кодеров по кодированию.
Это у пыхеров так заведено - писать-писать-писать, потом оглянуться, переписать всё с нуля (потому что полученный монстр вышел из-под контроля), и так далее во много итераций. Кода много, смысла мало, задачи решаются в лоб, и потом становятся фанерными (не влезай, убьёт). Кто-то перерастает это, и начинает писать на языках, которые больше этому способствуют. Чаще всего - python или ruby. Но никак не perl.
> Бред, далёкий от реальности. На python писать легко и просто, мешает там
> намного больше вещей, чем в perl. Если взять обычного человека, далёкого
> от кодирования, и попросить его решить задачу, то в perl он
> даже до 'hello, world' не дойдёт.Ну да, язык для обучения типа Basic или Pascal. Можно ещё язык ДРАКОН вспомнить - вообще отличный пример.
>> Надо прожить жизнь так, чтобы потом не было мучительно больно за бесцельно
>> прожитые годы. Нужно не строчки написать, а задачу решить. Какой толк
>> от красивых строчек, которые не решают задачи?
> Не-не-не. Вы именно кодер, который пишет код ради кода, а не для
> решения задач.Я системный администратор и задачи я решаю вполне реальные, в отличие от выдуманных задач всяких веб-разработчиков, которым не нужны библиотеки для работы с SMTP, ICMP, SNMP, LDAP, HTTP, DNS, базами данных, а достаточно одного веб-фреймворка. На Python для всего этого добра годные библиотеки ещё поискать нужно.
> Для разработчика идеальное число строк, которое должно быть написано
> - 0. Если совсем надо, то 4. И по логу коммитов
> этих строчек всё всем становится понятно, если оно спроектировано грамотно. И
> они решают реальные задачи, а не задачи кодеров по кодированию.Если я после прочтения документации решу, что существующий продукт решает мои задачи без написания кода, то количество написанных мной строк кода - 0. И по логу коммитов ты об этом даже не узнаешь. Это только у парней с "грамотным проектированием", которые "решают реальные задачи" вся деятельность видна по коммитам в системе контроля версий. Это и есть самые что ни на есть "задачи кодеров по кодированию", а не реальная деятельность.
> Это у пыхеров так заведено - писать-писать-писать, потом оглянуться, переписать всё с
> нуля (потому что полученный монстр вышел из-под контроля), и так далее
> во много итераций. Кода много, смысла мало, задачи решаются в лоб,
> и потом становятся фанерными (не влезай, убьёт). Кто-то перерастает это, и
> начинает писать на языках, которые больше этому способствуют. Чаще всего -
> python или ruby. Но никак не perl.Да-да, то-то я смотрю Spamassassin, Amavis, debmirror, apt-cacher, Awstats, lightsquid, logwatch, MRTG, Munin, mysqltuner, Nagios, pflogsum, phpMyAdmin, Cacti, PostfixAdmin написаны на Python и Ruby. Из полезного на последних могу назвать лишь ExFalso, утилиты для управления Xen и Redmine. И ещё вспомнились mercurial, trac, yum.
>[оверквотинг удален]
> когда она отработает значительное время. Лишние потери времени, больше нужно держать
> в голове - не удобно.
> Спрашивается - зачем мне эти модули для тестирования, когда в случаях с
> опечатками в именах переменных можно вообще без них обойтись? Зачем мне
> эта строгая типизация, если она заставляет меня держать в голове больше
> контекста?
>>>Поэтому мне больше нравится Perl.
>> Хм... это где слабая типизация? И ключики между разными версиями могут запросто
>> различаться?
> Не знаю, о каких ключиках речь.Господи... какая чушь.
> Господи... какая чушь.Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять? Ведь всем известно, что Perl - мёртв, а Python - это ум, честь и совесть всех настоящих программистов. Ничего другого изучать не нужно. Если ты знаешь Python - ты крут и можешь глядеть на всех свысока. Все другие - просто дураки, раз до сих пор не поняли, насколько идеален Python.
>> Господи... какая чушь.
> Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять? Ведь всем
> известно, что Perl - мёртв, а Python - это ум, честь
> и совесть всех настоящих программистов. Ничего другого изучать не нужно. Если
> ты знаешь Python - ты крут и можешь глядеть на всех
> свысока. Все другие - просто дураки, раз до сих пор не
> поняли, насколько идеален Python.Python идеален не поэтому. И perl плох тоже не поэтому. :)
Python силён своей идеологией, которая проста и понятна людям. Python ближе к народу. Когда мне предлагают 5 синтаксисов одного и того же, когда у меня со строками одни функции, со списками - другие, а с генераторами - третьи, я хватаюсь за Python.
>Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять?Информации в вашем тексте Null, переливание из пустого в порожнее, затем опа откуда-то выводы ничем не подкрепленные.
>Ведь всем известно, что Perl - мёртв, а Python - это ум, честь и совесть всех настоящих программистов.
Давайте вы просто назовете мне книгу по Perl, вышедшую за последние 3 года.
>Ничего другого изучать не нужно.
Кто вам сказал, что мы не знаем perl, есть мнение, судя по топикам, что уровень наших знаний в программирование (и даже на perl) несколько выше чем ваш.
>Если ты знаешь Python - ты крут и можешь глядеть на всех свысока.
Никто не мешает прочитать книжку на русском языке, за один вечер, что бы чуть-чуть понимать о чём речь, потом правда понадобятся годы на освоение.
>Все другие - просто дураки, раз до сих пор не поняли, насколько идеален Python.
Вот что вы хотите сказать?
> Python это единственный язык, который по максимуму использует все бонусыЕдинственность? Докажи?? А-а-а... "Единственный из тех, которые ты любишь на этой неделе"? Ну-да, ну-да.
>> Python это единственный язык, который по максимуму использует все бонусы
> Единственность? Докажи??Чо? Докажи обратное.
>>> Python это единственный язык, который по максимуму использует все бонусы
>> Единственность? Докажи??
> Чо? Докажи обратное.Бремя доказательства лежит на том, кто выскзал утверждение. Когда заявивший требует доказательств обратного, не высказав ни одного подтверждения своего высказывания, начинается демагогия.
>>>> Python это единственный язык, который по максимуму использует все бонусы
>>> Единственность? Докажи??
>> Чо? Докажи обратное.
> Бремя доказательства лежит на том, кто выскзал утверждение. Когда заявивший требует доказательств
> обратного, не высказав ни одного подтверждения своего высказывания, начинается демагогия.Единственность доказывать не нужно, более того невозможно. А вот доказательство обратного -- легче лёгкого, называется контрпример. Так что шли бы вы со своим бременем мимо.
> Единственность доказывать не нужно, более того невозможно. А вот доказательство
> обратного -- легче лёгкого, называется контрпример. Так что шли бы вы со
> своим бременем мимо.Ruby (если не знать или не так понимать python) тоже хороший язык. Некоторые вещи там сделаны на заглядение. Хоть и аналоги в python можно реализовать в 1-5 строчек, искоробочное удобство - это искоробочное удобство. :)
Если бы ruby был бы с синтаксисом python - это было интересно... хотя о чём это я, ведь Ruby с синтаксисом Python уже есть, и называется CoffeeScript. :)
> Ruby (если не знать или не так понимать python) тоже хороший язык.
> Некоторые вещи там сделаны на заглядение. Хоть и аналоги в python
> можно реализовать в 1-5 строчек, искоробочное удобство - это искоробочное удобство.
> :)Я вас умоляю... https://www.destroyallsoftware.com/talks/wat
> Если бы ruby был бы с синтаксисом python - это было интересно...
> хотя о чём это я, ведь Ruby с синтаксисом Python уже
> есть, и называется CoffeeScript. :)Ну да CoffeeScript, но это не самостоятельный язык.
>> Ruby (если не знать или не так понимать python) тоже хороший язык.
>> Некоторые вещи там сделаны на заглядение. Хоть и аналоги в python
>> можно реализовать в 1-5 строчек, искоробочное удобство - это искоробочное удобство. :)
> Я вас умоляю... https://www.destroyallsoftware.com/talks/watТоже хороший - это не значит, что такой же хороший. :)
>> Если бы ruby был бы с синтаксисом python - это было интересно...
>> хотя о чём это я, ведь Ruby с синтаксисом Python уже
>> есть, и называется CoffeeScript. :)
> Ну да CoffeeScript, но это не самостоятельный язык.Какое имеет значение, самостоятельный язык или нет - в байт-код он компилируется, в ELF или в javascript? Прежде всего - это синтаксис и возможности, а не родословная.
>>> Ruby (если не знать или не так понимать python) тоже хороший язык.
>>> Некоторые вещи там сделаны на заглядение. Хоть и аналоги в python
>>> можно реализовать в 1-5 строчек, искоробочное удобство - это искоробочное удобство. :)
>> Я вас умоляю... https://www.destroyallsoftware.com/talks/wat
> Тоже хороший - это не значит, что такой же хороший. :)На роль разбавителя "единственного" без скобочек не тянет.
> Какое имеет значение, самостоятельный язык или нет - в байт-код он компилируется,
> в ELF или в javascript? Прежде всего - это синтаксис и
> возможности, а не родословная.Я бы остерегался вообще называть его языком, с таким же успехом libcello можно назвать языком https://github.com/orangeduck/libCello . Давайте будем последовательными это диалект javascript косящий под python, кстати далеко не единственный.
>> Тоже хороший - это не значит, что такой же хороший. :)
> На роль разбавителя "единственного" без скобочек не тянет.Зайду с козырей: dsl в ruby хороший и очень простой.
>Зайду с козырей: dsl в ruby хороший и очень простой.Козыри оказались шестерками. Давайте я перечислю что такое DSL: XML,JSON,HTML,Pikle,BSON,QML... Любое декларативное описание.
>>Зайду с козырей: dsl в ruby хороший и очень простой.
> Козыри оказались шестерками. Давайте я перечислю что такое DSL: XML,JSON,HTML,Pikle,BSON,QML...
> Любое декларативное описание.Шоб вам объекты на json описывать. То ещё удовольствие. А описывать их на Python... когда я вижу модели в django, я плачу, и на django у меня естественная аллергия - краткий лаконичный язык превращается в, простите, java или ещё что похуже.
В ruby можно получить лаконичность и функциональность в одном флаконе очень-очень просто.
>>>Зайду с козырей: dsl в ruby хороший и очень простой.
>> Козыри оказались шестерками. Давайте я перечислю что такое DSL: XML,JSON,HTML,Pikle,BSON,QML...
>> Любое декларативное описание.
> Шоб вам объекты на json описывать.А что мешает, import json.
Объекты импортируются и экспортируется на ура.
А еще лучше использовать mongodb для этого.
Кстати так и делаю.> То ещё удовольствие. А описывать их
> на Python... когда я вижу модели в django, я плачу, и
> на django у меня естественная аллергия - краткий лаконичный язык превращается
> в, простите, java или ещё что похуже.Чем, простите, вам модели Django не угодили? Краткие и лаконичные.
> В ruby можно получить лаконичность и функциональность в одном флаконе очень-очень просто.
Ок, можете пример (ссылку) привести.
> А что мешает, import json.
> Объекты импортируются и экспортируется на ура.
> А еще лучше использовать mongodb для этого.
> Кстати так и делаю.Речь о создании и описании, а не об экспорте и импорте. И объектов, а не таблицы данных.
> Чем, простите, вам модели Django не угодили? Краткие и лаконичные.Не угодили тем, что не краткие и не лаконичные. Я на русском языке могу описать, что там должно храниться, за 15 слов. А в django это займёт несколько килобайт однообразного кода. Тогда как с "живым" python ровно наоборот, у меня 4 строчки на python заменяют много-много слов.
>> В ruby можно получить лаконичность и функциональность в одном флаконе очень-очень просто.
> Ок, можете пример (ссылку) привести.По ruby dsl есть много материалов, ссылок, заметок. Сказать какой-то конкретный я не могу, я не рубист и ссылки на них не храню, но читал неоднократно. А хорошие материалы... по опыту того же python могу сказать, что 99% материалов не объясняют суть, а объясняют только тем, кто это понимает, что он "всё правильно сделал". А потом находишь материал, где вся суть в четырёх словах сполна выражена, и думаешь "где же ты раньше был, год жизни бы сэкономил". Посмотрите сами, что в сети и на профильных ресурсах пишут.
>Речь о создании и описании, а не об экспорте и импорте. И объектов, а не таблицы данных.Ну тогда для вас MongoDB однозначно, там нет таблиц. Кстати намедни новая версия pymongo вышла.
>Не угодили тем, что не краткие и не лаконичные.
Название класса -> таблица
Любая строка класса -> поле записиКуда еще кратче?
>По ruby dsl есть много материалов, ссылок, заметок.
Есть большая легенда о том как прекрасен в Ruby DSL, могу даже сказать откуда ноги растут: Puppet и Chief. Но обычно люди повторяющие эту легенду сами не понимают что такое DSL, не записывайтесь в их ряды. DSL он и на Си DSL.
>>Речь о создании и описании, а не об экспорте и импорте. И объектов, а не таблицы данных.
> Ну тогда для вас MongoDB однозначно, там нет таблиц. Кстати намедни новая
> версия pymongo вышла.В openbsd mongodb как два года назад сломался, так до сих пор и не починился. :(
json-файлы удобнее тем, что их можно прямо "на месте" редактором править, подрисовать там что-нибудь, не отвлекаясь от процесса производства.
>>Не угодили тем, что не краткие и не лаконичные.
> Название класса -> таблица
> Любая строка класса -> поле записи
> Куда еще кратче?Конструкция - громоздкая. Очень много лишних слов, в котором очень много лишних букв. Python-у это не свойственно, обычно я десятью символами мир двигаю. :)
>>По ruby dsl есть много материалов, ссылок, заметок.
> Есть большая легенда о том как прекрасен в Ruby DSL, могу даже
> сказать откуда ноги растут: Puppet и Chief. Но обычно люди повторяющие
> эту легенду сами не понимают что такое DSL, не записывайтесь в
> их ряды. DSL он и на Си DSL.Я примерно представляю, что такое DSL. И примеры из интернета показывают, каким милым становится синтаксис. Это не Django-ужас.
Но puppet и chief я в глаза не видел.
Если бы в python был такой же DSL, как и в ruby, я был бы на тридцать два процента счастливее. :)
>>>Речь о создании и описании, а не об экспорте и импорте. И объектов, а не таблицы данных.
>> Ну тогда для вас MongoDB однозначно, там нет таблиц. Кстати намедни новая
>> версия pymongo вышла.
> В openbsd mongodb как два года назад сломался, так до сих пор
> и не починился. :(Ну всё не слава богу... Возьмите миркоинстанс на амазоне, он первый год бесплатный, ну почти бесплатный 1$/год.
> json-файлы удобнее тем, что их можно прямо "на месте" редактором править, подрисовать
> там что-нибудь, не отвлекаясь от процесса производства.
>>>Не угодили тем, что не краткие и не лаконичные.
>> Название класса -> таблица
>> Любая строка класса -> поле записи
>> Куда еще кратче?
> Конструкция - громоздкая. Очень много лишних слов, в котором очень много лишних
> букв. Python-у это не свойственно, обычно я десятью символами мир двигаю.
> :)Ну давайте конкретику, какая буква лишняя.
>>>По ruby dsl есть много материалов, ссылок, заметок.
>> Есть большая легенда о том как прекрасен в Ruby DSL, могу даже
>> сказать откуда ноги растут: Puppet и Chief. Но обычно люди повторяющие
>> эту легенду сами не понимают что такое DSL, не записывайтесь в
>> их ряды. DSL он и на Си DSL.
> Я примерно представляю, что такое DSL. И примеры из интернета показывают, каким
> милым становится синтаксис. Это не Django-ужас.Странно, есть проекты где таблиц под 150 и ничего ужасного ей богу, в каждом app, по файлику models.py, в каждом по 5-10 классов, в каждом классе по 5-15 строк, почти одинаковых, самое сложное придумать корректные имена. читается всё на ура, пишется с той же скоростью что и читается, вообще не задумываясь.
> Но puppet и chief я в глаза не видел.
Жаль.
> Если бы в python был такой же DSL, как и в ruby,
> я был бы на тридцать два процента счастливее. :)Так он точно такой же, как и в любом интерпретируемом языке. Поддержка декларативных множеств xml,yaml,json,ini и т.д. + модули на родном языке с текстами вроде some_string='some_text'.
> Единственность доказывать не нужно, более того невозможно.
> А вот доказательство обратного
> -- легче лёгкого, называется контрпример. Так что шли бы вы со
> своим бременем мимо.Для начала - я не услышал ни одного конкретного примера исключительности. А ля: "У Python есть такое-то свойство, которого нет в Perl, в Java, в C++ и т.п." Что тут оспаривать? Я точно так же могу заявить о собственной единственности. Каждый язык и каждый человек - единственный. С другой стороны, чем я отличаюсь от других? И чем Python отличается от других языков?
> Для начала - я не услышал ни одного конкретного примера исключительности. А
> ля: "У Python есть такое-то свойство, которого нет в Perl, в
> Java, в C++ и т.п." Что тут оспаривать? Я точно так
> же могу заявить о собственной единственности. Каждый язык и каждый человек
> - единственный. С другой стороны, чем я отличаюсь от других? И
> чем Python отличается от других языков?Речь не о свойствах, которых нет нигде, а о свойствах, которые реализованы проще, удобнее и нагляднее, чем в других языках.
Например, отступы.
Например, "всё есть словарь" и единые методы доступа ко всему, будь ты хоть класс, хоть негр преклонных годов (а не восемь разных синтаксисов, отдельные механизмы для строк, для списков, словарей)
Например, наглядность и лаконичность, удобное и короткословное использование и ФП, и ООП, и других вместе, в одном флаконе.
Например, богатая стандартная библиотека.
Python - это поэзия. И вопрос из разряда "сапоги больше Пушкина". На python проще, потому что на python проще. Не потому, что привыкли к типу и синтаксису, а потому что на python зачастую проще даже тем, кто привыкли к другому типу и синтаксису. И, поняв некоторые концепции в python, их потом проще понять в других языках (хоть другие языки и крутил много лет, но отсутствие единообразия делает эти вещи как бы отдельными от самого языка, чем-то особенным. в python же всё одинаковое).
Python - это эсперанто языков программирования.
>И чем Python отличается от других языков?Ссылка на книгу в новости.
Спасибо за проделаную работу авторам перевода.
Переводчик ... Название книги "A Byte of Python" никак нельзя перевести как "Укус Питона" ... ну если ты не упоpотый :-\
> "A Byte of Python" никак нельзя перевести как
> "Укус Питона""Питона кусок"
> ... ну если ты не упоpотый :-\
Да, большое спасибо переводчику!
Спасибо, хорошая книга для новичка, читал ещё на английском.
стр.5: "..Не продавайте электронные или печатные версии этой книги, если в её описании вы в явной форме не указали, что она распространяется не от имени её первоначального автора.."
Кто-нибудь объясните, пож-ста, смысл этого предложения.
Наверное, не хочет непредусмотренных автором "редакторских правок".
> Кто-нибудь объясните, пож-ста, смысл этого предложения.Это газывается Автооское Право: делай так, как я сказал.
Хорошо, что ты не застал Microsoft Windows, а то ж, не дай Б-р, после любой-всякой попытки прочтения их EULA, мы бы никогда не увидели тут ни тебя, ни твоих вопросов.
> Кто-нибудь объясните, пож-ста, смысл этого предложения.смысл этого предложения такой - уроки русского не следует прогуливать.
> стр.5: "..Не продавайте электронные или печатные версии этой книги, если в её
> описании вы в явной форме не указали, что она распространяется не
> от имени её первоначального автора.."
> Кто-нибудь объясните, пож-ста, смысл этого предложения.Не хочет нести ответственность за отсебятину тех, кто переделывал его книгу. Подписывать его именем можно только авторский вариант книги.
Спасибо, почитаем...
ававававав....Story behind the name: Guido van Rossum, the creator of the Python language, named the language after the BBC show "Monty Python's Flying Circus". He doesn't particularly like snakes that kill animals for food by winding their long bodies around them and crushing them.
Гвидо ван Россум, создатель языка Python, назвал его так в честь телешоу на BBC под названием “Летающий цирк Монти Пайтона”[1], а вовсе не потому, что он любит змей, убивающих животных обвиванием своего длинного тела вокруг них и задавливанием.
обвиванием и задавливанием
обвиванием и задавливанием
обвиванием и задавливаниемобвейте меня кто-нить плз и задавлите
>обвиванием и задавливаниемименно это делает с компьютером: обвивает раму и задавливает процессор
>>обвиванием и задавливанием
> именно это делает с компьютером: обвивает раму и задавливает процессорДа и книгу нужно было назвать: "A Gigabyte of Python".
> Да и книгу нужно было назвать: "A Gigabyte of Python".Giga-bite of python. То-то тут укушенные питоном носятся :)
>обвиванием и задавливанием
>обвиванием и задавливаниемЧем так, так лучше уж никак... Представляю качество остального перевода.
Промптом переводили, что ли?
а где взять исходники переведенной книги? Нашел только ссылку на оригинал, и там есть инструкция как сделать epub
> Нашел только ссылку на оригиналвот его и читай.
Куда слать правки?
> Куда слать правки?напиши на заборе.
Там на заглавной странице уже появился адрес, куда слать. Видать, отслеживают.
А ничего, что BSD4 является копипастом BSD[4], где [4] - ссылка в HTML-варианте книги? Кстати, при открытии наблюдал уже BSD[5] :) Видимо, работа над книгой продолжается.