Mail.ru Group corporate blog
Python
Programming
Comments 37
+9
Посты Армина — как горькая пилюля, которую надо выпить, чтобы стало лучше :-)

Я угадал его до первого предложения, по названию.
+3
+1 :)

Воообще, в переводах наверное было бы хорошо в заголовке явно автора указывать.
+3
Согласен, возможность совместного запуска нескольких независимых интерпретаторов (как в JavaScript и в Lua) была бы кстати. Есть мнение, что замена счётчика ссылок на сборщик мусора тоже пошла бы на пользу. Согласен, что в питоне некоторые вещи избыточно и преждевременно оптимизированы. На вопрос из заголовка статьи я бы ответил, что хочу видеть Lua с таким же большим количеством библиотек, как у питона.
+2
Неоднократно находил высказывания о модном переходе на Go. Только вот, как по мне, Go не так выразителен и удобен. И дело не только в огромных запасах батареек у питона, но и в самом языке.
Написав на Go несколько программ меня не покидало чувство какой-то ограниченности что-ли.

Буду рад услышать от «перешедших» success story.
0
Но при написании проектов в команде разве вы не вводите какие-то искусственные ограничения, чтобы выдержать весь код в одном стиле? Искусственные, а тем более явные ограничения позволяют более точно анализировать (в т.ч. автоматически) поведение программы.
0
Единственное разумное ограничение на стиль кода в python — это PEP8. И ему должны следовать без исключения все python программисты. Не важно в команде они пишут или ведут свой проект.
0
Say hello to Ralph Waldo Emerson: «A Foolish Consistency is the Hobgoblin of Little Minds».

Say hello to Twisted.

Say hello to Google, которые, насколько я знаю, раньше частенько применяли два пробела в качестве отступов и CamelCase в названиях функций (не смог найти подтверждения в их сегодняшнем code style guide).

Но в целом да, я согласен с мыслью, что PEP8 должен стать библией для начинающих программистов, и за несоблюдение PEP8 их нужно безжалостно гонять по кругу ссаными тряпками до тех пор, пока не научаться писать красивый код.
0
только хочется уточнить:
PEP8 разрешает ТАБЫ!!! Он не разрешает их смешивать с пробелами для отступов. А то постоянно слышу мнение что по PEP8 табы запрещены…
0
http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces:
Spaces are the preferred indentation method.

Tabs should be used solely to remain consistent with code that is already indented with tabs.

Так-то, по большому счёту, PEP8 всё, что угодно разрешает:
Many projects have their own coding style guidelines. In the event of any conflicts, such project-specific guides take precedence for that project.

Это ведь просто набор рекомендаций, не более того.
0
К сожалению многие воспринимают написанное скорее как закон…
0
Когда человек особо не понимает, что написано да и сам читал в лучшем случае перепечатки то ничего хорошего. (увы натыкался на таких, и цитаты из PEP8 часто не помогали :( )
-1
Начал писать на python -> перешел с табов на пробелы -> понял их преимущество
0
Единый стиль кода эта такая вещь, которая и вопросов вызывать не должна.

Я скорее имел в виду комплексные ограничения. Например, использование только делегатов или только коллбэков. Или вообще используем обмен сообщениями через какие-нибудь inter-thread сокеты ZeroMQ.
К сожалению Python очень непостоянный в этом плане язык. Ситуация, конечно, меняется от версии к версии, но разрыв шаблона при работе с разными встроенными библиотеками периодически происходит.

Лично я в первую очередь бы хотел видеть постоянство на протяжении языка и всей стандартной и де-факто стандартных библиотек. Вопросы производительности, безусловно важные, но не критичные для Python, языка, который более всего подходит для связывания различных компонент, описания логики взаимодействия.
+8
Ну… мода вообще плохой показатель. И какая-нибудь Node.js тому подтверждение.
+2
Без этой самой «моды» никуда не денешься со стадии «ранние адепты». К тому же на nodejs мало кто переходил с других языков, в основном client-side разработчики ломанулись писать серверный код (но не будем о грустном), и в этом заключается секрет популярности ноды.
0
Да, согласен, но только «ранний адепт» готов набивать шишки на новой технологии, и это его выбор, что подходит далеко не всем.
+1
Все-таки главное преимущество Lua — это его минималистичность (как в языке, так и в размере интерпретатора). Не уверен, что если под него появятся мега-библиотеки, это сильно пойдет ему на пользу. В принципе, под Lua есть хороший репозиторий LuaRocks, но многие либы нельзя запускать в силу ограничений целевой платформы (например, реализация сокетов). + модель сопрограмм такова, что языку будет трудно стать языком широкого профиля, хотя для embedded такая схема — как раз то, что надо.
+2
А каких именно библиотек вам не хватает? :)

P.S.: Присоединюсь к комментарию о том, что ценность Lua именно в минималистичности.
Как сказал один мой очень хороший знакомый, Matthew Wild, который является членом совета XSF:
Python trying to give you as much as possible.
Lua — as less as possible.

