The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

форумы
правила/FAQ
поиск
регистрация
вход
слежка
RSS


Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

Доступен перевод на русский язык книги 'A Byte of Python', opennews (ok), 23-Авг-13, (0) [смотреть все] +1

Сообщения [Сортировка по времени | RSS]


41. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 24-Авг-13, 08:01 
>  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()

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

Ответить | Правка | К родителю #16 | Наверх | Cообщить модератору

46. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (??), 24-Авг-13, 14:34 
> Всё, других вариантов нет.

Ну всё, теперь горе-копипастеры статей про питон даже бровью не поведут, когда нечаяно похерят отступы.

>не имеет значения, сколько там табов-пробелов, важно только
> одно - стоят они на одной линии или нет.

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.

Ответить | Правка | Наверх | Cообщить модератору

49. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 24-Авг-13, 15:10 
>>не имеет значения, сколько там табов-пробелов, важно только
>> одно - стоят они на одной линии или нет.
> PEP с вами не согласен.

Речь идёт не о PEP, речь идёт о восприятии человеком. Пробелы считать не нужно - достаточно видеть блоки. Разумеется, PEP-8 это благо, и только следование ему (хотя бы по большинству пунктов), делает человека человеком разумным. :)

Кстати, в данной книге я посмотрел начало: автор рекомендует использовать 4 пробела или tab. Я так и не понял, то ли он PEP-8 не читал, то ли осуждает.


> Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в
> конце блока есть несколько вложенных блоков - на взгляд так сразу
> не определишь, сколько там блоков закончилось.

"Если что-то не работает или не понятно - см. PEP-8". Это как Нагорную проповедь перечитывать - чем больше перечитываешь, тем большее открывается - потому что ситуации всегда разные...


> Когда начало уехало далеко-далеко вверх, тут так сразу и не поймёшь, какой
> там блок закончился: искомый или какой-то другой? Пробелы считать, делить на
> четыре? А вдруг писал какой-то оригинал вроде вас, который про PEP

не pep, а pep-8, большинству пунктов которого я следую и использую 4 пробела.


> выделить в отдельную подпрограмму. Но в случае со скобочками и при
> использовании хорошего стиля, когда закрывающая скобочка стоит на одной линии с
> открывающей скобочкой (или if), сориентироваться гораздо проще, потому что воображаемую
> линию можно построить не только сверху, но и снизу - от
> закрывающей скобки.

Так и строй линию от последней линии до первой. Я не понял вообще никакой разницы со скобочками, кроме того, что скобочка МОЖЕТ там стоять, а строка - ОБЯЗАНА там стоять, иначе парсер не будет работать. Таких проблем у меня не было НИКОГДА, и я даже не могу представить, как они могут возникнуть. Со скобочками есть одна проблема, но очень большая - они МЕШАЮТ.


>>да и вообще все, кроме совсем слепых,
>> совсем глупых или пыхеров...
> В Python средств защиты от ошибок очень мало, он слишком гибкий. Это
> хорошо, когда на языке можно сделать что-то сложное, но плохо, когда
> эта гибкость настолько легко доступна, что ей можно воспользоваться нечаянно, по ошибке.

Такие ошибки практически маловероятны. У меня было больше инциндентов с установленной не там скобочкой, чем с неверным отступом. А вариантов всего три:

1. Если элемент с :, то +1 отступ, и никаких других вариантов (кроме краткой записи однострочника) быть не может.

2. Если элемент не с :, то остаёмся на той же строчке

3. Если элемент не с :, то блок закончен, и отступы уходят назад

все остальные варианты дадут ошибку парсера. поэтому в реальных (а не надуманных) задачах что-то испортить - минимум шансов.

Ответить | Правка | Наверх | Cообщить модератору

65. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 24-Авг-13, 19:26 
> Речь идёт не о 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 если программа запустилась, то это ещё не значит, что в программе нет опечаток. Иногда так поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за опечатки. Куча времени теряется впустую.


Ответить | Правка | Наверх | Cообщить модератору

73. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 25-Авг-13, 02:32 
> А ещё есть одно неудобство, когда нужно временно закомментировать блок try, так
> чтобы его внутренности продолжали работать. Бывает нужно понять, какое там исключение
> возникает, но для этого каждый раз приходится отступы исправлять - не удобно.

Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.


> Ну, если вам так нравится читать, то читайте. Я - как чукча
> из анекдота, не читатель, а писатель. По мне, чем реже приходится
> прибегать к чтению и чем проще необходимую информацию уместить в голове,
> тем проще - программа быстрее пишется и отлаживается.

PEP8 - это КРАЙНЕ РЕКОМЕНДУЕМЫЙ СТАНДАРТ. И, встретя код другого "живущего по pep8 и pep20", я его легко пойму. Более того, на более-менее простой задаче два "живущих по pep8 и pep20" решат её абсолютно одинаково. :)

Наличие стандарта - это большой плюс. А позиция "я тут самый умный, и мне наплевать, кто там что будет читать, моё дело - писать" - очень усложняет поддержку.


> От какой последней линии? Кончается сразу несколько блоков, а начала блоков не
> видно. Не понятно на глаз, какие блоки уже закончились, а какие - нет.

- Люся, я на кладбище
- Кто-то умер?
- Ты не поверишь, ТУТ ВСЕ УМЕРЛИ!


То ли у нас разные русские языки, то ли разные восприятия. Если ничего снизу не торчит, то все блоки закончились. И это нормально, это самая популярная практика, просто пишешь сверху вниз, а потом не нужно задумываться о том, что где закрывать. Если такой условный пример разбавить скобочками, то сразу возрастёт сложность - их нужно будет где-то закрывать, либо }}}}, либо четыре строчки в ряд, либо "превращать perl в python, но со скобочками", ставя их ровно на линии, и получая ровно те же самые блоки, но с ни-к-селу-ни-к-городу скобочками.


> Насчёт гибкости у меня такая проблема - я хочу чтобы интерпретатор ловил
> опечатки в именах переменных. В Perl есть прагма strict и родственная
> ей fields - от таких нелепых ошибок спасает, просто не даёт
> запустить программу с такими ошибками. В Python если программа запустилась, то
> это ещё не значит, что в программе нет опечаток. Иногда так
> поработает программа полчаса, а потом вываливает тебе ошибку, которая произошла из-за
> опечатки. Куча времени теряется впустую.

dict, locals, globals. Всё есть словарь, и каждый словарь можно контролировать, если очень хочется. И, опять же, какие-то странные позывы - добавил кода, но не проверил, а через полчаса оно вывалилось? А если оно вывалилось не из-за опечатки, а из-за кривого алгоритма или лексически грамотной, но технически ошибочной конструкции? Такие вещи встречаются намного чаще - как можно не проверять то, что написал?

Короче говоря, python - это для разработчиков, которые хотят сделать код, который был бы понятным другим разработчикам, чтобы развивать его вместе и придумывать новое на его основе. А perl - для программистов (не знаю, для кого как, а для меня это слово ругательное, и лично я могу за него и в дыню дать), которые написали и свалили, и ничего их не колышет, работает - и ладно, а прочие тонкости и прочие люди уже никак не волнуют. Лично я КАЖДУЮ строчку проверяю на предмет того, "а понятно будет ли это пыхеру, которого я на улице отловлю за руку, и посажу это читать?". Могу использовать и менее эффективные и более громоздкие конструкции только для того, чтобы они были понятнее, чтобы с этим можно было реально работать, менять и дополнять (даже тем людям, которые в python понимают слабо), чтобы у написанного была дальнейшая жизнь.

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

Ответить | Правка | Наверх | Cообщить модератору

81. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (??), 26-Авг-13, 07:26 
>Когда начинаешь использовать python как python, а не как perl с оступами - таких проблем просто не возникает.

А по существу-то есть что сказать?

Есть блок:

try:
   ...
except a as e:
   ...
except b as e:
   ...
except:
   ...
else:
   ...

