программистское, 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, например, для сетевых вызовов.
Портировать этот зоопарк, например, на солярис - это сплошные танцы с бубнами.

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

[unbe.livejournal.com]

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

[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)

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

Эм...

[2:20 /tmp]$ cat >test.py
#!/usr/bin/env python2.5
# -*- coding: utf-8 -*-
a = u"не работает"
print a
[2:21 /tmp]$ ./test.py
не работает

А питона версия какая? А с локалью всё хорошо?

[avva.livejournal.com]

Гм, действительно видимо что-то с локалью. Думал, что дело в версии, но на другой машине, где правильно проставлена локаль, и 2.4 и 2.5 работают.

Я с этим столкнулся, когда писал скрипт для AppEngine, где я локаль, соответственно, не контролирую никак. Но возможно меня проглючило и там тоже все заработает, надо проверить.

[amarao-san.livejournal.com]

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

[nine_k]

никто не мешает и тут напрямую вызывать конструктор: f = file("spam").
(но в 3.0 тип file выкинули, заменив на ряд более подробных типов из модуля io, так что open() ещё и разбирается, какой конструктор вызвать.)

[amarao-san.livejournal.com]

Хе. Питон хитрее. Это функции из модуля __builtin__.

len=dir
len(len)

хехехехе.

[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 вроде изначально все в юникоде и это кажется еще лучше.

[ob3r0n.livejournal.com]

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

[ob3r0n.livejournal.com]

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

[ob3r0n.livejournal.com]

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

[ob3r0n.livejournal.com]

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

[xxqs.livejournal.com]

я вполне рад, что для решаемых мною задач перл подходит в 99% случаев :)

[ob3r0n.livejournal.com]

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

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

Спасибо за информацию. Мне следовало догадаться, что "SyntaxError: Non-ASCII character" это вряд ли "print не умеет выводить ничего, кроме байтов".

[ezhik-israely.livejournal.com]

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

[ob3r0n.livejournal.com]

а это просто говорит о кривых руках и неправильно настроенной локали.

[alexeybobkov]

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

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

[amarao-san.livejournal.com]

замыкания в питоне? Они есть?

(И что есть декораторы?)

[nec-p1us-u1tra.livejournal.com]

Замыкания прекрасно есть в перле.

[xxqs.livejournal.com]

дело же не в языке, а в наборе библиотек. Multithreading, например, сделан сильно по-разному в разных интерпретаторах (perl, python, jvm).

спать пора, что-то пока не придумывается ещё различий, где перл сильно более другой :)