При этом для Lua (и тем паче для LuaJIT) можно реализовать абсолютно любую библиотеку, выполняющую абсолютно любую функцию (например, моя реализация crypt($5$) (с SHA256) на «Pure Lua» работала быстрее (!!!) реализации Ульриха Дреппера (автора glibc) на C из описания работы функции.

Хотя я подобного, например, не ожидал, ибо это нонсенс, чтобы интерпретируемый код работал с большей производительностью, чем скомпилированный и оптимизированный.
Но, вот так вот.
(замерял на 15 проходах по тысяче и по 5 тысяч паролей).
+1
Очень хотелось бы изучить эти более низкоуровневые особенности языка Python. Поделитесь хорошими источниками. Спасибо.
0
Практически всё, что я встречал было на английском языке, без него никуда.

Во-первых, исходники Python, конечно же (ссылка выше).

Во-вторых, статьи из различных источников, навскидку вспомнил блог Laurent Luce (посты старые, но интересные):
Python threads synchronization: Locks, RLocks, Semaphores, Conditions, Events and Queues
Python list implementation
Python string objects implementation
Python dictionary implementation
Но их много разных, можно просто поискать в интернете.

В-третьих, различные доклады с конференций (PyCon, EuroPython) тоже интересно посмотреть-послушать, но выборочно.
+1
Простите за невежество и не кидайтесь камнями, но может все-таки кто на пальцах объяснить, что есть эти слоты?
+3
В статье речь идёт о внутренних слотах, которые находятся в «кишках» интерпретатора и являются особенностью конкретной реализации CPython, а не о __slots__.
Я говорю не о конструкции __slots__, я имею в виду слоты внутреннего типа для специальных методов.

0
я думал, что у этих мехнизмов, ноги из одного места растут. И для того что бы не посылать сразу на git товарища. Решил дать ссылку с более понятным описанием
+1
Пытался рассказать своими словами, получилось не очень, поэтому пошёл и нашёл неплохое объяснение:

Внутренние типы в Python, будучи написанными на C, представляют собой огромную структуру с большим количеством ссылок на функции, реализующие базовые операции: работу с памятью для этих объектов, получение и установку аттрибутов, сравнение и т.д. Многие (но не все) из этих методов пробрасываются на уровень Python (например, метод __repr__), однако сишный код вызывает эти внутренние функции напрямую через указатели (например, функция type->tp_repr), и такие вызовы не попадают на уровень Python и не обрабатываются механизмом поиска методов Python.

Так вот, CPython, регистрируя новый внутренний тип, автоматически создаёт словарь, в который складывает названия для всех специальных («магических») методов и слоты с соответствующими функциями в сишном коде. Поэтому мы, собственно, и можем вызывать эти функции (get, __init__ и другие прочие) для встроенных типов. Ключи этого словаря не могут указывать напрямую на указатели на сишные функции, вместо этого они указывают на специальные объекты (слоты), которые, собственно, и реализуют всю работу по вызову соответствующих сишных функций из Python.
+1
Я слышал версию, что слоты были внедрены для уменьшения количества используемой объектом памяти. По умолчанию для поиска полей/методов в объекте используется стандартный __dict__ это быстро, но это сколько индекс, по этому сколько то памяти даже(100-1000 байт, не помню точную цифру). В случае __slots__ поиск идет по массиву по очереди, по этому меньше памяти но и медленный поиск
+1
По-моему, слоты нужны, чтобы не искать магические методы по цепочке наследования. Иными словами, мы сплющиваем все магические методы из всей иерархии в одну мапу, по которой поиск константный (и не зависит от длины цепочки наследования).
0
Да, и я где то читал, что это для уменьшения фрагментации памяти. На самом деле Python достаточно скромный по памяти в отличии от JS (c JIT) и Java.
0
Не очень понимаю трагедию:
Обычно делают так: сначала dict__getitem__ просто парсит аргументы, а затем происходит вызов dict_do_getitem с актуальными параметрами. Видите, что происходит? dict__getitem__ и dict_get обе вызывают dict_get, которая является внутренней статической функцией, и вы не можете ничего с этим поделать.


или перевод страдает или я туплю.

Оригинал:
A Python method in C is just a C function with a specific signature. That is the first problem. That function's first purpose is to handle the Python level parameters and convert them into something you can use on the C layer. At the very least you need to pull the individual arguments from a Python tuple or dict (args and kwargs) into local variables. So a common pattern is that dict__getitem__ internally does just the argument parsing and then calls into something like dict_do_getitem with the actual parameters. You can see where this is going. dict__getitem__ and dict_get both would call into dict_get which is an internal static function. You cannot override that.


Кажется тут говорится немного о другом… но всё равно не понимаю. Ему не нравится, что приходится предварительно парсить аргументы для dict_do_getitem?
Only those users with full accounts are able to leave comments.  , please.