Comments 37
Народ, кто ещё угадал Армина после первого же предложения?
Согласен, возможность совместного запуска нескольких независимых интерпретаторов (как в JavaScript и в Lua) была бы кстати. Есть мнение, что замена счётчика ссылок на сборщик мусора тоже пошла бы на пользу. Согласен, что в питоне некоторые вещи избыточно и преждевременно оптимизированы. На вопрос из заголовка статьи я бы ответил, что хочу видеть Lua с таким же большим количеством библиотек, как у питона.
Нынче модно стало переходить с Python на Go.
Неоднократно находил высказывания о модном переходе на Go. Только вот, как по мне, Go не так выразителен и удобен. И дело не только в огромных запасах батареек у питона, но и в самом языке.
Написав на Go несколько программ меня не покидало чувство какой-то ограниченности что-ли.
Буду рад услышать от «перешедших» success story.
Написав на Go несколько программ меня не покидало чувство какой-то ограниченности что-ли.
Буду рад услышать от «перешедших» success story.
Из недавнего: tech.dropbox.com/2014/07/open-sourcing-our-go-libraries/
Но при написании проектов в команде разве вы не вводите какие-то искусственные ограничения, чтобы выдержать весь код в одном стиле? Искусственные, а тем более явные ограничения позволяют более точно анализировать (в т.ч. автоматически) поведение программы.
Единственное разумное ограничение на стиль кода в python — это PEP8. И ему должны следовать без исключения все python программисты. Не важно в команде они пишут или ведут свой проект.
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 их нужно безжалостно гонять по кругу ссаными тряпками до тех пор, пока не научаться писать красивый код.
Say hello to Twisted.
Say hello to Google, которые, насколько я знаю, раньше частенько применяли два пробела в качестве отступов и CamelCase в названиях функций (не смог найти подтверждения в их сегодняшнем code style guide).
Но в целом да, я согласен с мыслью, что PEP8 должен стать библией для начинающих программистов, и за несоблюдение PEP8 их нужно безжалостно гонять по кругу ссаными тряпками до тех пор, пока не научаться писать красивый код.
только хочется уточнить:
PEP8 разрешает ТАБЫ!!! Он не разрешает их смешивать с пробелами для отступов. А то постоянно слышу мнение что по PEP8 табы запрещены…
PEP8 разрешает ТАБЫ!!! Он не разрешает их смешивать с пробелами для отступов. А то постоянно слышу мнение что по PEP8 табы запрещены…
http://legacy.python.org/dev/peps/pep-0008/#tabs-or-spaces:
Так-то, по большому счёту, PEP8 всё, что угодно разрешает:
Это ведь просто набор рекомендаций, не более того.
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.
Это ведь просто набор рекомендаций, не более того.
Единый стиль кода эта такая вещь, которая и вопросов вызывать не должна.
Я скорее имел в виду комплексные ограничения. Например, использование только делегатов или только коллбэков. Или вообще используем обмен сообщениями через какие-нибудь inter-thread сокеты ZeroMQ.
К сожалению Python очень непостоянный в этом плане язык. Ситуация, конечно, меняется от версии к версии, но разрыв шаблона при работе с разными встроенными библиотеками периодически происходит.
Лично я в первую очередь бы хотел видеть постоянство на протяжении языка и всей стандартной и де-факто стандартных библиотек. Вопросы производительности, безусловно важные, но не критичные для Python, языка, который более всего подходит для связывания различных компонент, описания логики взаимодействия.
Я скорее имел в виду комплексные ограничения. Например, использование только делегатов или только коллбэков. Или вообще используем обмен сообщениями через какие-нибудь inter-thread сокеты ZeroMQ.
К сожалению Python очень непостоянный в этом плане язык. Ситуация, конечно, меняется от версии к версии, но разрыв шаблона при работе с разными встроенными библиотеками периодически происходит.
Лично я в первую очередь бы хотел видеть постоянство на протяжении языка и всей стандартной и де-факто стандартных библиотек. Вопросы производительности, безусловно важные, но не критичные для Python, языка, который более всего подходит для связывания различных компонент, описания логики взаимодействия.
Ну… мода вообще плохой показатель. И какая-нибудь Node.js тому подтверждение.
Все-таки главное преимущество Lua — это его минималистичность (как в языке, так и в размере интерпретатора). Не уверен, что если под него появятся мега-библиотеки, это сильно пойдет ему на пользу. В принципе, под Lua есть хороший репозиторий LuaRocks, но многие либы нельзя запускать в силу ограничений целевой платформы (например, реализация сокетов). + модель сопрограмм такова, что языку будет трудно стать языком широкого профиля, хотя для embedded такая схема — как раз то, что надо.
А каких именно библиотек вам не хватает? :)
P.S.: Присоединюсь к комментарию о том, что ценность Lua именно в минималистичности.
Как сказал один мой очень хороший знакомый, Matthew Wild, который является членом совета XSF:
При этом для Lua (и тем паче для LuaJIT) можно реализовать абсолютно любую библиотеку, выполняющую абсолютно любую функцию (например, моя реализация crypt($5$) (с SHA256) на «Pure Lua» работала быстрее (!!!) реализации Ульриха Дреппера (автора glibc) на C из описания работы функции.
Хотя я подобного, например, не ожидал, ибо это нонсенс, чтобы интерпретируемый код работал с большей производительностью, чем скомпилированный и оптимизированный.
Но, вот так вот.
(замерял на 15 проходах по тысяче и по 5 тысяч паролей).
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 тысяч паролей).
Очень хотелось бы изучить эти более низкоуровневые особенности языка Python. Поделитесь хорошими источниками. Спасибо.
Был небольшой цикл статей на хабре:
habrahabr.ru/company/buruki/blog/189972/
Хотя товарищ hellman правильно вас отправил.
habrahabr.ru/company/buruki/blog/189972/
Хотя товарищ hellman правильно вас отправил.
Практически всё, что я встречал было на английском языке, без него никуда.
Во-первых, исходники 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) тоже интересно посмотреть-послушать, но выборочно.
Во-первых, исходники 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) тоже интересно посмотреть-послушать, но выборочно.
Простите за невежество и не кидайтесь камнями, но может все-таки кто на пальцах объяснить, что есть эти слоты?
stackoverflow.com/questions/472000/python-slots
Грубо, новый механизм поиска атрибутов объекта по списку вместо словаря.
Грубо, новый механизм поиска атрибутов объекта по списку вместо словаря.
В статье речь идёт о внутренних слотах, которые находятся в «кишках» интерпретатора и являются особенностью конкретной реализации CPython, а не о
__slots__.Я говорю не о конструкции __slots__, я имею в виду слоты внутреннего типа для специальных методов.
я думал, что у этих мехнизмов, ноги из одного места растут. И для того что бы не посылать сразу на git товарища. Решил дать ссылку с более понятным описанием
Пытался рассказать своими словами, получилось не очень, поэтому пошёл и нашёл неплохое объяснение:
Внутренние типы в Python, будучи написанными на C, представляют собой огромную структуру с большим количеством ссылок на функции, реализующие базовые операции: работу с памятью для этих объектов, получение и установку аттрибутов, сравнение и т.д. Многие (но не все) из этих методов пробрасываются на уровень Python (например, метод __repr__), однако сишный код вызывает эти внутренние функции напрямую через указатели (например, функция type->tp_repr), и такие вызовы не попадают на уровень Python и не обрабатываются механизмом поиска методов Python.
Так вот, CPython, регистрируя новый внутренний тип, автоматически создаёт словарь, в который складывает названия для всех специальных («магических») методов и слоты с соответствующими функциями в сишном коде. Поэтому мы, собственно, и можем вызывать эти функции (get, __init__ и другие прочие) для встроенных типов. Ключи этого словаря не могут указывать напрямую на указатели на сишные функции, вместо этого они указывают на специальные объекты (слоты), которые, собственно, и реализуют всю работу по вызову соответствующих сишных функций из Python.
Я слышал версию, что слоты были внедрены для уменьшения количества используемой объектом памяти. По умолчанию для поиска полей/методов в объекте используется стандартный __dict__ это быстро, но это сколько индекс, по этому сколько то памяти даже(100-1000 байт, не помню точную цифру). В случае __slots__ поиск идет по массиву по очереди, по этому меньше памяти но и медленный поиск
По-моему, слоты нужны, чтобы не искать магические методы по цепочке наследования. Иными словами, мы сплющиваем все магические методы из всей иерархии в одну мапу, по которой поиск константный (и не зависит от длины цепочки наследования).
Да, и я где то читал, что это для уменьшения фрагментации памяти. На самом деле Python достаточно скромный по памяти в отличии от JS (c JIT) и Java.
Это совсем не те слоты.
Не очень понимаю трагедию:
или перевод страдает или я туплю.
Оригинал:
Кажется тут говорится немного о другом… но всё равно не понимаю. Ему не нравится, что приходится предварительно парсить аргументы для dict_do_getitem?
Обычно делают так: сначала 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?
Sign up to leave a comment.
Python, каким бы я хотел его видеть