Когда в третий except попадает какое-то непонятное исключение, не a и не b и нужно понять, что это такое, как быть?

>Наличие стандарта - это большой плюс. А позиция "я тут самый умный, и мне наплевать, кто там что будет читать, моё дело - писать" - очень усложняет поддержку.

Это была самоирония (вы не заметили упоминание анекдота про чукчу?).

А вообще - есть такое практическое правило, что люди не могут выполнять инструкции больше четырёх страниц. Они стараются уяснить смысл и делают так, как поняли, а не по пунктам инструкции. Поэтому чем меньше инструкция - тем больше от неё толку. От больших же инструкций пользы будет не больше, чем от маленьких.

>И это нормально, это самая популярная практика, просто пишешь сверху вниз, а потом не нужно задумываться о том, что где закрывать.

Это хорошо, когда можно писать-писать, а потом бросить. Автоматическую сборку мусора тоже не дураки придумали. Проблема бывает, когда нужно ПРОДОЛЖИТЬ блок - не удобно ориентироваться, сколько там отступов нужно вправо сделать. Закрывающие фигурные скобки в этом случае помогают.

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

>dict, locals, globals. Всё есть словарь, и каждый словарь можно контролировать, если очень хочется.

Можно. Но опять-таки - в процессе работы программы, а не перед её запуском, как в Perl. И в Perl это почти ничего не стОит.

>И, опять же, какие-то странные позывы - добавил кода, но не проверил, а через полчаса оно вывалилось? А если оно вывалилось не из-за опечатки, а из-за кривого алгоритма или лексически грамотной, но технически ошибочной конструкции? Такие вещи встречаются намного чаще - как можно не проверять то, что написал?

Проблема в том, что именно на это и должны уходить умственные усилия, а не на борьбу с опечатками. У мозга ресурс ограниченный (правило 7+-2 и всё такое). Когда нужно думать ещё и об опечатках, меньше внимания достаётся алгоритму. Поэтому лучше, когда опечатки контролируются компилятором-интерпретатором на автомате. Не хочу я возлагать на себя тупую работу, с которой в состоянии справиться компьютер.

Ответить | Правка | Наверх | Cообщить модератору

87. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 08:11 
>>Когда начинаешь использовать 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);
    }
}


