программистское, python

[avva]

Я наконец начал писать на Пайтоне. Но, по-моему, пишу в нем пока что в стиле Перла.

Из того, что не нравится:

- это ненормально, когда в языке есть встроенная функция open(), а встроенной функции close() нету. Есть в этом что-то извращенное.

- основной аргумент поклонников Пайтона - что в нем все продумано, логично, и на все есть один логичный способ это сделать, в отличие от Перла, где все можно сделать сотней разных способов. Но при приближении к объекту начинают бросаться в глаза трещины и морщины. Меня поразило количество встроенных в язык путей интерполировать значение внутри строки: 1) синтаксис %s и оператор % 2) синтаксис {0} и метод str.format() 3) синтаксис $x и класс string.Template. При этом все три способа оказались недостаточно мощными для моих достаточно скромных целей.

- какая-то фигня с Юникодом происходит. print не умеет выводить ничего, кроме байтов; нет способа объяснить ему, что юникодные строки надо выводить всегда в такой-то кодировке. Поэтому печать utf-8 строк либо включает в себя кучу вызовов decode() практически на каждую строку, либо пользуется менее удобными функциями, чем print.

В целом язык приятный. К significant whitespace привыкаешь очень быстро, и к {} обратно не тянет. Вообще синтаксис очень легкий, простой и интуитивный в большинстве случаев. Посмотрим, что он еще расскажет.

Comments

[xxqs.livejournal.com]

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

в общем, если есть возможность не использовать пайтон, то я и не использую :)

[ob3r0n.livejournal.com]

вы просто не умеете его готовить ;)

[squadette.livejournal.com]

про Hurd я просто молчу :(

в этом отношении сосут практически все языки и библиотеки!

включая, кстати, и Солярис!

[unbe.livejournal.com]

а еще раздражает self и __такие__ методы

[ob3r0n.livejournal.com]

как-то методы надо отделять друг от друга. и хорошо что они отделяются графически (символьно), а уже использовать для этого знаки подчеркивания или что-то другое - тут на вкус и цвет

[avnik.livejournal.com]

Ну из них все кроме __init__ означают перегрузку оператора, или перехват какой-то сткандартной операции. И хорошо что всякая черная магия выделена синтаксически.

А self всего лишь соглашение о именовании, также как для классметодов принято писать cls.

[obiwanus.livejournal.com]

self чем хуже чем this? :)
а меня после питона стало раздражать { }

[avnik.livejournal.com]

f=open('spam')
f.write('eggs\n')
f.close()
Вполне себе есть.

open (он же file) правильнее рассматривать как конструктор, а не как функцию.

PS Кстати %s может быть и %(key)s -- тогда правый аргумент % трактуется как dict

[unbe.livejournal.com]

конструктор - это, например, в ruby, а здесь натурально built-in function. Вместе с другими built-in functions типа len() вызывает некоторое недоумение.

[http://users.livejournal.com/_nik_/]

А можно подробнее про фигню с юникодом? Файл начинается ли с чего-либо вроде следующего:
#!/usr/bin/env python2.5
# -*- coding: utf-8 -*-

?

[avva.livejournal.com]

это ничего не дает, кроме того, что можно literals внутри исходников на utf-8 писать. Конкретно, добавьте к вашим двум строчкам

a = u"не работает"
print a

UnicodeEncodeError: 'latin-1' codec can't encode characters in position 0-4: ordinal not in range(256)

[ob3r0n.livejournal.com]

это означает лишь то, что все нелатинские буквы будут трактоваться в кодировке utf8

[amarao-san.livejournal.com]

Самое интересное там начинается в районе функционального программирования. Итератор, возвращающий функции - это же круто!

[ob3r0n.livejournal.com]

а замыкания и декораторы - вообще верх совершенства )

[migmit.vox.com (from livejournal.com)]

А там есть функциональное программирование??? Он же даже хвостовую рекурсию, вроде, до сих пор не умеет.

[ob3r0n.livejournal.com]

кто сказал что можно сделать одним возможным способом?

oberon@darkstar:~/Загрузки$ python
Python 2.4.6 (#2, Feb 17 2009, 20:01:48) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import this
The Zen of Python, by Tim Peters

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

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

print как раз адекватно работает.

другое дело, что люди не отличают unicode и utf8

надо просто уметь общаться с encode() decode() и люди к вам потянутся.

это как раз культуру прививает ;)

кстати в python3000 вроде изначально все в юникоде и это кажется еще лучше.

[alexeybobkov]

К significant whitespace привыкаешь очень быстро, и к {} обратно не тянет

Но в Хаскеле ещё лучше :)

[nine_k]

У Хаскеля порог вхождения много выше.
Питон всё же разрабатывался изначально как язык для обучения. (И до сих пор отлично подходит.)

[nec-p1us-u1tra.livejournal.com]

Мой первый большой бумц в питоне случился с достаточно простым объектом -- списком списков. Оказывается присваивание в питоне это shallow copy 8( полдня ловил этот прикол.

[nine_k]

Есть ещё классический прикол, когда значением параметра по умолчанию делается mutable объект: он же между вызовами сохраняется!

>>> def foo(p, x={}):
...   x[p]="used up"
...   return x
... 
>>> foo(1)
{1: 'used up'}
>>> foo(2)
{1: 'used up', 2: 'used up'}
>>> _

Не программисткое

[nechaman]

"есть встроенная функция open(), а встроенной функции close() "
Когда подумаешь о всем нашем мире, то наверное такое и неплохо.

[kzn.livejournal.com]

Знаю, наверное глупо спрашивать, но
1. локаль стоит?
2. случайно ли не ipython -- у него есть некоторые проблемы с юникодом.


Вообще, язык очень приятный. Как многие замечали, в чем-то похож на lisp.
И что хорошо -- есть куча различных библиотек + высокие возможности интеграции с C и C++ -- тот же boost.python.

[pesec.livejournal.com]

А ещё, а ещё -- в нём есть Глобальный Лок, и один инстанс питона не может кушать больше 100% одного процессора.

[eterevsky.livejournal.com]

Над этим работают (http://code.google.com/p/unladen-swallow/).

[bolk.livejournal.com]

Про продуманность, это байка. В интернетах можно найти статьи с критикой, там можно увидеть сколько непродуманных мест в языке, причём в Python3 мало что изменится.

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

Кстати, встроенный close и не нужен. Достаточно удалить объект.

[http://users.livejournal.com/_nik_/]

> причём в Python3 мало что изменится.

А почему в будущем времени? python 3 давно уже вышел, готовится к выпуску 3.1…

Stackless и Nagare

[hml.livejournal.com]

Кстати, очень советую обратить внимание на Stackless Python и построенный на его основе фреймворк Nagare (http://www.nagare.org). Если кратко, то в stackless добавляются легковесные нити и продолжения, а Nagare очень органично использует их для сохранения/восстановления состояния web-приложения, так что логика программирования для web становится абсолютно такой же, как и для обычного приложения.
А как там можно генерировать html! Например:

with h.table(border=1):
with h.tr:
with h.td:
h<<u"Cell1" with h.td: h<<u"Cell2" with h.tr: with h.td: h<<h.a("Link1").action(lambda: self.some_func("l1")) with h.td: h<<h.a("Link2").action(self.some_func2)

Re: Stackless и Nagare

[hml.livejournal.com]

упс, форматирование съелось

[eterevsky.livejournal.com]

Непонимание юникода меня тоже очень раздражает. Вроде бы, это исправили в Python 3.

[yuripats.livejournal.com]

Питон.