Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 164
спасибо!
Большое спасибо за перевод! Хоть и вряд ли буду на нем писать, но язык очень интересный. Прямо получил удовольствие от изучения =)
Хоть коротенькое описание основных преимуществ языка бы было..
"Скорость выполнения программ написанных на Python очень высока."
В сравнении с чем? :)
И еще у Вас, кажется, пункты 2 и 3 в списке преимуществ перепутаны местами.
Еще, я бы "list comprehension" перевел бы как "охват списков".
А вообще хорошая статья и хороший перевод.
В сравнении с чем? :)
И еще у Вас, кажется, пункты 2 и 3 в списке преимуществ перепутаны местами.
Еще, я бы "list comprehension" перевел бы как "охват списков".
А вообще хорошая статья и хороший перевод.
Да, вы правы. Исправил.
по сравнению с ruby и php ;)
> по сравнению с ruby и php
Более того, по сравнению с перлом. По крайней мере, я наблюдал такое у себя, на самописных идентичных скриптах на питоне и перле. Холивары по этому поводу прошу не устраивать, сам перл люблю. Но тем не менее... :)
Более того, по сравнению с перлом. По крайней мере, я наблюдал такое у себя, на самописных идентичных скриптах на питоне и перле. Холивары по этому поводу прошу не устраивать, сам перл люблю. Но тем не менее... :)
Я с Вами согласен, но не худо было бы что-то подобное указать в статье :) Поэтому я вопрос и задал.
"Python требует не требует явного объявления переменных"
что бы это значило?...
что бы это значило?...
Кажется лучшее введение в этот язык:
Magnus Lie Hetland «Мгновенный Python»
http://www.fortunecity.com/skyscraper/motorola/668/rus/koi/python/belanov/instpy-r.html
Magnus Lie Hetland «Мгновенный Python»
http://www.fortunecity.com/skyscraper/motorola/668/rus/koi/python/belanov/instpy-r.html
Исправьте в тексте "картеж" на "кортеж" =)
Статья понравилась, так коротко и в то же время полно наверное нигде не видел. Про исключения можно добавить, что в Питоне есть конструкции try-except-finally (начиная с 2.5).
"Вы можете шаблон строки и подставить в него элементы из кортежа или словаря." как-то неправильно звучит )
Очень много грамматических ошибок, читать не приятно :(
По языку. Не нравится он мне :) Ни капли не жалею, что не стал его изучать :)
Что именно не нравится:
Блоки - их просто не видно. Понадобится редактор, который подсвечивает весь блок, от такого глаза быстро устанут.
Срезы - это просто конец света list[0:2]. С 0 по 2 элемент не включительно! Это ж надо было такое придумать? Есть аргументы? Приведите их пожалуйста.
Очень понравились условные операторы.
Преимущества языка какие-то просто громко сказанные. Никогда не поверю, что Python удобнее Perl, и тем более богаче :) Может быть где-то быстрее, но в сегодняшнем мире программирования скорость не главное :) Современные технологии основанные на XML и XSL на производительность просто забивают, так что скорость тут не аргумент. Хотя все зависит от поставленной задачи :)
Ну это просто смешно. Сами подумайте, много ли вы писали модулей для PHP? Для Python напишите ровно столько же ;) Модули должны писаться на том же языке! Для Perl, например, можно писать модули на Perl (и таких большинство) и на Си (для самых требовательных задач), причем используются они одинаково с точки зрения интерфейса.
В итоге мне понравились только условные операторы.
Все сказанное сугубо IMHO.
По языку. Не нравится он мне :) Ни капли не жалею, что не стал его изучать :)
Что именно не нравится:
Блоки - их просто не видно. Понадобится редактор, который подсвечивает весь блок, от такого глаза быстро устанут.
Срезы - это просто конец света list[0:2]. С 0 по 2 элемент не включительно! Это ж надо было такое придумать? Есть аргументы? Приведите их пожалуйста.
Очень понравились условные операторы.
Преимущества языка какие-то просто громко сказанные. Никогда не поверю, что Python удобнее Perl, и тем более богаче :) Может быть где-то быстрее, но в сегодняшнем мире программирования скорость не главное :) Современные технологии основанные на XML и XSL на производительность просто забивают, так что скорость тут не аргумент. Хотя все зависит от поставленной задачи :)
В связи с этим вы можете писать свои собственные модули для Python на C или C++
Ну это просто смешно. Сами подумайте, много ли вы писали модулей для PHP? Для Python напишите ровно столько же ;) Модули должны писаться на том же языке! Для Perl, например, можно писать модули на Perl (и таких большинство) и на Си (для самых требовательных задач), причем используются они одинаково с точки зрения интерфейса.
В итоге мне понравились только условные операторы.
Все сказанное сугубо IMHO.
Во первых прошу прощения за грамматические ошибки. Постарался все проверить, но видимо проверил не все… А теперь по порядку:
1. Не буду спорить с вами о предпочтениях.
2. Я объяснил так, потому что так понятно. Если мы используем list[0:2], то на выходе мы получим значения list[0], list[1],list[2]. Вот так, а [2] мы уже не получаем. По моему написанно вполне доступно.
3. а) Каждый выбирает то что ему удобнее.
б) «Хотя все зависит от поставленной задачи» — вот именно! Для одной поставленной задачи может 2-3 мкс не важны, но в другой эти мкс могут вылиться в что-то большее.
в) Я говорю что вы можете писать модули для Python. А вот кому это надо — другой вопрос. Возможно просто вы с ними не знакомы.
4. Я рад, что вам понравились условные операторы.
1. Не буду спорить с вами о предпочтениях.
2. Я объяснил так, потому что так понятно. Если мы используем list[0:2], то на выходе мы получим значения list[0], list[1],
3. а) Каждый выбирает то что ему удобнее.
б) «Хотя все зависит от поставленной задачи» — вот именно! Для одной поставленной задачи может 2-3 мкс не важны, но в другой эти мкс могут вылиться в что-то большее.
в) Я говорю что вы можете писать модули для Python. А вот кому это надо — другой вопрос. Возможно просто вы с ними не знакомы.
4. Я рад, что вам понравились условные операторы.
1. Последняя строчка в моем посте должна была исключить это Ваше замечание ;) IMHO есть IMHO.
2. Написано доступно, претензия не Вам, а языку. Конструкция не очевидна.
2. Написано доступно, претензия не Вам, а языку. Конструкция не очевидна.
На самом деле, как мне кажется, для бо́льшей простоты понимания конструкцию list[0:2] можно описать как «взять два элемента списка начиная с нулевого»; в этом случае срез как раз берёт элементы с нулевого по второй исключая элемент с индексом 2.
> Блоки - их просто не видно. Понадобится редактор, который подсвечивает весь блок, от такого глаза быстро устанут.
Если код слеплен так, что отступ блока на пробел больше, чем предыдущего, это не беда языка, это диагноз программиста. При стандартных табовых отступах с размером таба в 4 пробела, как рекомендуется, блоки чудесно видно.
> Срезы - это просто конец света list[0:2]. С 0 по 2 элемент не включительно! Это ж надо было такое придумать?
Считайте, что второе значение - это не индекс, а размер среза. Т.е. в указанном list[0:2] мы имеем дело со срезом, начинающимся с элемента с индексом 0 и содержащего в себе 2 элемента - нулевой и первый. Что здесь не так?
Если код слеплен так, что отступ блока на пробел больше, чем предыдущего, это не беда языка, это диагноз программиста. При стандартных табовых отступах с размером таба в 4 пробела, как рекомендуется, блоки чудесно видно.
> Срезы - это просто конец света list[0:2]. С 0 по 2 элемент не включительно! Это ж надо было такое придумать?
Считайте, что второе значение - это не индекс, а размер среза. Т.е. в указанном list[0:2] мы имеем дело со срезом, начинающимся с элемента с индексом 0 и содержащего в себе 2 элемента - нулевой и первый. Что здесь не так?
Сами хоть поняли что сказали?
1) Не важно какой отступ, хоть в 10 пробелов, блок все равно явно не выделен. Если между блоками нет пустой строки, они сливаются. Кстати, стандартный "табовый" отступ - 8 пробелов ;)
2) Пример list[5:6] полностью опровергает ваше высказывание и возвращает только элемент list[5]. Если хотите, можете считать, что второе значение это размер среза, на здоровье ;)
1) Не важно какой отступ, хоть в 10 пробелов, блок все равно явно не выделен. Если между блоками нет пустой строки, они сливаются. Кстати, стандартный "табовый" отступ - 8 пробелов ;)
2) Пример list[5:6] полностью опровергает ваше высказывание и возвращает только элемент list[5]. Если хотите, можете считать, что второе значение это размер среза, на здоровье ;)
Сам понял. В отличие от многих других, я часто понимаю, что говорю.
1. А ставить пустую строку в Питоне Вам религия не позволяет? Насчет стандарта - если не секрет, где Вы его взяли? Я считаю стандартом рекомендации автора языка. А Вы?
2. Спасибо Вам огромное, буду считать не здоровье. Тем не менее, я не услышал ответа на вопрос, что не так в подобной записи. Вы считаете, что "не включительно" не имеет право на существование только потому, что не нравится лично Вам?
1. А ставить пустую строку в Питоне Вам религия не позволяет? Насчет стандарта - если не секрет, где Вы его взяли? Я считаю стандартом рекомендации автора языка. А Вы?
2. Спасибо Вам огромное, буду считать не здоровье. Тем не менее, я не услышал ответа на вопрос, что не так в подобной записи. Вы считаете, что "не включительно" не имеет право на существование только потому, что не нравится лично Вам?
1. Я не использую Питон, т.к. он меня полностью не устраивает.
Насчет стандарта. Здесь ищем высказывание Если разметка не задана, то по умолчанию применяется значение -8 - "стандарт" табуляций системы UNIX
Из 2 явно следует, что Вы не понимаете о чем говорите. Вы не правы и не признаете этого.
Я считаю, что "не включительно" в данном контексте просто не интуитивно.
Если я хочу получить элементы с 5 по 7, мне понятнее будет написать list[5:7], а не list[5:8]. Язык должен читаться.
Насчет стандарта. Здесь ищем высказывание Если разметка не задана, то по умолчанию применяется значение -8 - "стандарт" табуляций системы UNIX
Из 2 явно следует, что Вы не понимаете о чем говорите. Вы не правы и не признаете этого.
Я считаю, что "не включительно" в данном контексте просто не интуитивно.
Если я хочу получить элементы с 5 по 7, мне понятнее будет написать list[5:7], а не list[5:8]. Язык должен читаться.
НАсчет п.2 я с вами согласен. Под записью [5:7] я бы тоже понимал от 5 до семи включительно. Поэтому и уделил внимание записи невключительно. Подумал что это вам и не понравилось.
А Вас не смущает, что для обращения к первому элементу массива в большинстве языков надо написать что-то вроде arr[0]?
Обсуждаемая проблема меня больше смущает.
С нуля в мире компьютеров считается практически все еще с момента их (компьютеров) зарождения. Так что этот момент никого смущать не должен.
С нуля в мире компьютеров считается практически все еще с момента их (компьютеров) зарождения. Так что этот момент никого смущать не должен.
Ну так отсчеты массива с нуля и особенности механизма срезов в питоне - одного поля ягоды.
В общем, мне кажется, что я спорю о вкусе устриц с тем, кто их не ел.
В общем, мне кажется, что я спорю о вкусе устриц с тем, кто их не ел.
Насчет устриц.
Мне кажется, что Вы кроме них ничего не ели ;)
Мне кажется, что Вы кроме них ничего не ели ;)
А Вам почему так кажется?
Мне, например, потому что судя по Вашим комментариям в этом топике, вы не написали и десятка строк кода на Питоне, но при этом ничтоже сумняшеся критикуете его, рассказываете, что не удобно и что плохо сделано.
Мне, например, потому что судя по Вашим комментариям в этом топике, вы не написали и десятка строк кода на Питоне, но при этом ничтоже сумняшеся критикуете его, рассказываете, что не удобно и что плохо сделано.
Да, не писал. Не пользовался.
И не буду пользоваться. Почему? Да потому что синтаксис языка изначально не позволяет мне оформлять код так, как мне нравится. У меня нет свободы, а ее очень люблю.
Потом про срезы. Такой формат просто неочевиден. Это самое запутывающее, что я только встречал.
И потом, в конце моего поста русским по белому написано IMHO! И это самое IMHO ни в коем случае не должно совпадать ни с Вашим, ни с чьим-либо другим.
P.S. Я с Вами общаюсь на русском языке, и всякие вставки типа "ничтоже сумняшеся" есть элементарное неуважение.
И не буду пользоваться. Почему? Да потому что синтаксис языка изначально не позволяет мне оформлять код так, как мне нравится. У меня нет свободы, а ее очень люблю.
Потом про срезы. Такой формат просто неочевиден. Это самое запутывающее, что я только встречал.
И потом, в конце моего поста русским по белому написано IMHO! И это самое IMHO ни в коем случае не должно совпадать ни с Вашим, ни с чьим-либо другим.
P.S. Я с Вами общаюсь на русском языке, и всякие вставки типа "ничтоже сумняшеся" есть элементарное неуважение.
IMHO - это не белый билет. Если вы выносите своё мнение на общий вид, то будьте готовы, что оно столкнется с другим таким же IMHO. Например, с моим.
P.S. Вы мне только что буквально вынесли мозг. Чем Вам не нравится выражение "ничтоже сумняжеся"? Это абсолютно нормальное русское крылатое выражение.
P.S. Вы мне только что буквально вынесли мозг. Чем Вам не нравится выражение "ничтоже сумняжеся"? Это абсолютно нормальное русское крылатое выражение.
1. Насчет стандарта. Повторяю еще раз: автором языка рекомендован размер таба в 4 пробела. Что касается tabs:
man tabs
The following options shall be supported:
-n Specify repetitive tab stops separated by a uniform number of column positions, n, where n is a single-digit decimal number. The default usage of tabs with no arguments shall be equivalent to tabs-8.
Как видите, ничего и близко похожего на "Особое значение имеет разметка -8: для системы UNIX она является стандартной" из Вашего документа. Откровенно говоря, это больше похоже на домыслы переводчика. Если уж пользуемся документацией, давайте ссылаться на ОРИГИНАЛЫ, а не на не очень удачные переводы.
По поводу того, что Питон Вы не используете. ВЫ заявили, что в Питоне блоки сливаются потому, что между блоками нельзя поставить пустую строку. Когда Вам указали, что пустую строку поставить можно, ВЫ же заявили, что это значения не имеет, потому что Питон Вы не используете. Ловкий ход, что тут скажешь.
Из 2 не следует ровным счетом ничего. Я НЕ говорил, что второй индекс - это размер среза. Я сказал, что для КОНКРЕТНОГО приведенного Вами примера его можно трактовать так. Вы же заявили, что "не включительно" - это однозначно плохо. Только после долгой дискуссии Вы сказали, что Вы так считаете. Если бы так было сказано изначально, спора по этому поводу и не возникло бы.
man tabs
The following options shall be supported:
-n Specify repetitive tab stops separated by a uniform number of column positions, n, where n is a single-digit decimal number. The default usage of tabs with no arguments shall be equivalent to tabs-8.
Как видите, ничего и близко похожего на "Особое значение имеет разметка -8: для системы UNIX она является стандартной" из Вашего документа. Откровенно говоря, это больше похоже на домыслы переводчика. Если уж пользуемся документацией, давайте ссылаться на ОРИГИНАЛЫ, а не на не очень удачные переводы.
По поводу того, что Питон Вы не используете. ВЫ заявили, что в Питоне блоки сливаются потому, что между блоками нельзя поставить пустую строку. Когда Вам указали, что пустую строку поставить можно, ВЫ же заявили, что это значения не имеет, потому что Питон Вы не используете. Ловкий ход, что тут скажешь.
Из 2 не следует ровным счетом ничего. Я НЕ говорил, что второй индекс - это размер среза. Я сказал, что для КОНКРЕТНОГО приведенного Вами примера его можно трактовать так. Вы же заявили, что "не включительно" - это однозначно плохо. Только после долгой дискуссии Вы сказали, что Вы так считаете. Если бы так было сказано изначально, спора по этому поводу и не возникло бы.
The default usage of tabs with no arguments shall be equivalent to tabs-8
Вами же и написано ;)
Всем известно, что значение по умолчанию - скорее всего стандартное.
Остальной текст вы выдумали.
Доказательства:
http://michael-p.habrahabr.ru/blog/21477… - тут нигде не сказано о том, что нельзя поставить пустую строку :)
http://michael-p.habrahabr.ru/blog/21477… - Вы говорите что "второе значение - это не индекс, а размер среза". А потом даете описание (именно описание) конкретного (именно конкретного) примера в Вашем неправильном трактовании.
Вы мне приписываете слова, которых я не говорил - вот что "однозначно плохо".
Вами же и написано ;)
Всем известно, что значение по умолчанию - скорее всего стандартное.
Остальной текст вы выдумали.
Доказательства:
http://michael-p.habrahabr.ru/blog/21477… - тут нигде не сказано о том, что нельзя поставить пустую строку :)
http://michael-p.habrahabr.ru/blog/21477… - Вы говорите что "второе значение - это не индекс, а размер среза". А потом даете описание (именно описание) конкретного (именно конкретного) примера в Вашем неправильном трактовании.
Вы мне приписываете слова, которых я не говорил - вот что "однозначно плохо".
Написано о значении по умолчанию для отдельной программы. Почему Вы пытаетесь представить это как стандарт для написания кода?
> http://michael-p.habrahabr.ru/blog/21477… - тут нигде не сказано о том, что нельзя поставить пустую строку
Ваши слова:
1. Блоки - их просто не видно
2. Не важно какой отступ, хоть в 10 пробелов, блок все равно явно не выделен. Если между блоками нет пустой строки, они сливаются
Здесь русским языком сказано, что блоки не видно потому, что между ними нет пустой строки. Получается, что минус языка состоит в том, что Вы не желаете ставить между блоками пустую строку. Как ни крути, такой логики я не понимаю.
> Вы говорите что "второе значение - это не индекс, а размер среза". А потом даете описание (именно описание) конкретного (именно конкретного) примера в Вашем неправильном трактовании.
Ну если в качестве аргументов начал приводиться порядок слов, то тут спорить уже не о чем.
> Вы мне приписываете слова, которых я не говорил.
Чушь. Большая часть Ваших реплик бездоказательна. Приведите мне ЦИТАТЫ того, что я "выдумал" или "приписал" Вам.
> http://michael-p.habrahabr.ru/blog/21477… - тут нигде не сказано о том, что нельзя поставить пустую строку
Ваши слова:
1. Блоки - их просто не видно
2. Не важно какой отступ, хоть в 10 пробелов, блок все равно явно не выделен. Если между блоками нет пустой строки, они сливаются
Здесь русским языком сказано, что блоки не видно потому, что между ними нет пустой строки. Получается, что минус языка состоит в том, что Вы не желаете ставить между блоками пустую строку. Как ни крути, такой логики я не понимаю.
> Вы говорите что "второе значение - это не индекс, а размер среза". А потом даете описание (именно описание) конкретного (именно конкретного) примера в Вашем неправильном трактовании.
Ну если в качестве аргументов начал приводиться порядок слов, то тут спорить уже не о чем.
> Вы мне приписываете слова, которых я не говорил.
Чушь. Большая часть Ваших реплик бездоказательна. Приведите мне ЦИТАТЫ того, что я "выдумал" или "приписал" Вам.
Спорить с Вами нет смысла :)
Про значение для отдельной программы. Табуляция в 8 символов изначально стандартна для UNIX. 4 пробела просто удобнее и практически все используют. 4 симфола де-факто, 8 де-юре.
Насчет порядка слов. Мы общаемся на русском языке, а в нем очень многое зависит именно от порядка слов. Именно за счет этого он великий и могущий. Так что прежде чем что-то написать, подумайте как это поймут другие.
Насчет приписывания. "ВЫ заявили, что в Питоне блоки сливаются потому, что между блоками нельзя поставить пустую строку" - Ваши слова. Я такого не заявлял. Это нигде не написано! Если Вы не можете по человечески интерпретировать написанное - это Ваша проблема.
"Вы же заявили, что "не включительно" - это однозначно плохо." Уж извините, но такого я точно не заявлял. Это Вы придумали.
Продолжать разговор не имеет смысла.
Про значение для отдельной программы. Табуляция в 8 символов изначально стандартна для UNIX. 4 пробела просто удобнее и практически все используют. 4 симфола де-факто, 8 де-юре.
Насчет порядка слов. Мы общаемся на русском языке, а в нем очень многое зависит именно от порядка слов. Именно за счет этого он великий и могущий. Так что прежде чем что-то написать, подумайте как это поймут другие.
Насчет приписывания. "ВЫ заявили, что в Питоне блоки сливаются потому, что между блоками нельзя поставить пустую строку" - Ваши слова. Я такого не заявлял. Это нигде не написано! Если Вы не можете по человечески интерпретировать написанное - это Ваша проблема.
"Вы же заявили, что "не включительно" - это однозначно плохо." Уж извините, но такого я точно не заявлял. Это Вы придумали.
Продолжать разговор не имеет смысла.
1. Я не могу себе представить, какой же нужно использовать шрифт, редактор и монитор, чтобы блоки с отступами в 4 символа сливались. В статье есть примеры с форматированием. Вы действительно считаете, что этот код плохо читаем?
2. неправильно выразился. Разница между первым и вторым элементом в срезе - это количество элементов. Восприятие такой конструкции - вопрос привычки, на мой взгляд. Зато очень удобно: list[2:] (с 2 и до конца), list[:2] (с 0 до 2), варианты с переворачиванием списка через отрицательные срезы и т.п.
Мне кажется, что Вы как-то очень поверхностно ознакомились с языком и стали делать далеко идущие выводы.
Хотя, если не нравится, то не нравится.
2. неправильно выразился. Разница между первым и вторым элементом в срезе - это количество элементов. Восприятие такой конструкции - вопрос привычки, на мой взгляд. Зато очень удобно: list[2:] (с 2 и до конца), list[:2] (с 0 до 2), варианты с переворачиванием списка через отрицательные срезы и т.п.
Мне кажется, что Вы как-то очень поверхностно ознакомились с языком и стали делать далеко идущие выводы.
Хотя, если не нравится, то не нравится.
Заметьте, кроме Вас никто не привел более менее обоснованных аргументов, а устроили здесь непонятно что.
Фанатизм по языку не должен быть настолько слепым, чтобы нисколько не задумываться над той или иной особенностью. У нас не как у всех!
Заметьте, я просто высказал свое мнение, я никому его не навязывал. И что я получил в ответ? Мое мнение не опровергли, а обосрали (извините за выражение).
Кстати PEP (Python Enhancement Proposals) - это не стандарт, а всего лишь рекомендации. Если мне рекомендуют длину строки кода делать не более 79 символов, это еще не значит, что мне нельзя делать строки на всю ширину моего экрана.
Насчет итераторов. Думаю не самый лучший аргумент. Си - язык куда более низкого уровня. Или я ошибаюсь? Исправьте пожалуйста, мне не нужны ошибочные знания. Потом, итераторы, если не ошибаюсь, это одна из сущностей STL (Standart Template Library). Это не стандартные возможности языка, в самом языке Си нет итераторов. Если мне не изменяет память (а если изменяет, пожалуйста исправьте), в STL нет срезов. Есть метод типа slice (может copy, точно не помню), но именно среза нет. Так что особенности STL в применении к Python не самый убедительный аргумент.
Все сказанное, как всегда, IMHO.
Фанатизм по языку не должен быть настолько слепым, чтобы нисколько не задумываться над той или иной особенностью. У нас не как у всех!
Заметьте, я просто высказал свое мнение, я никому его не навязывал. И что я получил в ответ? Мое мнение не опровергли, а обосрали (извините за выражение).
Кстати PEP (Python Enhancement Proposals) - это не стандарт, а всего лишь рекомендации. Если мне рекомендуют длину строки кода делать не более 79 символов, это еще не значит, что мне нельзя делать строки на всю ширину моего экрана.
Насчет итераторов. Думаю не самый лучший аргумент. Си - язык куда более низкого уровня. Или я ошибаюсь? Исправьте пожалуйста, мне не нужны ошибочные знания. Потом, итераторы, если не ошибаюсь, это одна из сущностей STL (Standart Template Library). Это не стандартные возможности языка, в самом языке Си нет итераторов. Если мне не изменяет память (а если изменяет, пожалуйста исправьте), в STL нет срезов. Есть метод типа slice (может copy, точно не помню), но именно среза нет. Так что особенности STL в применении к Python не самый убедительный аргумент.
Все сказанное, как всегда, IMHO.
Насчет отступов. Если мы описываем достаточно длинный список, на Perl мы можем оформить его следующим образом:
my $array = [
'aaaaaaaaaa',
'bbbbbbbbbb',
'cccccccccc',
'dddddddddd',
'eeeeeeeeee',
];
Представьте, что в списке 20 элементов. Очень удобно таким образом оформить хеш. Оформить такой список одной строкой - получится нечитаемо. Перед каждым элементом стоит 4 пробела. Как Python воспримет такую конструкцию? Можно ли так делать?
Еще пример. Условный оператор с 10ю условиями (мало какие условия нам придется просчитывать). На Perl оформить очень удобно так
if (
условие1
||
условие2
&&
условие3
and
условие4
or
...
) {...}
Читается очень легко. Можно ли так сделать на Python? Ведь отступ это новый блок. Как он такое обрабатывает?
my $array = [
'aaaaaaaaaa',
'bbbbbbbbbb',
'cccccccccc',
'dddddddddd',
'eeeeeeeeee',
];
Представьте, что в списке 20 элементов. Очень удобно таким образом оформить хеш. Оформить такой список одной строкой - получится нечитаемо. Перед каждым элементом стоит 4 пробела. Как Python воспримет такую конструкцию? Можно ли так делать?
Еще пример. Условный оператор с 10ю условиями (мало какие условия нам придется просчитывать). На Perl оформить очень удобно так
if (
условие1
||
условие2
&&
условие3
and
условие4
or
...
) {...}
Читается очень легко. Можно ли так сделать на Python? Ведь отступ это новый блок. Как он такое обрабатывает?
Насчет стандартов табуляции. ЛОЛ! ЗАЧОТ!!!
Ради этого потратил маны и написал целых две строчки на питоне, впервые в жизни.
Вот:
#!/usr/bin/env python
print "0123456789"
print ">\t<"
Угадайте что я получил?
Табулятор в 7 пробелов!!!
Может где-то кто-то срез написал как [0:7]?
Ради такого не страшно 10 минусов получить
Ради этого потратил маны и написал целых две строчки на питоне, впервые в жизни.
Вот:
#!/usr/bin/env python
print "0123456789"
print ">\t<"
Угадайте что я получил?
Табулятор в 7 пробелов!!!
Может где-то кто-то срез написал как [0:7]?
Ради такого не страшно 10 минусов получить
Немного ошибся. Все же не семь, а восемь пробелов.
Но все равно 8, а не 4.
Но все равно 8, а не 4.
\t - символ табуляции. При нажатии кнопки Tab выводится именно он. Просто некоторые редакторы его перехватывают и заменяют на определенное число пробелов.
А суть в том, что его стандартное значение 8 пробелов. Вернее от 0 до 8 пробелов. Ведь символ табуляции придуман, чтобы ровненько выводить колонки в консоли.
А суть в том, что его стандартное значение 8 пробелов. Вернее от 0 до 8 пробелов. Ведь символ табуляции придуман, чтобы ровненько выводить колонки в консоли.
А какая взаимосвязь с рекомендацией о количестве проблелов для идентификации блоков кода и \t?
Вообще связи никакой. Но выше утверждалось что табулятор по стандарту 4 пробела.
Ещё раз. Табуляция и рекомендованное количество пробелов для разделения блоков кода. Какая взаимосвязь?
Ну Вам же объяснили, что это по стандарту (рекомендации, best practice, называйте, как хотите) Питона! А не по юниксовой консоли.
Но всё это такая ерунда, что и говорить не о чем. Любой современный редактор может вставлять вместо таба любое количество пробелов, а большинство могу менять пробелы табы. Нет никакой проблемы с этим.
Но всё это такая ерунда, что и говорить не о чем. Любой современный редактор может вставлять вместо таба любое количество пробелов, а большинство могу менять пробелы табы. Нет никакой проблемы с этим.
Я говорил о стандартной табуляции вообще. Кстати файрфокс тоже ставит табуляцию в 8 пробелов. Это стандарт.
А то, что для форматирования кода табуляция выставляется в 4 пробела, это я уже 12 лет прекрасно знаю. Стандарт и рекомендация вещи принципиально разные. Я говорил о стандарте.
А то, что для форматирования кода табуляция выставляется в 4 пробела, это я уже 12 лет прекрасно знаю. Стандарт и рекомендация вещи принципиально разные. Я говорил о стандарте.
Так поэтому Вас тут и спрашивают, какое отношение имеет стандарт табуляции к отступам в Питоне? Ккстати, а покажете ссылку на этот "стандарт"? RFC, ANSI, ISO, ECMA? W3C на худой конец? Правда, интересно ведь.
Кстати, где я говорил о связи стандартов табуляции и отступов в питоне?
Я вижу Вы очень любите придираться к словам. Поэтому, покажите мне где я говорю о стандарте и его явной связи с именно питоном.
Я вижу Вы очень любите придираться к словам. Поэтому, покажите мне где я говорю о стандарте и его явной связи с именно питоном.
Вы довольно давно уже говорите об этом в топике про Питон.
Но я, ей богу, не хочу больше с вами бодаться. Во всяком случае, пока не получу ссылку на стандарт, где написано, что \t = 8 пробелов.
Но я, ей богу, не хочу больше с вами бодаться. Во всяком случае, пока не получу ссылку на стандарт, где написано, что \t = 8 пробелов.
Народ, ну хватит обсуждать эту фигню с табуляцией. Никто первым не хочет останавливаться, что ли, синдром козленка на мосту ? :) Какое отношение вообще это имеет к статье ?
> Срезы - это просто конец света list[0:2]. С 0 по 2 элемент не включительно! Это ж надо было такое придумать? Есть аргументы? Приведите их пожалуйста.
Просто нужно понимать под аргументами среза не номера элементов, а, уж не знаю как они называются правильно, номера промежутков между элементами списка чтоли.
_["a", "b", "c", "dog", "cat"]
_0__1__2__3___4___5
-5__-4_-3__-2__-1_____(альтернативный счет с конца)
Из этой схемы все становится понятнее:
>>> a[0:-2]
['a', 'b', 'c']
>>> a[-4:-1]
['b', 'c', 'cat']
>>> a[-4:5]
['b', 'c', 'cat', 'dog']
Просто нужно понимать под аргументами среза не номера элементов, а, уж не знаю как они называются правильно, номера промежутков между элементами списка чтоли.
_["a", "b", "c", "dog", "cat"]
_0__1__2__3___4___5
-5__-4_-3__-2__-1_____(альтернативный счет с конца)
Из этой схемы все становится понятнее:
>>> a[0:-2]
['a', 'b', 'c']
>>> a[-4:-1]
['b', 'c', 'cat']
>>> a[-4:5]
['b', 'c', 'cat', 'dog']
Еще один камень в огород языка :)
Глобальные переменные. Ну зачем это надо было сделать как в PHP?
По-моему логичнее было бы сделать доступ к глобальной переменной без лишнего изврата. А если есть необходимость внутри блока (функции) определить локальную переменную с именем, как у глобальной, то лучше (было бы) для этого использовать ключевое слово local.
P.S. Для тех, кто в оправдание будет говорить, что это сделано из соображений безопасности и т.д. отвечу: это проблема не языка, а программиста.
IMHO: Очередной язык для начинающих в духе PHP.
Глобальные переменные. Ну зачем это надо было сделать как в PHP?
По-моему логичнее было бы сделать доступ к глобальной переменной без лишнего изврата. А если есть необходимость внутри блока (функции) определить локальную переменную с именем, как у глобальной, то лучше (было бы) для этого использовать ключевое слово local.
P.S. Для тех, кто в оправдание будет говорить, что это сделано из соображений безопасности и т.д. отвечу: это проблема не языка, а программиста.
IMHO: Очередной язык для начинающих в духе PHP.
Глобальные переменные, как известно, зло. По возможности, их лучше их не использовать. Поэтому локальные переменные используются чаще, и вводить для них дополнительный префикс было бы неудобно. Во многом это вопрос вкуса, как и всё остальное.
По поводу "языка для начинающих в духе PHP" - это Вы смешно сказали :)
По поводу "языка для начинающих в духе PHP" - это Вы смешно сказали :)
А откуда, если не секрет, вам известно про то, что глобальные переменные зло?
В мане по PHP я такого не видел.
В мане по PHP я такого не видел.
Я, честно говоря, даже не знаю, как Вам ответить :) Или этот комментарий - шутка?
В общем, на тот случай, если это не шутка:
"[Global variables] are usually considered bad practice precisely because of their nonlocality: a global variable can potentially be modified from anywhere, and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity."
[http://en.wikipedia.org/wiki/Global_variables]
Ну и богатый личный опыт, разумеется :)
В общем, на тот случай, если это не шутка:
"[Global variables] are usually considered bad practice precisely because of their nonlocality: a global variable can potentially be modified from anywhere, and any part of the program may depend on it. A global variable therefore has an unlimited potential for creating mutual dependencies, and adding mutual dependencies increases complexity."
[http://en.wikipedia.org/wiki/Global_variables]
Ну и богатый личный опыт, разумеется :)
Перехожу постепенно с PHP на Python и ниразу пока не жалею. Приходится писать и на одном и на втором языке паралельно. Так вот когда сажусь за PHP мне противно на нём писать становится. А само больше вырубает меня "{}" для разделения блоков (в питоне с отступами очень удобно, хотя когда только приступал к его изучению было страшно с таким разделением кода), "$" перед переменными ну это полный какой то изврат, ";" в конце строк тоже не парит моск.
Я немного писал на C и Perl, поэтому синтаксис PHP показался мне вполне похожим.
Синтаксис Python'а и Ruby мне что-то не нравиться, может стоит написать на нем пару программок, чтобы разобраться.
Синтаксис Python'а и Ruby мне что-то не нравиться, может стоит написать на нем пару программок, чтобы разобраться.
>А само больше вырубает меня «{}»
После работы с Алголом-Паскалем мне страшно не хватает скобок «begin-end», но это не стало для меня принципиальным недостатком всех последующих языков
После работы с Алголом-Паскалем мне страшно не хватает скобок «begin-end», но это не стало для меня принципиальным недостатком всех последующих языков
Очередным языком для начинающих в духе PHP он стал только из-за глобальных переменных, блоков и механизма срезов?
Я не считаю правильным общаться на подобные темы с человеком, который собирается стать отцом Бритни Спирс.
Вы совершенно правы: когда объективно нечего ответить, нужно сразу переходить на личности. А не то пустобрехом посчитают ведь!
Объективно не на что отвечать :)
Спасибо за минус ;) Очередной фанат питона? Я знаю о чем говорю, программирую уже 12 лет на разных языках, и могу кое о чем посудить ;) Готов спорить это твой первый скриптовый язык, ну максимум второй
Спасибо за минус ;) Очередной фанат питона? Я знаю о чем говорю, программирую уже 12 лет на разных языках, и могу кое о чем посудить ;) Готов спорить это твой первый скриптовый язык, ну максимум второй
Язык вынуждает нормально форматировать код, чтобы читабельней было. Неплохая задумка :) Кстати он в гугле активно используется. Наверно задачи с map-reduce на нём несложно реализовываются.
И не только в гугле. Еще в википедии, линейке и много где еще.
Если не ошибаюсь, Википедия написана на PHP.
Я говорю о pyWikipedia-ботах.
if number in (3, 4, 7, 9): #Если переменная number входит в список (3, 4, 7, 9)...
Опечатка: в кортеж, а не в список.
Опечатка: в кортеж, а не в список.
Очень правильное замечание!
И ещё немного мелких камешков:
> # объявить такую переменную для объекта. Причем
> # tэта переменная будет членом только classinstance.
Здесь неправильный цвет текста. =) + Опечатка.
Аналогично неправильная покраска:
> Исключения в Python имеют структуру try-except [exceptionname]:
> >>> fnexcept()
Некорректные отступы:
> # Но программа не "Выполняет недопустимую операцию"
> # А обрабатывает блок исключения соответствующий ошибке «ZeroDivisionError»
> # объявить такую переменную для объекта. Причем
> # tэта переменная будет членом только classinstance.
Здесь неправильный цвет текста. =) + Опечатка.
Аналогично неправильная покраска:
> Исключения в Python имеют структуру try-except [exceptionname]:
> >>> fnexcept()
Некорректные отступы:
> # Но программа не "Выполняет недопустимую операцию"
> # А обрабатывает блок исключения соответствующий ошибке «ZeroDivisionError»
>В стандартные библиотеках Python
исправьте, плиз
исправьте, плиз
простите, может я глупый вопрос задаю.. статья хорошая, спасибо, но, мне кажется, совсем бы не помешал пример "hello world" :))
а именно, где хранится, как выполняется, компилируется или интерпретируется, какие среды разработки если они есть и, наконец, какое расширение должен иметь файл? :))
спасибо)
а ввобще - на первый взгляд синтаксис мне не очень понравился.. если язык претендует на высокую читабельность кода: я не понял, как в нем реализовать логические скобки для разделения порядка и наглядности выражений?
и хотелось бы узнать про другие операторы, кроме "="...
а именно, где хранится, как выполняется, компилируется или интерпретируется, какие среды разработки если они есть и, наконец, какое расширение должен иметь файл? :))
спасибо)
а ввобще - на первый взгляд синтаксис мне не очень понравился.. если язык претендует на высокую читабельность кода: я не понял, как в нем реализовать логические скобки для разделения порядка и наглядности выражений?
и хотелось бы узнать про другие операторы, кроме "="...
высокая читабельность кода получается из жестких требований к отступам.
в пхп вы могли бы написать
if () {
..
}
if () { .. }
if ()
{
..
}
и даже
if ()
{ .. }
в питоне же - вариант только один
if cond:
..
так или иначе - получается что чьи бы исходники на питоне вы не открыли - везде будет только 1 вариант. И никак иначе. Особенно учитывая тот факт что фреймворки а-ля Zend и вовсе сейчас рекомендуют смешивать стили:
function asd()
{
}
if () {
..
}
Среду разработки лучше смотреть ту которая на питоне на самом и написана :) Заодно неплохой пример будет. wing ide скажем.
helloworld (лучше уж game over :))
hello.py:
#!/usr/bin/env python
print "Hello, World!"
#sh >python hello.py
:)
в пхп вы могли бы написать
if () {
..
}
if () { .. }
if ()
{
..
}
и даже
if ()
{ .. }
в питоне же - вариант только один
if cond:
..
так или иначе - получается что чьи бы исходники на питоне вы не открыли - везде будет только 1 вариант. И никак иначе. Особенно учитывая тот факт что фреймворки а-ля Zend и вовсе сейчас рекомендуют смешивать стили:
function asd()
{
}
if () {
..
}
Среду разработки лучше смотреть ту которая на питоне на самом и написана :) Заодно неплохой пример будет. wing ide скажем.
helloworld (лучше уж game over :))
hello.py:
#!/usr/bin/env python
print "Hello, World!"
#sh >python hello.py
:)
1. Пример хелловрда есть в статье. Однако приведу его здесь:
>>> print "Hello World!"
где >>> - приглашение интерпретатора.
2. http://ru.wikipedia.org/wiki/Python снимет основную часть вопросов.
Однако IDE\shell'ы упомяну(до конца пункта 2 идет исключительно мое мнение):
IDLE - неплохо, но минимализм скучен.
PyCrust - очень удачный shell.
WingIDE - имеет один недостаток - платность.
Boa Construstor - мощен, однако интерфейс не является интуитивно понятным.
3. Операторы и все все все. В питоне интерактивный хелп, это очень удобно.
Вы делаете так:
>>import operator
>>help(operator)
и получаете обзор операторов.
4. расширение .py
Один из приятнейших языков, по моему скромному мнению. Синтаксис чудесен- мне переодически приходиться писать мелкий программки на C и MatLab - на питоне писать приятнее. Его, как я подозреваю, очень любит ученый люд - научных библиотек под него очень-очень много.
p.s. пример логических скобок тоже есть в статье: посмотрите раздел операторы внимательней.
p.p.s. Удачного изучения =)
>>> print "Hello World!"
где >>> - приглашение интерпретатора.
2. http://ru.wikipedia.org/wiki/Python снимет основную часть вопросов.
Однако IDE\shell'ы упомяну(до конца пункта 2 идет исключительно мое мнение):
IDLE - неплохо, но минимализм скучен.
PyCrust - очень удачный shell.
WingIDE - имеет один недостаток - платность.
Boa Construstor - мощен, однако интерфейс не является интуитивно понятным.
3. Операторы и все все все. В питоне интерактивный хелп, это очень удобно.
Вы делаете так:
>>import operator
>>help(operator)
и получаете обзор операторов.
4. расширение .py
Один из приятнейших языков, по моему скромному мнению. Синтаксис чудесен- мне переодически приходиться писать мелкий программки на C и MatLab - на питоне писать приятнее. Его, как я подозреваю, очень любит ученый люд - научных библиотек под него очень-очень много.
p.s. пример логических скобок тоже есть в статье: посмотрите раздел операторы внимательней.
p.p.s. Удачного изучения =)
Если честно - питон штука хорошая, а статья - дурацкая. Непонятно для кого статья? Для начинающих? Упущено дофига теории. Для уже-знающих-другой-язык? В таком случае объяснение как расставлять двойные и одинарные ковычки в строках для кого? :)
Да и о питоне тут мало. Мало хорошего.
1. Многопоточность (пусть и с GIL, но все же)
2. Сильное ООП. Особенно радуют возможности манипуляции классов. Так, паттерн Singleton на питоне невозможен. Зато можно "расшарить" состояние объектов между их инстанциями. Куда более продвинутый и чаще нужный вариант.
3. Скорость. СКОРОСТЬ! Особенно если взять psyco (иногда получится быстрее чем C и это не шутка).
4. Изобретай-не-хочу. Есть PyPy. Питон написанный на питоне. Экспериментировать там с движком для энтузиастов - милое дело ;)
5. Stackless Python. С возможностью переключения стека C.
6. Self-Документирование. Так, открыв питон (сам интерпретатор). Пишем import sys. Затем help(sys). Весело? А теперь представьте - копаетесь вы в какой-нибудь программке. И запутались. И прям там в середине кода help(ЧТО_УГОДНО). И в консоли где порграмма исполняется будет help.
7. Питон легко может стать "связующим" языком. В него легко писать модули на Си. Ничуть не сложнее в программу на Си вставиьт интерпретатор питона. Не сложнее и в Яву питон впихнуть (Jython). И наоборот. В итоге питон и впихивают везде и вся. Скоро и Mozilla обещает в Firefox вставить наряду с JS. А пользователи линукса наверное уже давно заметили что и в муз. плеере и в граф. приложениях - уже везде можно писать скрипты на питоне :)
8. Python vs Perl: они достойны друг друга.
9. Python vs Ruby = Django vs ROR. RoR чертовски хорошо. А django оказывается почти на 300% быстрее :). В Ruby ещё подкупают блоки и концепция "всё - объекты" (очень уж легко читается: 5.times { do_something })
10. Библиотека скриптов. Так или иначе но и веб-сервер и работа с тегами - ну прям все там есть.
11. Python vs PHP: PHP Manual ROCKS! Начинающим (тем кто впервые программить садится) в питон лучше не лезть.
12. Встроенная возможность (и необходимость) компиляции в байткод. А так же сохранение этой стадии в виде файла *.pyc или *.pyo. После чего возможно распространение только байткода без полных исходников.
13. Segfault у меня у него получается выбить куда реже чем у PHP, например %)
14. Генераторы. Да.
В качестве огормного ЖИРНОГО минуса - GIL. Или Global Interpreter Lock. Из-за этого урода 8-ядерный сервер можно загрузить только на треть или чуть более (где то 250% из 800% у меня получалось). Т.е. конкуретное исполнение кода (необходимый минимум для GUI приложений) в питоне есть, но вот эффективной многопоточности - нет (пока?).
Сейчас питон уже популярен. И вы даже не представляете насколько. В России разрабтчиков днём с огнём не сыщешь. А ведь его уже ставят в практически все дефолтные поставки дистрибутивов линукс. Яву, знаете ли не пихают. PHP тем более. Перл - да. Но я же сказал они друг друга стоят ;).
Я вот питон люблю. С каждым днём все больше. Уж и не помню в чем была такая необходимость его изучить. Наверное Пол Грэхэм. И его эссе "Python Paradox" (погугл... поищите!). А с тех пор постоянно нахожу в нём что то новое (чего только стоило понять возможность расшаривания состояний между объектами вместо паттерна одиночки!).. И кажется нет этому конца и края %)
Кстати многое в статье относится только к Python 2.4
Например в Python 2.5 мы уже имеем очень весёлую модель исключений:
Да и о питоне тут мало. Мало хорошего.
1. Многопоточность (пусть и с GIL, но все же)
2. Сильное ООП. Особенно радуют возможности манипуляции классов. Так, паттерн Singleton на питоне невозможен. Зато можно "расшарить" состояние объектов между их инстанциями. Куда более продвинутый и чаще нужный вариант.
3. Скорость. СКОРОСТЬ! Особенно если взять psyco (иногда получится быстрее чем C и это не шутка).
4. Изобретай-не-хочу. Есть PyPy. Питон написанный на питоне. Экспериментировать там с движком для энтузиастов - милое дело ;)
5. Stackless Python. С возможностью переключения стека C.
6. Self-Документирование. Так, открыв питон (сам интерпретатор). Пишем import sys. Затем help(sys). Весело? А теперь представьте - копаетесь вы в какой-нибудь программке. И запутались. И прям там в середине кода help(ЧТО_УГОДНО). И в консоли где порграмма исполняется будет help.
7. Питон легко может стать "связующим" языком. В него легко писать модули на Си. Ничуть не сложнее в программу на Си вставиьт интерпретатор питона. Не сложнее и в Яву питон впихнуть (Jython). И наоборот. В итоге питон и впихивают везде и вся. Скоро и Mozilla обещает в Firefox вставить наряду с JS. А пользователи линукса наверное уже давно заметили что и в муз. плеере и в граф. приложениях - уже везде можно писать скрипты на питоне :)
8. Python vs Perl: они достойны друг друга.
9. Python vs Ruby = Django vs ROR. RoR чертовски хорошо. А django оказывается почти на 300% быстрее :). В Ruby ещё подкупают блоки и концепция "всё - объекты" (очень уж легко читается: 5.times { do_something })
10. Библиотека скриптов. Так или иначе но и веб-сервер и работа с тегами - ну прям все там есть.
11. Python vs PHP: PHP Manual ROCKS! Начинающим (тем кто впервые программить садится) в питон лучше не лезть.
12. Встроенная возможность (и необходимость) компиляции в байткод. А так же сохранение этой стадии в виде файла *.pyc или *.pyo. После чего возможно распространение только байткода без полных исходников.
13. Segfault у меня у него получается выбить куда реже чем у PHP, например %)
14. Генераторы. Да.
В качестве огормного ЖИРНОГО минуса - GIL. Или Global Interpreter Lock. Из-за этого урода 8-ядерный сервер можно загрузить только на треть или чуть более (где то 250% из 800% у меня получалось). Т.е. конкуретное исполнение кода (необходимый минимум для GUI приложений) в питоне есть, но вот эффективной многопоточности - нет (пока?).
Сейчас питон уже популярен. И вы даже не представляете насколько. В России разрабтчиков днём с огнём не сыщешь. А ведь его уже ставят в практически все дефолтные поставки дистрибутивов линукс. Яву, знаете ли не пихают. PHP тем более. Перл - да. Но я же сказал они друг друга стоят ;).
Я вот питон люблю. С каждым днём все больше. Уж и не помню в чем была такая необходимость его изучить. Наверное Пол Грэхэм. И его эссе "Python Paradox" (погугл... поищите!). А с тех пор постоянно нахожу в нём что то новое (чего только стоило понять возможность расшаривания состояний между объектами вместо паттерна одиночки!).. И кажется нет этому конца и края %)
Кстати многое в статье относится только к Python 2.4
Например в Python 2.5 мы уже имеем очень весёлую модель исключений:
try:
except:
..
else:
..
finally:
..
Так же появился оператор with... =)
Кстати говоря "научить" язык пониманию скобок и традиционного синтаксиса - в общем-то, легко. Кажется такой проект в инете где-то есть... Понимать отступы сложнее чем искать скобки %)Да. Статья действительно для начинающих. Но спасибо за ценные дополнения.
Отличный комментарий, спасибо.
GIL - это беда, конечно. Но с другой стороны, ожидать от скриптового (в первую очередь) языка красивой реализации многопоточности довольно сложно.
А вот это скорее формальность :) Добраться до исходного кода я всё равно смогу, пусть и с некоторым чуть большим геморроем.
Написание же C-шных модулей на питоне - дело не хитрое и зачастую полезное (если, например, надо работать с оборудованием). Чем-то напоминает расширение Visual Basic'а COM-объектами :)
Вообще, Питон - это идеальный язык, на мой взгляд, для тех, кто изучает программирование. Он наиболее близок к псевдокоду по синтаксису :) Он прививает хороший стиль оформления кода, сочетает 3 основных стиля программирования (ОО, процедурный и функциональный), бесплатен (что может быть немаловажно для школ). При этом, в отличии от Паскаля и Бейсика, питон актуален и достаточно распространен.
12. Встроенная возможность (и необходимость) компиляции в байткод. А так же сохранение этой стадии в виде файла *.pyc или *.pyo. После чего возможно распространение только байткода без полных исходников.
А вот это скорее формальность :) Добраться до исходного кода я всё равно смогу, пусть и с некоторым чуть большим геморроем.
Написание же C-шных модулей на питоне - дело не хитрое и зачастую полезное (если, например, надо работать с оборудованием). Чем-то напоминает расширение Visual Basic'а COM-объектами :)
Вообще, Питон - это идеальный язык, на мой взгляд, для тех, кто изучает программирование. Он наиболее близок к псевдокоду по синтаксису :) Он прививает хороший стиль оформления кода, сочетает 3 основных стиля программирования (ОО, процедурный и функциональный), бесплатен (что может быть немаловажно для школ). При этом, в отличии от Паскаля и Бейсика, питон актуален и достаточно распространен.
даже скомпилированную СИ программу можно разложить на исходники. Но на реальные исходники они будут похожи весьма сомнительно :). Таки потеря комментариев, всех названий переменных и проч. делает исходники практически нечитаемыми. Хоть и взлом программ при этом возможен. Зато невозможна перепродажа и практически исключается reuse. И ещё практически невозможно вытащить алгоритмы в которых потом разобраться (т.е. красть идеи).
p.s. возможно всё, но вот какими усилиями и далеко не каждому... :)
p.s. возможно всё, но вот какими усилиями и далеко не каждому... :)
Всегда уважал людей, которые пишут комментарии, по объему информации превышающие многие статьи (намеренно, не хабратопики).
> 2. Сильное ООП.
Не согласен, например len(строка) ну никак не назовешь это сильным ООП)
Или еще зачем в методах первым параметром идет некий self? )
>А django оказывается почти на 300% быстрее
Зато у РоРа комьюнити на 300% больше. А скорость это дело времени.
Не согласен, например len(строка) ну никак не назовешь это сильным ООП)
Или еще зачем в методах первым параметром идет некий self? )
>А django оказывается почти на 300% быстрее
Зато у РоРа комьюнити на 300% больше. А скорость это дело времени.
2. хинт:
>>> a = 'asd'
>>> a.__len__()
3
Сам Ruby медленнее Python. Дело не в рельсах и не в django. Тот уровень ООП, который присутсвует в Ruby требует времени. Много. Осмелюсь предположить, Ruby никогда не будет быстрее Python. И уж точно будет медленнее Python+PSYCO. Имхо.
>>> a = 'asd'
>>> a.__len__()
3
Сам Ruby медленнее Python. Дело не в рельсах и не в django. Тот уровень ООП, который присутсвует в Ruby требует времени. Много. Осмелюсь предположить, Ruby никогда не будет быстрее Python. И уж точно будет медленнее Python+PSYCO. Имхо.
Недавно смотрел скринкаст от создателя IronPython (питон на .NET) Джима Югунина. В качестве иллюстрации к вопросу производительности он продемонстрировал такой пример:
1. Сначала на IronPython запускается один из стандартных тестов производительности (с функцией Ack, но не суть). Тест по сути математический, с рекурсией. Время выполнения теста порядка 12 секунд.
2. Ключевая функция (та самая Ack) переписывается на C#, как статический метод, а затем вызывается (вообще без проблем) из питона. Результат: 0.8 секунды.
Примерно так решается большая часть проблем производительности (во всяком случае те из них, которые не связаны с параллелизмом).
1. Сначала на IronPython запускается один из стандартных тестов производительности (с функцией Ack, но не суть). Тест по сути математический, с рекурсией. Время выполнения теста порядка 12 секунд.
2. Ключевая функция (та самая Ack) переписывается на C#, как статический метод, а затем вызывается (вообще без проблем) из питона. Результат: 0.8 секунды.
Примерно так решается большая часть проблем производительности (во всяком случае те из них, которые не связаны с параллелизмом).
Очень интересно посмотреть, можно ссылочку? :)
Можно :)
len - это скорее атавизм от ранних версий. Хотя да, логичнее было бы что-то типа a.len().
Некий self - это ровно такая же фишка языка, как и отступы, как и специальные методы с двумя подчеркиваниями. По сути во всех ОО-языках такой указатель в нестатическом методе присутствует, только вот в Питоне он передается в явном виде (что, собственно, и отличает метод объекта от функции класса).
Что же касается коммьюнити, то у Руби повезло: появилась компания (37 Сигналов), которая начала его активно продвигать в массы. К сожалению, аналогичного "двигателя" для Питона (пока) нет. Т.е. есть масса компаний, которые его используют для своих разработок, но фактически ни одна из них не делает из этого принцип и не пиарит язык. Увы.
Некий self - это ровно такая же фишка языка, как и отступы, как и специальные методы с двумя подчеркиваниями. По сути во всех ОО-языках такой указатель в нестатическом методе присутствует, только вот в Питоне он передается в явном виде (что, собственно, и отличает метод объекта от функции класса).
Что же касается коммьюнити, то у Руби повезло: появилась компания (37 Сигналов), которая начала его активно продвигать в массы. К сожалению, аналогичного "двигателя" для Питона (пока) нет. Т.е. есть масса компаний, которые его используют для своих разработок, но фактически ни одна из них не делает из этого принцип и не пиарит язык. Увы.
Добавьте сюда еще средства разработк, коих для Руби масса, а для Питона - раз-два и обчелся. Наиболее приличное, что я видел в то время, когда использовал язык - это Komodo. Но он платный и довольно тормозной.
Что же касается отсуствия питоновского рантайма в дистрибутивах линуха и в винде - это не так страшно. Для винды, во всяком случае, есть возможность сгенерировать exe'шник, который будет включать интерпретатор питона, ваш байт-код и все необходимые библиотеки. Наверное, это не самое изящное решение, но и на том, как говорится, спасибо.
Что же касается отсуствия питоновского рантайма в дистрибутивах линуха и в винде - это не так страшно. Для винды, во всяком случае, есть возможность сгенерировать exe'шник, который будет включать интерпретатор питона, ваш байт-код и все необходимые библиотеки. Наверное, это не самое изящное решение, но и на том, как говорится, спасибо.
Для питона ведь как и для руби есть свой адд-он к Eclipse, или у руби есть что-то еще более мощное? (видел только RDT)
У руби есть масса IDE, на сколько я знаю, в основном они круче питоновских.
Плагин к эклипсу назывался PyDev. Когда я его пытался использовать (года 3 назад), он работал крайне забавно. Скажем, пытался вывести какой-то автокомплит после точки, поставленной на пустой строке :) В общем, недоразумение сплошное. А подсветка синтаксиса в PyDev была не ахти.
Неплохой плагин был для Емакса, но это на любителя.
Плагин к эклипсу назывался PyDev. Когда я его пытался использовать (года 3 назад), он работал крайне забавно. Скажем, пытался вывести какой-то автокомплит после точки, поставленной на пустой строке :) В общем, недоразумение сплошное. А подсветка синтаксиса в PyDev была не ахти.
Неплохой плагин был для Емакса, но это на любителя.
Для питона тоже есть плагин к IDEA, оказывается.
Может кто-нибудь смотрел?
Может кто-нибудь смотрел?
Полезнее было бы начать со статьи чем Питон лучше своих аналогов?
А так для большинства - ещё один мёртворожденный язык.
Чем он отличается(лучше) от Perl, C, JS, Basic хотя бы в общих чертах.
А так для большинства - ещё один мёртворожденный язык.
Чем он отличается(лучше) от Perl, C, JS, Basic хотя бы в общих чертах.
Все статьи вида "Чем яблоки лучше абрикосов" в конечном счете сводятся к холиварам. А вот когда у человека возникает интерес, или конкретная задача, подобное введение в язык может оказаться полезным.
х.м. если написано, что: - яблоко это фрукт и растёт на деревьях в средней полосе, то я не буду их искать среди джунглей.
Аналогично, было бы полезно в заголовке указать: это скриптовый язык используется там то и там то и отличается от своих собратьев тем то и тем то требует для себя того то и того.
Хотя краткое введение, действительно неплохое :).
Аналогично, было бы полезно в заголовке указать: это скриптовый язык используется там то и там то и отличается от своих собратьев тем то и тем то требует для себя того то и того.
Хотя краткое введение, действительно неплохое :).
Спасибо за эту статью!
Питон мне изначально понравился. Лаконичный, быстрый, мощный. Как-то год или два назад поставил попробовать, на винду, так там в дистрибутиве простенький IDE написанный на питоне. Для меня это был шок.
Читаемость кода питона - это отдельная история, более читаемого я не наблюдал за всю свою жизнь у реальных ЯП. Воистину стандартизация написания самим создателем языка - это великая вещь, риск которой оправдался на все 100%.
Очень радует уже продуманная система пакетов модулей.
Самым главным минусом Py для меня являются проблемы с хостингом, пока на _каждом_ сервере есть только PHP.. а так хочется везде видеть py+django )
Читаемость кода питона - это отдельная история, более читаемого я не наблюдал за всю свою жизнь у реальных ЯП. Воистину стандартизация написания самим создателем языка - это великая вещь, риск которой оправдался на все 100%.
Очень радует уже продуманная система пакетов модулей.
Самым главным минусом Py для меня являются проблемы с хостингом, пока на _каждом_ сервере есть только PHP.. а так хочется везде видеть py+django )
питон на хостинге мне кажется странной идеей. Те кто пишут на питоне сайты, как правило, пишут и свои http-сервера, и используют распределённую память и memcached, открывают сами уйму tcp соединений на что-то... представить себе возможный виртуальный хостинг с такими возможностями - не получится :)
виртуальные выделенные сервера это наше все. Если уж проект до цельного сервера пока не дорос :).
виртуальные выделенные сервера это наше все. Если уж проект до цельного сервера пока не дорос :).
на самом деле осознание того, что для питона надо (относительно)много условий на хостинге, отталкивает многих от написания простых сайтов на Py. Все новички начинают с PHP, в том числе из-за популярности оного на хостинге. А не написав простого сайта на Py, никогда не напишешь сложного :) я надеюсь моя мысль теперь более ясна.
mod_python все более популярен, и это радует. Подождем еще ) многим же не надо всех опций и своего http сервера, надо минимум возможностей, чтобы начать практическое использование - что в изучении и популяризации языка самое главное.
mod_python все более популярен, и это радует. Подождем еще ) многим же не надо всех опций и своего http сервера, надо минимум возможностей, чтобы начать практическое использование - что в изучении и популяризации языка самое главное.
> Однострочные комментарии начинаются со знака фунта «#»
всю жизнь считал что у фунта значек другой -
всю жизнь считал что у фунта значек другой -
хе-хе... скушал хабр мой значок, вставлю картинку http://img171.imageshack.us/img171/156/s… ...
пока искал картинку нашелся и ответ http://en.wikipedia.org/wiki/Pound
> #, known in the US as a pound sign or number sign
...о сколько нам открытий чудных...
пока искал картинку нашелся и ответ http://en.wikipedia.org/wiki/Pound
> #, known in the US as a pound sign or number sign
...о сколько нам открытий чудных...
Большое спасибо, статья очень интересная! Кто знает, может быть придется и на питоне в свое время программировать :)
Исправьте "присудствовать"
Огромное спасибо за статью.
Следуя советам ведущих Radio-T, имею в планах переход с PHP на Python везде, где это только возможно. И такая статья пришлась как раз в тему )
Следуя советам ведущих Radio-T, имею в планах переход с PHP на Python везде, где это только возможно. И такая статья пришлась как раз в тему )
Как в языке Python можна использовать данные из одного класса в другом, для работы с ними и дальнейшего преобразования.
Спасибо, отличная статья и блестящее оформление, плюс Вам в карму!
У Вас ошибка во втором примере (предпоследняя строчка):
>>> print myfunction(list)
Должно быть print myfunction(mylist)
>>> print myfunction(list)
Должно быть print myfunction(mylist)
а у Вас разметка к чертям поломалась:(
И в самом деле, статья хорошая а разметка примеров поломана… :(
Можно исправить? А то лень всё это сохранять локально чтобы посмотреть красиво.
Можно исправить? А то лень всё это сохранять локально чтобы посмотреть красиво.
Стиль изложения лично мне понравился, тем более перечислены некоторые базовые примеры среды и стандартных компонент. Спасибо за материал!
Кликбейтный заголовок. А что не за 1 минуту?
Я вот только читал эту статью 20-30 минут. А если ещё пробовать код набирать? День как минимум
Я вот только читал эту статью 20-30 минут. А если ещё пробовать код набирать? День как минимум
сейчас такую статью могут минусовать ещё долго...
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Основы языка программирования Python за 10 минут