и посчитаем конструкции, которые нужны компьютеру, но не человеку, все эти ;, $, (, {

Вот на что внимание расходуется больше.

Ответить | Правка | Наверх | Cообщить модератору

97. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 26-Авг-13, 10:50 
>[оверквотинг удален]
> 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. Даже пример писать не хочется, потому что придётся сейчас в документацию лезть.

Ответить | Правка | Наверх | Cообщить модератору

95. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 26-Авг-13, 10:29 
> А 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/

Ответить | Правка | К родителю #73 | Наверх | Cообщить модератору

96. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 10:32 
>> И в мире, где opensource стало царицей полей - это очень важно.
>> Поддерживаемость - это основной козырь ранее написанного кода, чтобы не пришлось
>> его переизобретать. Именно на этом основывается преимущество opensource.
> Идеологическая промывка засчитана. Любому сотруднику, которому предстоит дорабатывать
> программу, дают доступ к исходникам. Срач в исходниках недопустим в любом
> случае, будь то опенсорс или проприетарщина.
> Поддерживаемость у проприетарных продуктов кагбэ значительно выше, проприетарщики деньги
> зарабатывают, ценят свою репутацию, а потому не могут кинуть клиента.

"Идеологическая промывка засчитана".

Ответить | Правка | Наверх | Cообщить модератору

98. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 26-Авг-13, 11:04 
> "Идеологическая промывка засчитана".

А вы почитайте, почитайте. Наиболее сложные и хорошие программы, _как_правило_ (не всегда, конечно), начинались как коммерческие проекты. По стечению обстоятельств их просто подарили радетелям за свободу.

Ответить | Правка | Наверх | Cообщить модератору

102. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 26-Авг-13, 14:33 
> Наиболее сложные и хорошие программы, _как_правило_ (не всегда, конечно), начинались как коммерческие проекты.

Кхм... Linux,Nginx и даже ваш любимый Perl. Из обратного могу только вспомнить Blender.

Ответить | Правка | Наверх | Cообщить модератору

50. "Доступен перевод на русский язык книги A Byte of Python"  +1 +/–
Сообщение от Аноним (-), 24-Авг-13, 15:20 
>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.

Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера допустим, зачем приводить спагетти код как аргумент.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

68. "Доступен перевод на русский язык книги A Byte of Python"  –1 +/–
Сообщение от www2 (ok), 24-Авг-13, 20:53 
>>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.
> Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера
> допустим, зачем приводить спагетти код как аргумент.

Затем, что это лишь иллюстрация. Книжка по рефакторингу этот неудачный момент Python'а не исправит, потому что речь о свойствах языка, а не о свойствах программы, которая на нём написана.

Ответить | Правка | Наверх | Cообщить модератору

80. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 25-Авг-13, 21:32 
>>>Только когда крутишь большой блок, то прицел часто сбивается. Особенно когда в конце блока есть несколько вложенных блоков - на взгляд так сразу не определишь, сколько там блоков закончилось.
>> Вы бы нашли уже себе приличную книгу по рефракторингу, ей богу, Фаулера
>> допустим, зачем приводить спагетти код как аргумент.
> Затем, что это лишь иллюстрация.

Иллюстрация чего?

>Книжка по рефакторингу этот неудачный момент Python'а
> не исправит, потому что речь о свойствах языка, а не о
> свойствах программы, которая на нём написана.

Ну хватит чушь нести.

Ответить | Правка | Наверх | Cообщить модератору

51. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 24-Авг-13, 15:21 
>[оверквотинг удален]
>            
>    if d <> 8:
>            
>        ...
>            
>    elif d <> c:
>            
>        ...
>            
>        if not d:

Отличный пример. Просто прекрасный. Его можно превратить в неприятную задачу, после которой код будет выглядеть намного ужаснее, всего лишь просьбой "а теперь расставь скобочки!"

В том то и дело, что в python нужно следить только за текущим и предыдущим уровнём. Всё. Потом просто бросаешь код, не нужно думать, где его закрывать.

Даже если в python не было бы тех супервозможностей, которые у него есть, и которые реально облегчают и написание и прочтение - одно только форматирование уже было бы достоинством, позволяющим предпочесть этот язык. Хотя, конечно, у того же ruby есть много приятностей, которых в python нет.

Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

55. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 24-Авг-13, 15:52 
> Хотя,
> конечно, у того же ruby есть много приятностей, которых в python
> нет.

например?

Ответить | Правка | Наверх | Cообщить модератору

57. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 24-Авг-13, 16:29 
>> Хотя,
>> конечно, у того же ruby есть много приятностей, которых в python нет.
> например?

Я так сразу и не вспомню, потому что это возникает в процессе использования, а так просто я такие вещи в памяти не храню. :)

Ну, например, .flatten

Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн (ладно бы, у list-ов было бы .get, так и его почему-то нет).

Вставки удобнее и нагляднее, чем .format / %

Не помню, но помню, что их там немало.

Ответить | Правка | Наверх | Cообщить модератору

60. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 24-Авг-13, 17:02 
>Ну, например, .flatten

Это который к array? В numpy круче.

>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн

Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.

> (ладно бы, у list-ов было бы .get, так и его почему-то нет).

Есть .pop и срезы.

Ответить | Правка | Наверх | Cообщить модератору

61. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 24-Авг-13, 17:07 
>>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн
> Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.

Я не говорил про None. Был бы какой-нибудь ListNone...

>> (ладно бы, у list-ов было бы .get, так и его почему-то нет).
> Есть .pop

Это всё не очень удобно.

>  и срезы.

Ты гений! Реально работает, вовзращает то, что нужно!

Ответить | Правка | Наверх | Cообщить модератору

63. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 24-Авг-13, 17:14 
>>>Ещё мне удобнее, когда отсутствующий list index даёт nil, а не эксепшн
>> Дзен Python: Явное лучше неявного. None вполне может быть элементом списка.
> Я не говорил про None. Был бы какой-нибудь ListNone...

Вводить новый тип, зачем, except IndexError: someaction вполне рулит.

>>> (ладно бы, у list-ов было бы .get, так и его почему-то нет).
>> Есть .pop
> Это всё не очень удобно.
>>  и срезы.
> Ты гений! Реально работает, вовзращает то, что нужно!

Я не гений, это азы.

Ответить | Правка | Наверх | Cообщить модератору

75. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 25-Авг-13, 02:35 
>> Я не говорил про None. Был бы какой-нибудь ListNone...
> Вводить новый тип, зачем, except IndexError: someaction вполне рулит.

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

Ответить | Правка | Наверх | Cообщить модератору

78. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 25-Авг-13, 21:25 
>>> Я не говорил про None. Был бы какой-нибудь ListNone...
>> Вводить новый тип, зачем, except IndexError: someaction вполне рулит.
> Однострочники - это удобно, его можно запульнуть в значение-параметр, его можно легко
> впихнуть в шаблон, сделав маленькое удобство, которое сделает проект ещё удобнее.
> Если такие удобства делать большими вставками, то и тратится лишнее время,
> и добавляется лишний код, который будет под ногами путаться... а однострочник
> всунул, и порядок, висит в углу, считает калории или ещё что-нибудь,
> и никак не мешает.

Давайте я вам озвучу вашу проблему. Вы путаете типы ruby и python. Тип array в ruby и list в python означают совсем разные сущности. В python даже в стандартной библиотеки перечисляемых типов ну просто завались, похоже вы выбрали не тот тип. Вам нужно было выбрать словарь, возможно посмотреть на кучу(heapq), bisect или типы из collection.

Ответить | Правка | Наверх | Cообщить модератору

89. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 08:19 
> Давайте я вам озвучу вашу проблему. Вы путаете типы 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. Может быть, есть хук, чтобы это при лодинге исправлять?

Ответить | Правка | Наверх | Cообщить модератору

92. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 26-Авг-13, 09:38 
>[оверквотинг удален]
> хук, то тип должен приводиться к list. А у меня почти
> все данные - родом из json.
> Во-вторых, в list есть срезы.
> В-третьих, можно, конечно, вместо dict-ов в list-ах использовать dict-ы в dict-ах, но
> лично для меня list-ы выглядят эстетичнее. Для меня удобство и приятность
> поглощения моим восприятием - это самое главное, что-то неприятное или сложное
> я просто не буду воспринимать. Изначально я именно dict в dict
> и использовал, какие-то неприятные ощущения остались. К тому же, в json
> ключи строковые, даже если в словаре они int. Может быть, есть
> хук, чтобы это при лодинге исправлять?

Увы и ах, без приведения кода ничем не могу вам помочь, если хотите напишите сюда python.su поможем решить вашу проблему.

Ответить | Правка | К родителю #89 | Наверх | Cообщить модератору

94. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 09:42 
> Увы и ах, без приведения кода ничем не могу вам помочь, если
> хотите напишите сюда python.su поможем решить вашу проблему.

на python.su я пишу, и помогают :) а проблемы, как таковой нет, если не считать небольшой зависти к рубистам :)

Ответить | Правка | К родителю #92 | Наверх | Cообщить модератору

100. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 26-Авг-13, 13:12 
>> Увы и ах, без приведения кода ничем не могу вам помочь, если
>> хотите напишите сюда python.su поможем решить вашу проблему.
> на python.su я пишу, и помогают :) а проблемы, как таковой нет,
> если не считать небольшой зависти к рубистам :)

Так сформулируйте что хотите, и вдруг окажется, что все гораздо лучше.

Ответить | Правка | К родителю #94 | Наверх | Cообщить модератору

67. "Доступен перевод на русский язык книги A Byte of Python"  –1 +/–
Сообщение от www2 (ok), 24-Авг-13, 20:47 
>[оверквотинг удален]
>>        ...
>>
>>    elif d <> c:
>>
>>        ...
>>
>>        if not d:
> Отличный пример. Просто прекрасный. Его можно превратить в неприятную задачу, после которой
> код будет выглядеть намного ужаснее, всего лишь просьбой "а теперь расставь
> скобочки!"

Эта проблема, как раз, возникает только у питонистов, когда они копипастят свои программы. В других языках эта конструкция изначально будет написана со скобочками. В Perl, кстати, даже для одного оператора в блоке if нужно ставить фигурные скобки. Не запутаешься, в отличие от.

Ответить | Правка | К родителю #51 | Наверх | Cообщить модератору

71. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 25-Авг-13, 02:07 
> Эта проблема, как раз, возникает только у питонистов, когда они копипастят свои
> программы. В других языках эта конструкция изначально будет написана со скобочками.
> В Perl, кстати, даже для одного оператора в блоке if нужно
> ставить фигурные скобки. Не запутаешься, в отличие от.

Опять придумали проблему, которая как раз у питонистов НЕ возникает, но возникает у тех, кто им не пользуется, или кто им пользуется, как перлом, не понимая, что такое pythonic.

Я даже больше скажу - если у меня в программе удалить все отступы, я их на глаз восстановлю минут за 5. Ибо сказано "Явное лучше неявного". Боязливых же и неверных участь одна... :)

Ответить | Правка | Наверх | Cообщить модератору

82. "Доступен перевод на русский язык книги A Byte of Python"  –1 +/–
Сообщение от www2 (??), 26-Авг-13, 07:30 
> Я даже больше скажу - если у меня в программе удалить все
> отступы, я их на глаз восстановлю минут за 5. Ибо сказано
> "Явное лучше неявного". Боязливых же и неверных участь одна... :)

В своей программе и я могу без фигурных скобочек и без отступов сориентироваться :) Вы в чужой сориентируйтесь.

Ответить | Правка | Наверх | Cообщить модератору

52. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 24-Авг-13, 15:35 
> В Python средств защиты от ошибок очень мало, он слишком гибкий.

Это... как бы начиная от строгой типизации, кончая doctest,unittest из коробки.

>Поэтому мне больше нравится Perl.

Хм... это где слабая типизация? И ключики между разными версиями могут запросто различаться?


Ответить | Правка | К родителю #46 | Наверх | Cообщить модератору

66. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 24-Авг-13, 20:44 
>> В Python средств защиты от ошибок очень мало, он слишком гибкий.
> Это... как бы начиная от строгой типизации, кончая doctest,unittest из коробки.

В Perl типизация менее строгая, но зато более статическая (если использовать strict, что считается общепринятым). Объявил массив - обращаться как с хэшем ты с ним не сможешь, а предупреждение об этом будет выдано ещё ДО запуска программы. Не объявил переменную или опечатался в её имени - узнаешь об этом ещё ДО запуска программы. Экономит время.

И слабая типизация в Perl не ощущается как недостаток, потому что во многих случаях трудно толковать какую-то операцию двояко: в Python a + b может означать как сложение чисел, так и конкатенацию строк, в Perl такой проблемы нет, потому что есть отдельные операции - $a + $b и отдельная - $a . $b. Ну и соответствующие операции сравнения: $a == $b и $a eq $b. Не нужно держать в голове контекст, в какой из переменных сейчас строка с числом, а где - просто число и не нужно соображать, какую из переменных приводить к нужному типу. Просто пишешь: сравни их как строки, и любая комбинация строк с числами и собственно чисел приведётся к нужному типу. Особенно удобно, когда регулярными выражениями выделяешь число - в Python я часто забывая привести число к строковому типу перед сравнением или вычислением и получаю ошибку уже в процессе работы программ, когда она отработает значительное время. Лишние потери времени, больше нужно держать в голове - не удобно.

Спрашивается - зачем мне эти модули для тестирования, когда в случаях с опечатками в именах переменных можно вообще без них обойтись? Зачем мне эта строгая типизация, если она заставляет меня держать в голове больше контекста?

>>Поэтому мне больше нравится Perl.
> Хм... это где слабая типизация? И ключики между разными версиями могут запросто
> различаться?

Не знаю, о каких ключиках речь.

Ответить | Правка | Наверх | Cообщить модератору

72. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 25-Авг-13, 02:11 
> Не нужно держать в голове контекст, в какой из переменных сейчас строка с
> числом, а где - просто число и не нужно соображать, какую
> из переменных приводить к нужному типу. Просто пишешь

"Скажи мне, на каком языке ты пишешь, и я скажу, какая каша у тебя в голове"

Приплыли. ЗАЧЕМ сравнивать две переменных, если ты даже не знаешь, ЧТО В НИХ, и не прослеживаешь контекст? Как это вообще объяснить? Типа, встал утром спозаранку, почесал яйцо, и подумал "а почему бы не сравнить a с b"?

>  Зачем мне эта строгая типизация

Она дисциплинирует. Как и оступы. Потому что в этом случае писать НЕПРАВИЛЬНО становится больно. Лучше потратить больше времени на проектирования, но написать 4 хороших строчки, чем не думая написать 50, а потом за это всю жизнь расплачиваться.

Ответить | Правка | Наверх | Cообщить модератору

83. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 26-Авг-13, 07:39 
> Приплыли. ЗАЧЕМ сравнивать две переменных, если ты даже не знаешь, ЧТО В
> НИХ, и не прослеживаешь контекст?

Я знаю, что я регуляркой выделил из строки число. Я знаю, что там число. Не понимаю, зачем мне ещё и приводить этот текст с числом к типу "число", если я это и так знаю?

> Как это вообще объяснить? Типа, встал
> утром спозаранку, почесал яйцо, и подумал "а почему бы не сравнить
> a с b"?

Дурак вы, батенька.

>>  Зачем мне эта строгая типизация
> Она дисциплинирует. Как и оступы. Потому что в этом случае писать НЕПРАВИЛЬНО
> становится больно.

Ну так бы сразу и сказали, что вы - мазохист. Я люблю писать, потому что мне это приятно. И люблю писать правильно, но не люблю, когда ко мне мой же инструмент придирается по пустякам, да ещё и с опозданием, не перед запуском программы, а в процессе работы. Ленивый язык, работает на отъебись, а не для того, чтобы помочь программисту.

> Лучше потратить больше времени на проектирования, но написать 4
> хороших строчки, чем не думая написать 50, а потом за это
> всю жизнь расплачиваться.

Надо прожить жизнь так, чтобы потом не было мучительно больно за бесцельно прожитые годы. Нужно не строчки написать, а задачу решить. Какой толк от красивых строчек, которые не решают задачи?

Ответить | Правка | Наверх | Cообщить модератору

85. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 07:59 
> Ну так бы сразу и сказали, что вы - мазохист. Я люблю
> писать, потому что мне это приятно. И люблю писать правильно, но
> не люблю, когда ко мне мой же инструмент придирается по пустякам,
> да ещё и с опозданием, не перед запуском программы, а в
> процессе работы. Ленивый язык, работает на отъебись, а не для того,
> чтобы помочь программисту.

Бред, далёкий от реальности. На python писать легко и просто, мешает там намного больше вещей, чем в perl. Если взять обычного человека, далёкого от кодирования, и попросить его решить задачу, то в perl он даже до 'hello, world' не дойдёт.


>> Лучше потратить больше времени на проектирования, но написать 4
>> хороших строчки, чем не думая написать 50, а потом за это
>> всю жизнь расплачиваться.
> Надо прожить жизнь так, чтобы потом не было мучительно больно за бесцельно
> прожитые годы. Нужно не строчки написать, а задачу решить. Какой толк
> от красивых строчек, которые не решают задачи?

Не-не-не. Вы именно кодер, который пишет код ради кода, а не для решения задач. Для разработчика идеальное число строк, которое должно быть написано - 0. Если совсем надо, то 4. И по логу коммитов этих строчек всё всем становится понятно, если оно спроектировано грамотно. И они решают реальные задачи, а не задачи кодеров по кодированию.

Это у пыхеров так заведено - писать-писать-писать, потом оглянуться, переписать всё с нуля (потому что полученный монстр вышел из-под контроля), и так далее во много итераций. Кода много, смысла мало, задачи решаются в лоб, и потом становятся фанерными (не влезай, убьёт). Кто-то перерастает это, и начинает писать на языках, которые больше этому способствуют. Чаще всего - python или ruby. Но никак не perl.

Ответить | Правка | Наверх | Cообщить модератору

105. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 21-Сен-13, 23:37 
> Бред, далёкий от реальности. На 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.

Ответить | Правка | Наверх | Cообщить модератору

79. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 25-Авг-13, 21:28 
>[оверквотинг удален]
> когда она отработает значительное время. Лишние потери времени, больше нужно держать
> в голове - не удобно.
> Спрашивается - зачем мне эти модули для тестирования, когда в случаях с
> опечатками в именах переменных можно вообще без них обойтись? Зачем мне
> эта строгая типизация, если она заставляет меня держать в голове больше
> контекста?
>>>Поэтому мне больше нравится Perl.
>> Хм... это где слабая типизация? И ключики между разными версиями могут запросто
>> различаться?
> Не знаю, о каких ключиках речь.

Господи... какая чушь.

Ответить | Правка | К родителю #66 | Наверх | Cообщить модератору

84. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от www2 (ok), 26-Авг-13, 07:58 
> Господи... какая чушь.

Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять? Ведь всем известно, что Perl - мёртв, а Python - это ум, честь и совесть всех настоящих программистов. Ничего другого изучать не нужно. Если ты знаешь Python - ты крут и можешь глядеть на всех свысока. Все другие - просто дураки, раз до сих пор не поняли, насколько идеален Python.


Ответить | Правка | Наверх | Cообщить модератору

86. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от бедный буратино (ok), 26-Авг-13, 08:01 
>> Господи... какая чушь.
> Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять? Ведь всем
> известно, что Perl - мёртв, а Python - это ум, честь
> и совесть всех настоящих программистов. Ничего другого изучать не нужно. Если
> ты знаешь Python - ты крут и можешь глядеть на всех
> свысока. Все другие - просто дураки, раз до сих пор не
> поняли, насколько идеален Python.

Python идеален не поэтому. И perl плох тоже не поэтому. :)

Python силён своей идеологией, которая проста и понятна людям. Python ближе к народу. Когда мне предлагают 5 синтаксисов одного и того же, когда у меня со строками одни функции, со списками - другие, а с генераторами - третьи, я хватаюсь за Python.

Ответить | Правка | Наверх | Cообщить модератору

90. "Доступен перевод на русский язык книги A Byte of Python"  +/–
Сообщение от Аноним (-), 26-Авг-13, 09:24 
>Ну да, проще сказать "чушь". Зачем напрягаться и пытаться понять?

Информации в вашем тексте Null, переливание из пустого в порожнее, затем опа откуда-то выводы ничем не подкрепленные.

>Ведь всем известно, что Perl - мёртв, а Python - это ум, честь и совесть всех настоящих программистов.

Давайте вы просто назовете мне книгу по Perl, вышедшую за последние 3 года.

>Ничего другого изучать не нужно.

Кто вам сказал, что мы не знаем perl, есть мнение, судя по топикам, что уровень наших знаний в программирование (и даже на perl) несколько выше чем ваш.

>Если ты знаешь Python - ты крут и можешь глядеть на всех свысока.

Никто не мешает прочитать книжку на русском языке, за один вечер, что бы чуть-чуть понимать о чём речь, потом правда понадобятся годы на освоение.

>Все другие - просто дураки, раз до сих пор не поняли, насколько идеален Python.

Вот что вы хотите сказать?

Ответить | Правка | К родителю #84 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей 		Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру