Комментарии 192
Все хорошо, но в __getattr__(self, key) не лучше ли перехватывать исключение KeyError?
В данном варианте реализации перехватываем любое исключение, насколько я помню так делать не рекомендуется.
В данном варианте реализации перехватываем любое исключение, насколько я помню так делать не рекомендуется.
Я бы вообще не рекомендовал переобъявлять __getattr__(). Не могу представить, зачем это вообще может понадобиться.
А можно пример от несогласного? =)
А то так и не узнаю.
Едиственное, что приходит на ум:
А то так и не узнаю.
Едиственное, что приходит на ум:
class mydict(dict):
self.__getattr__(self, key):
if key=='smile':
return "Улыбнитесь, вас снимают! =)"
else:
return super(mydict, self).__getattr__(key)
Реализация сложной логики на изначально простейших членах объекта (или как они там по-питоньи). Увы и ах, но невозможность ограничить доступ к свойствам (может так?) сподвигает на временные решения типа «Пока поставим public потом напишем сеттер», а потом сеттер никто не пишет, дабы не переписывать всё приложение… (сеттеры и геттеры в данном контексте равнозначны)
Ну почему? __getattr__ может использоваться для перехвата определенных атрибутов. Класс может не иметь атрибута, но при обращении к нему атрибут может вычисляться динамически.
class Test:
def __getattr__(self,attrname):
if attrname == «blahblahblah»:
return «blahblahblah»
else:
raise AttributeError, attrname
t = Test()
print( t.blahblahblah ) #prints «blahblahblah»
class Test:
def __getattr__(self,attrname):
if attrname == «blahblahblah»:
return «blahblahblah»
else:
raise AttributeError, attrname
t = Test()
print( t.blahblahblah ) #prints «blahblahblah»
Пардон…
class Test:
def __getattr__(self,attrname):
if attrname == «blahblahblah»:
return «blahblahblah»
else:
raise AttributeError, attrname
t = Test()
print( t.blahblahblah ) #prints «blahblahblah»
</sorce>
Ну, это его каноническое (имхо) назначение в системах типа ORM. Автор имел в виду мне кажется обращение перехват обращения к реальным атрибутам
От себя пример — у вконтакта есть API, там методы называются например wall.GetPost(some_kwargs)
Я реализую библиотечку для работы с API. Как мне сделать вызов этого метода из моей библиотеки (если не реализовывать все методы самостоятельно а просто проксировать их)?
вариант 1 (без __getattr__):
и второй вариант (с __getattr__):
По сути функционал не изменился но выглядит нагляднее.
Я реализую библиотечку для работы с API. Как мне сделать вызов этого метода из моей библиотеки (если не реализовывать все методы самостоятельно а просто проксировать их)?
вариант 1 (без __getattr__):
api.call('wall.GetPost', **kwargs)и второй вариант (с __getattr__):
api.wall.GetPost(**kwargs)По сути функционал не изменился но выглядит нагляднее.
«автор читал доки по Python» и как же про filter не знать тогда? ) он веть даже не только в питоне
отступы у вас табами в примерах, не по pep-0008)
и здесь вы со своим PEP-8 =)
Заменил табы на пробелы. Правда, привык к ширине табуляции 2, вместо 4 желательных по PEP-8.
PEP-8 не требует пробелы вместо табов, перечитайте его чтобы убедиться. Но, несмотря на это, код в примерах действительно недосчитался кучи пробелов вокруг знаков равенства/неравенства.
Use 4 spaces per indentation level.
For really old code that you don't want to mess up, you can continue to
use 8-space tabs.
For new projects, spaces-only are strongly recommended over tabs.
For really old code that you don't want to mess up, you can continue to
use 8-space tabs.
For new projects, spaces-only are strongly recommended over tabs.
Ну, да, вот я и говорю не требует стандарт пробелов (всего-лишь рекомендует).
рекомендует, но весьма настоятельно (strongly)
Love and Peace!
www.ietf.org/rfc/rfc2119
www.ietf.org/rfc/rfc2119
Тут дело даже не в том, что человек пришел с С++, а в том что документация была прочтена поверхностно.
А когда люди со своими привычками в другом языке лезут в python, вот это действительно выглядит страшно. Например, видел несколько раз, как вчерашние программисты на delphi ставят в python коде в конце каждой строки точку с запятой. По синтаксису это допустимо, но это страшно…
А когда люди со своими привычками в другом языке лезут в python, вот это действительно выглядит страшно. Например, видел несколько раз, как вчерашние программисты на delphi ставят в python коде в конце каждой строки точку с запятой. По синтаксису это допустимо, но это страшно…
А эти дельфисты документацию вообще читали? Как можно такой момент упустить — ума не приложу. Даже если изучать Python по примерам, надёрганным с интернета, будет очевидно, что точка с запятой не нужна (:
Эта волшебная сила привычки… Вы не представляете, насколько на автомате оно ставится :)
Представляю.
Но тут еще дело уважения к языку.
Ведь каждый язык программирования — это свой синтаксис и своя семантика, а отсюда следуют своя терминология, свои «правильные» подходы, своя культура и т.д.
И оно отнюдь не только для того, чтобы выделиться.
Во-первых, единство стандарта позволяет всем писать более-менее одинаково (с точки зрения форматирования и использования конструкций языка для каких-либо простых задач типа сортировки).
Во-вторых, этот единый стиль не взялся с потолка, а длительное время шлифовался профессионалами, специализирующимися на данном языке программирования. Следовательно, большинство вопросов «против», которые вы можете придумать, исходя из того, «как оно сделано в таком-то моем любимом языке программирования», окажутся либо уже давно решенными, либо противоречащими культуре языка (хотя, может быть, работать оно будет корректно).
Можно привести множество примеров, но как Java-программист замечу: в Java до сих пор нет замыканий )
Но тут еще дело уважения к языку.
Ведь каждый язык программирования — это свой синтаксис и своя семантика, а отсюда следуют своя терминология, свои «правильные» подходы, своя культура и т.д.
И оно отнюдь не только для того, чтобы выделиться.
Во-первых, единство стандарта позволяет всем писать более-менее одинаково (с точки зрения форматирования и использования конструкций языка для каких-либо простых задач типа сортировки).
Во-вторых, этот единый стиль не взялся с потолка, а длительное время шлифовался профессионалами, специализирующимися на данном языке программирования. Следовательно, большинство вопросов «против», которые вы можете придумать, исходя из того, «как оно сделано в таком-то моем любимом языке программирования», окажутся либо уже давно решенными, либо противоречащими культуре языка (хотя, может быть, работать оно будет корректно).
Можно привести множество примеров, но как Java-программист замечу: в Java до сих пор нет замыканий )
Действительно, не представляю. Я пишу, в основном, на C++, но при написании скриптов на Python очень редко возникает желание поставить точку с запятой или скобку после if. С привычкой нужно бороться, так как в каждом языке — своя культура оформления кода.
не нужна и мешает — это две большие разницы. Коду на многих языках; между операторами/строками не мешает, но в некоторых одинакова… Вам жалко, что кто напишет в коде что-то что коду не мешает, а мешает лишь вашим привычкам?
Результат проверки: не питонист.
Даже не пртендовал, так что минус уберите :)
На самом деле пытаюсь понять в чём python «круче» php для веб-приложений, но не получается. Все (на хабре) твердят, что круче, а на практике на django гугл рассылке мну далеко послали… я Понимаю, что gae и php вещи несовместимые (это ж не за кофем ходить), но была бы там минимальная поддержка пхп я б за 10 (ну, может 11) дней написал фреймворк свой (или портировал бы симфони) с учетом их бигтабле и т.п. а из джанги послали, типа нефиг кроссплатформенный фреймворк пытаться запустить на питоновской платформе… пытался примкнуть к опенсорцу фреймворку чисто для гае — тоже послали, типа нефиг идеи рельс на питон тащить, хотя рельс не видел и не слышал, а исходил из впечатлений от php фреймворков… как тут можно быть питонистом? Я ж даже патчи не предлагал со своими asm-c-php-style'ом, а спрашивал «как», «стоит ли так»… :(
На самом деле пытаюсь понять в чём python «круче» php для веб-приложений, но не получается. Все (на хабре) твердят, что круче, а на практике на django гугл рассылке мну далеко послали… я Понимаю, что gae и php вещи несовместимые (это ж не за кофем ходить), но была бы там минимальная поддержка пхп я б за 10 (ну, может 11) дней написал фреймворк свой (или портировал бы симфони) с учетом их бигтабле и т.п. а из джанги послали, типа нефиг кроссплатформенный фреймворк пытаться запустить на питоновской платформе… пытался примкнуть к опенсорцу фреймворку чисто для гае — тоже послали, типа нефиг идеи рельс на питон тащить, хотя рельс не видел и не слышал, а исходил из впечатлений от php фреймворков… как тут можно быть питонистом? Я ж даже патчи не предлагал со своими asm-c-php-style'ом, а спрашивал «как», «стоит ли так»… :(
В больших сообществах такое случается — идите к нам в Common Lisp — там все дружелюбно и компетентно
Да не пытаетесь вы. Вы берете свои привычки из PHP и тянете их в Python, с минимальной адаптацией, без разбора, что языки разные, очень разные. С точно таким же успехом вы будете писать на LISP как на PHP. Так с чего бы ощутить разницу? Вы пишете все также на PHP, просто вминаете свой PHP в чужеродные конструкции. Так только батхерт можно ощутить, а не преимущества.
Вам надо переключиться, и врубиться — это не PHP, не JAVA и не С. Это Python/Ruby/PREL/LISP/Erlang/Ocaml/_нужное вписать_. Выкиньте свои привычки, и научитесь новому языку.
Это не означает, что при написании программ на императивном python вам нельзя использовать немного функционального стиля. Тот же sum() восхитителен. Но если вы начнете писать на LISP в python, вы получите говнокод.
Вам надо переключиться, и врубиться — это не PHP, не JAVA и не С. Это Python/Ruby/PREL/LISP/Erlang/Ocaml/_нужное вписать_. Выкиньте свои привычки, и научитесь новому языку.
Это не означает, что при написании программ на императивном python вам нельзя использовать немного функционального стиля. Тот же sum() восхитителен. Но если вы начнете писать на LISP в python, вы получите говнокод.
Какие могут быть привычки, которые надо выкидывать? Вот сижу уже минут 10 и думаю, что из моих привычек относится к PHP, а что к программированию/проектированию ПО вообще, в какой момент я начинаю думать категориями языка, а не абстрактных классов/объектов со свойствами/методами. В голову пришло только, что, может быть, не стоит использовать множественное наследование от абстрактных классов для реализации привычных интерфейсов, а держать эти интерфейсы в голове, надеясь, что не забудешь определить какой-то метод.
Мне выискивать и цитировать все, немного лень. Ну например вас огорчает отсутствие public и private, и вот вы уже хотите использовать всю мощь языка и перекрыть доступ к атрибутам при помощи тяжелой магии. В python так не делают.
Потом у вас странная цель сразу написать свой фреймворк, зачем? Изучите вначале хотя бы один, чтобы вообще почувствовать, как это работает в python.
В общем один из возможных стартов, прочесть и выполнить упражнения к django, те, что на официальном сайте.
Потом у вас странная цель сразу написать свой фреймворк, зачем? Изучите вначале хотя бы один, чтобы вообще почувствовать, как это работает в python.
В общем один из возможных стартов, прочесть и выполнить упражнения к django, те, что на официальном сайте.
Цель была скорее не написать свой фреймворк, а написать полноценное приложение с нуля, без использования компонентов не входящих в стандартную библиотеку. Когда понял, что начинать нужно чуть ли не с написания своего веб-сервера, пришёл к выводу, что надо писать фреймворк или придётся копипастить 90% кода в следующее приложение. В принципе можно это назвать изучением языка «снизу вверх», сначала реализовать самому, чтобы понять как работает, а потом смотреть готовые решения, чтобы понять плюсы и минусы своего и либо допилить его до ума, чтобы было «не хуже как у людей», либо стереть, чтобы случайно не опозориться :) Как-то жизнь научила, что такой способ изучения языка позволяет лучше оценивать плюсы и минусы решений (как своих, так и чужих), чем замена «бизнес-логики» в чужом коде относясь к «инфраструктуре» как к чёрному ящику.
self.maluke.com/webdev например. Гуглится легко, было бы желание.
Еще я вам кратко ответил, надо разъяснить — понятный код в Python это принцип! Это заповедь программиста.
Но ведь писать понятный код надо начиная с момента, когда количество участников разработки переваливает за ноль, и стремительно приближается к единице.
Так вот лишние элементы, не несущие смысловой нагрузки, никак не улучшают восприятие. Когда я смотрю на разряженный код C/C++/Java, я отчетливо ощущаю раздражение от совершенно ненужных {};, за которыми еще и следить приходится.
Но ведь писать понятный код надо начиная с момента, когда количество участников разработки переваливает за ноль, и стремительно приближается к единице.
Так вот лишние элементы, не несущие смысловой нагрузки, никак не улучшают восприятие. Когда я смотрю на разряженный код C/C++/Java, я отчетливо ощущаю раздражение от совершенно ненужных {};, за которыми еще и следить приходится.
Тем не менее, точки с запятой желательны после pass и break.
Не так страшны вчерашние программисты на дельфи, как они же, пишущие код для введения в заблуждение вероятного противника:
Не так страшны вчерашние программисты на дельфи, как они же, пишущие код для введения в заблуждение вероятного противника:
for i in range(100): a += 1; b += a;>Плоское лучше, чем вложенное
Этот совет не является питон-специфичным и может быть применён в любом другом языке.
Этот совет не является питон-специфичным и может быть применён в любом другом языке.
Тем не менее, часто натыкаюсь на
def getUserData(user):
if user.authorized:
user.doAnything()
# еще куча кода
else:
raise UserError('Not authorized')
Тут уместно вспомнить про «Совершенный код», да.
Спасибо за статью! Немного от себя:
А зачем вообще такое может понадобится? Переделывать синтаксис одного языка под другой? Я понимаю, что кому-то, может быть, так и привычно, но явно не большинству… Да и способ не тот: return self.key естественно не поможет, возможно, скорее что-то вроде return self.__dict__[key].
А в последнем случае можно также использовать списковые включения, так даже более понятно:
На просторах интернета обнаружил «полезнейший» совет: чтобы обращаться к элементам словаря, как к атрибутам класса, то есть, в стиле JS (myobject.myelement), можно воспользоваться таким приемом
А зачем вообще такое может понадобится? Переделывать синтаксис одного языка под другой? Я понимаю, что кому-то, может быть, так и привычно, но явно не большинству… Да и способ не тот: return self.key естественно не поможет, возможно, скорее что-то вроде return self.__dict__[key].
А в последнем случае можно также использовать списковые включения, так даже более понятно:
b = [x for x in a if x >=5]
Я тоже не очень понял, в чем плюсы. мало того, что невозможно сделать что-то вроде a[«key_»+s], так еще возникают трудности с обращением к атрибутам.
Списковые выражения сам с удовольствием использую. Единственное: надо засмечать случаи, когда условие становится чересчур раздутым и лучше уже сделать другим, более очевидным способом.
Списковые выражения сам с удовольствием использую. Единственное: надо засмечать случаи, когда условие становится чересчур раздутым и лучше уже сделать другим, более очевидным способом.
Реализацию мимикрии словаря под объект предлагаю не обсуждать, она конечно хромая.
Но сама возможность такой работы со словарем, бывает удобной.
Например я вижу работу с современными NoSQL БД именно через словари, а не через прибитые гвоздями модели. Но доступ к элементам словаря стандартными языковыми средствами просто ужасен. Если у вас в коде таких обращений будет много, на него будет страшно смотреть.
Но сама возможность такой работы со словарем, бывает удобной.
Например я вижу работу с современными NoSQL БД именно через словари, а не через прибитые гвоздями модели. Но доступ к элементам словаря стандартными языковыми средствами просто ужасен. Если у вас в коде таких обращений будет много, на него будет страшно смотреть.
Это имеет смысл только в таких вот узкоспециализированных задачах, вроде написания ОРМ. Тема мне близка, потому что я писал таким образом свой для MongoDB :)
А вообще "[]" — вполне стандартный способ, тот же в C++ работает точно так же. Но ничего не мешает даже в том же ОРМе реализовать интерфейс-объект, который будет в конструкторе из какого-нибудь JSON собирать себе поля. Для этого извращаться над самими словарями необязательно.
А вообще "[]" — вполне стандартный способ, тот же в C++ работает точно так же. Но ничего не мешает даже в том же ОРМе реализовать интерфейс-объект, который будет в конструкторе из какого-нибудь JSON собирать себе поля. Для этого извращаться над самими словарями необязательно.
Ну можете колдовать со сборкой объектов, и дальнейшей их обратной разборкой. В MongoDB словарики, не забыли? Так зачем делать двойную работу? Потому что сто пятьдесят криворучек не смогли корректно написать __getattr__?
Ну и тут вроде python обсуждается, а не c++, большая концентрация [] на строку вредна для психики.
Ну и тут вроде python обсуждается, а не c++, большая концентрация [] на строку вредна для психики.
Для работы с базой удобно использовать namedtuple. Это ещё и эффективнее.
Менять же синтаксис языка — дурной тон.
Менять же синтаксис языка — дурной тон.
Дурной тон, это путать понятия. Синтаксис языка определяет доступ к элементам объекта через точку. Мы не затрагиваем синтаксис, мы используем стандартную, и очень активно используемую, возможность языка, чтобы в рамках его синтаксиса добавить сахара к работе со словарем. И никто не сказал, что это будет простой вызов __getitem__, может там какие-то дополнительные обработки обнаружатся, проверка данных, например.
То есть реализуется некий класс, поведение которого отличается от обычного словаря, но порядок работы как со словарем нет. То есть где нужен словарь, он остается словарем. И это очень удобно, это экономит время на сборке/разборке объекта.
— namedtuple достаточно статичная вещь, а документы в MongoDB (в качестве примера) вещь изменчивая. и четкой структуры не имеющая.
То есть реализуется некий класс, поведение которого отличается от обычного словаря, но порядок работы как со словарем нет. То есть где нужен словарь, он остается словарем. И это очень удобно, это экономит время на сборке/разборке объекта.
— namedtuple достаточно статичная вещь, а документы в MongoDB (в качестве примера) вещь изменчивая. и четкой структуры не имеющая.
Если вы используете словарь, то и работайте с ним как со словарём, не путайте людей, которые позже будут разбираться в вашем коде. Мне тоже не нравиться много пунктуации: квадратных скобок и кавычек при работе со словарями, но я всё-таки до такого не дохожу.
namedtuple, конечно, более удобен при чтении строк из реляционной БД.
namedtuple, конечно, более удобен при чтении строк из реляционной БД.
В своей библиотеке я буду работать со словарем так, как мне это кажется правильным. А чтобы не путаться надо хотя бы readme читать.
Я понимаю, вам кажется, что вы тут боретесь за чистоту языка, но это не так. Никто язык не трогает. Словарь это такой же класс, как и все остальные, от него также можно унаследоваться, и переделать его поведение под себя. Если вам это кажется наглостью, то уберите из stdlib defaultdict. Он тоже трогает святое.
Я понимаю, вам кажется, что вы тут боретесь за чистоту языка, но это не так. Никто язык не трогает. Словарь это такой же класс, как и все остальные, от него также можно унаследоваться, и переделать его поведение под себя. Если вам это кажется наглостью, то уберите из stdlib defaultdict. Он тоже трогает святое.
Кстати про namedtuple:
In [6]: P.__mro__
Out[6]: (<class '__main__.P'>, <type 'tuple'>, <type 'object'>)
Сволочи, они снаследовались от кортежа! На костер.
Я кстати за костер, но по другим причинам — namedtuple это образец кривости, это непередаваемый пи. Ну что стоило принять хотя бы кортеж, а не строку?? И вот вы этим говном пользуется, а значит __getattr__ переопределить это немыслимо?
In [6]: P.__mro__
Out[6]: (<class '__main__.P'>, <type 'tuple'>, <type 'object'>)
Сволочи, они снаследовались от кортежа! На костер.
Я кстати за костер, но по другим причинам — namedtuple это образец кривости, это непередаваемый пи. Ну что стоило принять хотя бы кортеж, а не строку?? И вот вы этим говном пользуется, а значит __getattr__ переопределить это немыслимо?
Чем ужасен-то? .get(), .setdefault() — прекрасные методы, и их и надо использовать.
Без квадратных скобок все равно не обойдетесь, если ключ в переменной. Или будете из принципа использовать getattr() / setattr()?
Без квадратных скобок все равно не обойдетесь, если ключ в переменной. Или будете из принципа использовать getattr() / setattr()?
обычно когда записи читаются из базы, то ключи не а переменной, а фиксированы схемой БД. И код действительно выглядит не очень читабельно из-за обилия пунктуации
Визуально ужасен, если много. Сравниваем — Product.id vs Product['id'].
Get и setdefault отличные методы, и их тоже надо использовать, я с вами абсолютно согласен. И ни в коем случае извращаться с getattr над словарем я не собираюсь. С другой стороны, если кто-то использующий библиотеку, сунет этот класс куда-то, где дернется getattr, то все сработает как ожидалось.
Но предположим, что некто, крайне пуританских взглядов, решил не мимикрировать словарь под объект, а создать честный объект. Как он будет проходиться по атрибутам своего объекта? Через задний проход, потому что объекты не предназначены для обхода атрибутов. А с нашим словариком он просто сделает for k, v in product.items(). Это если не вспоминать о времени, затрачиваемом на сборку объекта на лету, и его разборку перед упаковкой в БД.
Итак есть два пути — заточить объект так, чтобы он мимикрировал свое поведение под словарь, или не выпендриваться, и обернуть словарь так как надо, а методы словаря, оптимизированные, написанные на C, достанутся на халяву.
Напоминаю про namedtuple, которым все пользуются, но который является точно такой же надстройкой над tuple. Ну и кто от его использования пострадал? Ну только настоящие питонисты, которых бесит передача списка полей строкой, получили психологическую травму, увидев такое в stdlib.
Get и setdefault отличные методы, и их тоже надо использовать, я с вами абсолютно согласен. И ни в коем случае извращаться с getattr над словарем я не собираюсь. С другой стороны, если кто-то использующий библиотеку, сунет этот класс куда-то, где дернется getattr, то все сработает как ожидалось.
Но предположим, что некто, крайне пуританских взглядов, решил не мимикрировать словарь под объект, а создать честный объект. Как он будет проходиться по атрибутам своего объекта? Через задний проход, потому что объекты не предназначены для обхода атрибутов. А с нашим словариком он просто сделает for k, v in product.items(). Это если не вспоминать о времени, затрачиваемом на сборку объекта на лету, и его разборку перед упаковкой в БД.
Итак есть два пути — заточить объект так, чтобы он мимикрировал свое поведение под словарь, или не выпендриваться, и обернуть словарь так как надо, а методы словаря, оптимизированные, написанные на C, достанутся на халяву.
Напоминаю про namedtuple, которым все пользуются, но который является точно такой же надстройкой над tuple. Ну и кто от его использования пострадал? Ну только настоящие питонисты, которых бесит передача списка полей строкой, получили психологическую травму, увидев такое в stdlib.
Эта статья не только полезна, но и вредна начинающим любителям питона.
Питон ломает стереотипы статических языков при работе со списками. Мне кажется упор должен быть на это. Функция filter как пример анти-питоновского подхода.
Питон ломает стереотипы статических языков при работе со списками. Мне кажется упор должен быть на это. Функция filter как пример анти-питоновского подхода.
Почему? Вполне себе нормальная функция, всякие map, reduce и иже с ними давно уже есть и в других языках, даже в том же JS, если применить underscore.js. Другое дело, что питон по умолчанию запросто представляет к любому списку интерфейс итератора и простейший синтаксис срезов, вот это большой плюс и удобство. Тот же STL в C++, насколько я знаю, пока такой простоты не позволяет.
filter нормальная функция конечно, но когда фильтрующая функция выражена x >= 5, то кажется более подходящим использовать фильтрацию генератором к примеру. Просто и наглядно. А для filter оставить более сложные фильтры.
reduce в питоне уже ппрактически нету.
filter и map заменяются list comprehension'ом, который зачастую проще выглядит из-за отсутствия лямбд.
filter и map заменяются list comprehension'ом, который зачастую проще выглядит из-за отсутствия лямбд.
Могу в качестве парирования привести старый добрый «экспертный» подход к алгоритмическому расчету факториала:
Да и вообще, это вы зря, товарищ. Очень полезная вещь в некоторых случаях :) И лямбды тут ни при чем, можно просто передать указатель на функцию, то есть ее имя. Для сложной фильтрации самое оно, как правильно заметили выше.
fact = lambda x: reduce(int.__mul__, xrange(2, x + 1), 1)Да и вообще, это вы зря, товарищ. Очень полезная вещь в некоторых случаях :) И лямбды тут ни при чем, можно просто передать указатель на функцию, то есть ее имя. Для сложной фильтрации самое оно, как правильно заметили выше.
что значит «уже»? убрали?
www.artima.com/weblogs/viewpost.jsp?thread=98196
В 3.х reduce убран из builtins в модуль itertools.
В 3.х reduce убран из builtins в модуль itertools.
Жаль :( мне так питон понравился своей реализацией reduce/// имхо красивше чем в php///
изучение слепой печати на двух раскладках сразу даёт о себе знать
Почти что угодно почти где угодно красивее чем в PHP, это вообще отдельный вопрос.
просто это чуть ли не единственный плюс питона, который я заметил при попытке с перехода на не го с php скобочки и $ за качественный плюс, имхо, считать нельзя
теперь я не смогу убедить даже своих «соратников», не то что заказчиков, что мытуфтой маемся моглибы реализовать проекты быстрее.
теперь я не смогу убедить даже своих «соратников», не то что заказчиков, что мы
При переходе к другой парадигме нужно менять мышление. Иного способа быстро и надежно использовать новый инструмент просто не существует.
Пример из жизни: насколько быстро человек освоит IDE, если до этого он писал программки в блокноте и собирал из командной строки? Естественно, в первое время ему это будет казаться магией, и захочется продолжать работать с командной строкой, потому что «понятно, как оно работает». Просто сила привычки и недоверие ко всему новому.
Пример из жизни: насколько быстро человек освоит IDE, если до этого он писал программки в блокноте и собирал из командной строки? Естественно, в первое время ему это будет казаться магией, и захочется продолжать работать с командной строкой, потому что «понятно, как оно работает». Просто сила привычки и недоверие ко всему новому.
Так а в чем проблема?
и можно писать как раньше
from itertools import reduceи можно писать как раньше
1. Зачем вообще обращаться к элементам словаря как к атрибутам класса?
2. Раз уж python-way, то не
3. В разделе «Удаление элементов из списка» у вас написано i вместо item.
4. В 100% случаев вместо filter лучше использовать генераторы списков.
2. Раз уж python-way, то не
not " "in name, а
" " not in nameИ скобки вокруг не нужны.
3. В разделе «Удаление элементов из списка» у вас написано i вместо item.
4. В 100% случаев вместо filter лучше использовать генераторы списков.
Спасибо за поправки.
Не в 100%. Если условие имеет смысл вынести в отдельную функцию (не lambda), то кроме filter вариантов не остается.
Не в 100%. Если условие имеет смысл вынести в отдельную функцию (не lambda), то кроме filter вариантов не остается.
[x for x in items if func(x)]
filter(func, items) — красивше
А если нужно две функции сразу? А если в функцию еще нужно передать пару параметров? А если полученные элементы нужно еще как-то обработать?
И если сегодня вы на все эти вопросы отвечаете «нет», то есть ли гарантия, что завтра вам не придется ответить «да»? Может все-таки сразу написать максимально гибко и не менее (а по мне так и более) ясно?
И если сегодня вы на все эти вопросы отвечаете «нет», то есть ли гарантия, что завтра вам не придется ответить «да»? Может все-таки сразу написать максимально гибко и не менее (а по мне так и более) ясно?
Вам это более ясно потому что вы более привычны к императивному программированию, чем к функциональному.
А если понадобиться что-то более сложное, то понадобятся листовые выражения или можно написать нужную функцию прямо здесь — это часто чище, чем замудрённое list comprehension.
Что касается гибкости и красоты — нет ничего лучше перловых map и grep.
А если понадобиться что-то более сложное, то понадобятся листовые выражения или можно написать нужную функцию прямо здесь — это часто чище, чем замудрённое list comprehension.
Что касается гибкости и красоты — нет ничего лучше перловых map и grep.
что значит написать функцию прямо здесь?
пишите def на предыдущей строчке
или прям вот так обязательно в этой же самой строчке?
P.S.
я из тех кто считает что конструкция lambda в питоне должна умереть как абсолютно ненужная
я правда reduce бы оставил, уж очень он привычен мне как человеку пришедшему в питон с хаскеля
пишите def на предыдущей строчке
или прям вот так обязательно в этой же самой строчке?
P.S.
я из тех кто считает что конструкция lambda в питоне должна умереть как абсолютно ненужная
я правда reduce бы оставил, уж очень он привычен мне как человеку пришедшему в питон с хаскеля
Приведите пример, пожалуйста. Все что можно сделать с помощью filter, делается не менее лаконично с помощью генераторов списков.
При этом код, по мне, более нагляден. Во-первых, мы сразу видим, что возвращается список. Во-вторых, операции наглядно разделены на «что», «где» и «при каком условии». Ну и в-третьих, если почитать документацию Питона, то там везде генераторы списков и нигде filter. :-)
При этом код, по мне, более нагляден. Во-первых, мы сразу видим, что возвращается список. Во-вторых, операции наглядно разделены на «что», «где» и «при каком условии». Ну и в-третьих, если почитать документацию Питона, то там везде генераторы списков и нигде filter. :-)
У вас ошибки в статье. Во-первых, данный код будет прекрасно работать и будет позволять обращаться ко всем атрибутам словаря.
Потому что метод
Во-вторых, неверно, что
Правильно:
class mydict(dict):
def __getattr__(self, key):
return self[key]
def __setattr__(self, key, value)
self[key] = value
Потому что метод
__getattr__ вызывается только тогда, когда атрибут не найден. Для перехвата всех обращений к атрибутам существует метод __getattribute__.Во-вторых, неверно, что
self.key является синтаксическим сахаром для self.__getattr__(key).
Правильно:
getattr(self, key) вызовет self.__getattribute__(key).Спасибо. Исправил, чтоб не распространять дезинформацию. Действительно, перепроверил изначальный код проекта, ошибки возникали не из-за переопределенного __getattr__().
Взгляд начинающего Python программиста (изучаю для себя)
1. пример с enumerate и описание range, xrange попадается на глаза даже при беглом просмотре мануала.
2. обращение к словарю через атрибуты кажется бессмысленным, в свете вышеописанных side эффектов — бессмысленным бредом (комментатору+1)
3. Мне не нравятся обе конструкции. Или пишите один return в самом конце или группируйте повторяющиеся значения (примерно как в 1 варианте). Я бы оставил единственный return a and b and c and d (вопрос к знатокам в python'е логические операции вычисляются полностью?)
4. Удаление из списка при проходе специфична в любом языке при чем здесь python? Проще всего пройтись с конца списка и никаких ухищрений. А вообще из предложенного решения не понятно чего же вы хотели?
— если автор хотел лишь изменить текущий список, для чего писать предлагать создание нового списка с сохранением старого?
— если автор хотел удалить первые 5 элементов, для чего ему вообще проверки и фильтры? del a[0:5] не вариант?
— b = [x for x in a if x >=5] скорее больше похоже на python way, но лично мне эта конструкция еще непривычна — может просто неудобно читать справа налево :)
1. пример с enumerate и описание range, xrange попадается на глаза даже при беглом просмотре мануала.
2. обращение к словарю через атрибуты кажется бессмысленным, в свете вышеописанных side эффектов — бессмысленным бредом (комментатору+1)
3. Мне не нравятся обе конструкции. Или пишите один return в самом конце или группируйте повторяющиеся значения (примерно как в 1 варианте). Я бы оставил единственный return a and b and c and d (вопрос к знатокам в python'е логические операции вычисляются полностью?)
4. Удаление из списка при проходе специфична в любом языке при чем здесь python? Проще всего пройтись с конца списка и никаких ухищрений. А вообще из предложенного решения не понятно чего же вы хотели?
— если автор хотел лишь изменить текущий список, для чего писать предлагать создание нового списка с сохранением старого?
— если автор хотел удалить первые 5 элементов, для чего ему вообще проверки и фильтры? del a[0:5] не вариант?
— b = [x for x in a if x >=5] скорее больше похоже на python way, но лично мне эта конструкция еще непривычна — может просто неудобно читать справа налево :)
1. и есть в tutorial в разделе Looping Techniques
Другой вопрос, что кто ж станет читать tutorial.
3. Нет, не полностью.
Другой вопрос, что кто ж станет читать tutorial.
3. Нет, не полностью.
Про 3. Длинные цепочки and очень быстро становятся плохочитабельными. Подход с несколькими if-return в начале, из личного опыта, намного удобнее и понятнее.
> 1. пример с enumerate и описание range, xrange попадается на глаза даже при беглом просмотре мануала.
Я вот не наткнулся, почему-то, на enumerate() (зело полезная функция, буду юзать), а xrange() вообще еще не было в мануале, когда я язык изучал (лет 10 назад).
Я вот не наткнулся, почему-то, на enumerate() (зело полезная функция, буду юзать), а xrange() вообще еще не было в мануале, когда я язык изучал (лет 10 назад).
> — b = [x for x in a if x >=5] скорее больше похоже на python way, но лично мне эта конструкция еще непривычна — может просто неудобно читать справа налево :)
Просто функциональщина. Простая и понятная конструкция, нужно просто привыкнуть. Юзаю сплошь и рядом, она гораздо нагляднее, чем цикл.
P.S. В эрланге, кстати, точно такой же синтаксис у list comprehensors.
Просто функциональщина. Простая и понятная конструкция, нужно просто привыкнуть. Юзаю сплошь и рядом, она гораздо нагляднее, чем цикл.
P.S. В эрланге, кстати, точно такой же синтаксис у list comprehensors.
> Во многих случаях len(a) можно без потерь заменить на более быстро any(a)
вы меня заинтриговали. в каких это случаях функцию «длина списка» можно заменить функцией «список содержит элемент с истинным значением»?
вы меня заинтриговали. в каких это случаях функцию «длина списка» можно заменить функцией «список содержит элемент с истинным значением»?
и ещё, по поводу formatName.
эта функция возвращает имя, разбитое на части или… False? хм. ну ладно. вообще-то Python way — это raise что-нибудь, например ValueError.
в вашей функции есть лишние скобки. плюс, «A not in B» — более читабельно, чем «not A in B».
к тому же, каждый return останавливает и сбивает.
имхо, если условие не слишком длинное, надо объединить в одно выражение и по возможности использовать положительную логику, т.е. «если относительно чего-то верно это, это и это, то ...»
def formatName(name):
if len(name) < 40 and " " in name and not name.startswith("?"):
return name.split(" ")
return False
в такой записи более понятно, какие требования предъявляются к name: len < 40, " " in name и not startswith("?").
эта функция возвращает имя, разбитое на части или… False? хм. ну ладно. вообще-то Python way — это raise что-нибудь, например ValueError.
в вашей функции есть лишние скобки. плюс, «A not in B» — более читабельно, чем «not A in B».
к тому же, каждый return останавливает и сбивает.
имхо, если условие не слишком длинное, надо объединить в одно выражение и по возможности использовать положительную логику, т.е. «если относительно чего-то верно это, это и это, то ...»
def formatName(name):
if len(name) < 40 and " " in name and not name.startswith("?"):
return name.split(" ")
return False
в такой записи более понятно, какие требования предъявляются к name: len < 40, " " in name и not startswith("?").
if not чонибудь1 raise Чонибудь1Error
if not чонибудь2 raise Чонибудь2Error
Это в принципе что для C, что для C#, что для Python нормальная идиома (ну, в C там будет return Eвcякое, а то и return -Eвсякое).
Distinguishing code features: The first ten lines of any function, even an accessor, are all assert statements.
if not чонибудь2 raise Чонибудь2Error
Это в принципе что для C, что для C#, что для Python нормальная идиома (ну, в C там будет return Eвcякое, а то и return -Eвсякое).
Distinguishing code features: The first ten lines of any function, even an accessor, are all assert statements.
Если мы уверены, что в списке не будет None, False и пустых строк. К примеру, список имен пользователей.
def isSomeoneThere():
return len(activeUsers) and "Yes" or "No"
def isSomeoneThere():
return any(activeUsers) and "Yes" or "No"Если нам важно только то, содержит ли список элементы, можно прямо if activeUsers и писать (в приведённом примере — return bool(activeUsers)).
минуточку, что именно делает isSomeoneThere? проверяет массив на пустоту и возвращает Yes/No?
тогда зачем len, зачем any, почему просто не использовать bool(activeUsers), когда пустой массив == False, а остальное True? учитывая, что boolean evaluation применяется неявно, можно заменить всю эту песню на return activeUsers and «Yes» or «No»
тогда зачем len, зачем any, почему просто не использовать bool(activeUsers), когда пустой массив == False, а остальное True? учитывая, что boolean evaluation применяется неявно, можно заменить всю эту песню на return activeUsers and «Yes» or «No»
Да, а еще для любителей почитать «доки по стилю» очень рекомендую ссылку google-styleguide.googlecode.com/svn/trunk/pyguide.html. Style guide от Google — это, я вам скажу, не баран чихнул на забор.
Удаление элементов из списка. Если список небольшой, то можно вот так:
for item in a[:]:
if item<5:
a.remove(item)
нет, уважаемый, если уж речь о python way, то ТОЛЬКО filter или list comprehension. никаких индексов для работы с массивами, запомните это.
если вам совершенно необходимо сохранить ссылку на тот же самый массив, то надо использовать слайс-присваивание, то есть
a[:] = [i for i in a if i < 5]
или
a[:] = filter(lambda i: i < 5, a)
только так.
если вам совершенно необходимо сохранить ссылку на тот же самый массив, то надо использовать слайс-присваивание, то есть
a[:] = [i for i in a if i < 5]
или
a[:] = filter(lambda i: i < 5, a)
только так.
Чисто ради любопытства (на python программирую всего лишь лет пять, поэтому не считаю себя вправе указывать где серебряная пуля, а где нет) — а где в моем фрагменте кода индексы?
так, а чем a[:] отличается от просто a?
Тем, что a[:] создает новый объект. Это аналогично list(a). Кстати, улчше так и писать, чтобы не возникало подобным вопросов.
Идиома a[:] объясняется в tutorial в всего лишь третьем листинге раздела Lists.
Идиому list(a), где a — тоже list, я вообще впервые вижу.
Идиому list(a), где a — тоже list, я вообще впервые вижу.
Тем не менее, человек, который впервые видит python-код, сразу поймет, что list(a) — это создание нового объекта. А вот a[:] — вещь нетривиальная.
Также, a.reverse() лучше чем a[::-1] по той же причине.
Правда, для строки a.reverse() не подойдет.
Также, a.reverse() лучше чем a[::-1] по той же причине.
Правда, для строки a.reverse() не подойдет.
> Тем не менее, человек, который впервые видит python-код, сразу поймет, что list(a) — это создание нового объекта.
Нет, не поймёт. Начиная с непонятности синтаксиса встроенный_тип() и заканчивая неочевидностью того, создастся ли копия.
>Также, a.reverse() лучше чем a[::-1] по той же причине.
a.reverse() меняет in-place, слайс создаёт новый объект.
Нет, не поймёт. Начиная с непонятности синтаксиса встроенный_тип() и заканчивая неочевидностью того, создастся ли копия.
>Также, a.reverse() лучше чем a[::-1] по той же причине.
a.reverse() меняет in-place, слайс создаёт новый объект.
>>Начиная с непонятности синтаксиса встроенный_тип() и заканчивая неочевидностью того, создастся ли копия.
Чем такой синтаксис непонятен? Выглядит как обычное преобразование типа.
>>a.reverse() меняет in-place, слайс создаёт новый объект.
Неверно написал, имел ввиду a=a[::-1], конечно же.
Чем такой синтаксис непонятен? Выглядит как обычное преобразование типа.
>>a.reverse() меняет in-place, слайс создаёт новый объект.
Неверно написал, имел ввиду a=a[::-1], конечно же.
> Выглядит как обычное преобразование типа.
Вот и чудесно, преобразуем лист в лист и получаем его же.
Это не преобразование типа, ага.
Вот и чудесно, преобразуем лист в лист и получаем его же.
Это не преобразование типа, ага.
> Неверно написал, имел ввиду a=a[::-1], конечно же.
Да, поэтому мы не будем писать a=a[::-1], когда нам надо in-place. А когда нам не надо in-place, мы будем писать a[::-1].
Да, поэтому мы не будем писать a=a[::-1], когда нам надо in-place. А когда нам не надо in-place, мы будем писать a[::-1].
>Нет, не поймёт.
Я вот понял — функция (если не оговорено иного в сигнатуре вызова) не может возвращать не новый объект, хотя бы потому что он ей не передаётся :)
Я вот понял — функция (если не оговорено иного в сигнатуре вызова) не может возвращать не новый объект, хотя бы потому что он ей не передаётся :)
> a.reverse() лучше чем a[::-1]
не факт. смотря, как вы хотите поступить с a: a.reverse() реверснёт имеющийся, a[::-1] сделает копию. корректнее сказать, что a.reverse() лучше, чем a = a[::-1] — и читабельнее, и не создаёт лишней копии, но a.reverse() не подойдёт, если a ещё потребуется в своём первоначальном виде.
> по той же причине
по той причине, что читающий не знает про слайсы? ничего, пойдёт и прочитает. слайсы — это круто.
не факт. смотря, как вы хотите поступить с a: a.reverse() реверснёт имеющийся, a[::-1] сделает копию. корректнее сказать, что a.reverse() лучше, чем a = a[::-1] — и читабельнее, и не создаёт лишней копии, но a.reverse() не подойдёт, если a ещё потребуется в своём первоначальном виде.
> по той же причине
по той причине, что читающий не знает про слайсы? ничего, пойдёт и прочитает. слайсы — это круто.
Как по мне, но большая часть (не пересчитывал, по ощущениям) «косяков» относится к спискам, которые далеко не всем нужны… А насчёт «Плоское лучше, чем вложенное» душа кровью обливается — за «плоское» я получил единственное «хор.» по ИТ связанным специальностям, сделал бы «вложенное» получил бы очередной «отл»!
Но за статью всё равно плюсик, тема полезная, жаль что нев той мере как хотелось бы раскрытая: я сейчас пытаюсь писать на питоне то, что последние 10 лет писал либо на C++ (десктоп, MFC), либо на PHP (веб)… знаю что пишу неправильно, в смысле не python-way, но фидбэка нет и быть не может, поскольку я пытаюсь проникнуться плюсами питона, и перевести, если эти плюсы есть, всех своих «соратников»
Если не списки и словари, то зачем вообще Python?
> насчёт «Плоское лучше, чем вложенное» душа кровью обливается
В The Zen of Python есть и более «неудобные» максимы.
> насчёт «Плоское лучше, чем вложенное» душа кровью обливается
В The Zen of Python есть и более «неудобные» максимы.
Вот я тоже не понимаю… Но все вокруг твердят, что лучше python или ruby (если ограничиваться скриптовыми языками), а я разницы (кроме синтаксиса и yield) почти… Ну, не считая, что php поддерживает реез на уровне языка, а не библиотек/фреймворков
*http
Если не углубляться в холивары:
-изначальная не-CGI природа Python'а. Соответственно, с одной стороны, огромное количество стабильных и отлаженных средств общего назначения (найдите мне аналог NumPy, SymPy, BioPy для PHP) и большое количество способов реализации сервера (Twisted, Apache/nginx в качестве WSGI-пускалки, gevent как самостоятельный сервер или как WSGI-запускалка, raw sockets) со своими плюсами и минусами (покажите мне аналог Twisted'а для PHP);
-совершенство языка. Сравните банальные текстовые require/include в PHP и полноценные модули (да, их поведение можно имитировать неймспейсами/объектами, но это всё равно надо писать руками, в питоне же всё будет «из коробки»); плюс всякие приятные плюшки типа list comprehensions, generator expressions, синтаксиса без скобок и т.д.;
-богатые возможности для построения фреймворков. Если я не ошибаюсь, лучшее, что может тут предложить PHP — «магические» методы у классов. Сравните с наличием метаклассов, декораторов и дескрипторов у Python'а (впрочем, вы сами можете их и не замечать, просто используя фреймворки, но именно они позволяют делать эти фреймворки достаточно удобными);
-yield гораздо серьёзнее, чем кажется на первый взгляд. Это почти полноценная континуация, соответственно, сам по себе yield позволяет реализовать кооперативную однопоточную многозадачность (см. Twisted'овский @inlineCallbacks) без особой поддержки со стороны интерпретатора, в отличие от приснопамятного node.js, в котором это принципиально невозможно и остаётся только пользоваться голыми коллбеками. (вообще говоря, будь Twisted чуть пошустрее, это была бы однозначно лучшая сетевая библиотека Python'а. но издержки event loop'а на pure python дают о себе знать)
-изначальная не-CGI природа Python'а. Соответственно, с одной стороны, огромное количество стабильных и отлаженных средств общего назначения (найдите мне аналог NumPy, SymPy, BioPy для PHP) и большое количество способов реализации сервера (Twisted, Apache/nginx в качестве WSGI-пускалки, gevent как самостоятельный сервер или как WSGI-запускалка, raw sockets) со своими плюсами и минусами (покажите мне аналог Twisted'а для PHP);
-совершенство языка. Сравните банальные текстовые require/include в PHP и полноценные модули (да, их поведение можно имитировать неймспейсами/объектами, но это всё равно надо писать руками, в питоне же всё будет «из коробки»); плюс всякие приятные плюшки типа list comprehensions, generator expressions, синтаксиса без скобок и т.д.;
-богатые возможности для построения фреймворков. Если я не ошибаюсь, лучшее, что может тут предложить PHP — «магические» методы у классов. Сравните с наличием метаклассов, декораторов и дескрипторов у Python'а (впрочем, вы сами можете их и не замечать, просто используя фреймворки, но именно они позволяют делать эти фреймворки достаточно удобными);
-yield гораздо серьёзнее, чем кажется на первый взгляд. Это почти полноценная континуация, соответственно, сам по себе yield позволяет реализовать кооперативную однопоточную многозадачность (см. Twisted'овский @inlineCallbacks) без особой поддержки со стороны интерпретатора, в отличие от приснопамятного node.js, в котором это принципиально невозможно и остаётся только пользоваться голыми коллбеками. (вообще говоря, будь Twisted чуть пошустрее, это была бы однозначно лучшая сетевая библиотека Python'а. но издержки event loop'а на pure python дают о себе знать)
Своего рода аналог Twisted пожалуй PHPDaemon. Хотя Twisted безусловно мощнее.
Мне, кстати, еще очень нравится в Python множество способов передавать/принимать аргументы в функциях:
для передачи
для приема
В PHP есть func_num_args(), func_get_arg(), func_get_args() но это все же не то.
Декораторы часто бывают полезны.
Еще классно что можно передать функцию в качестве аргумента другой функции (в PHP с появлением лямбд тоже стало можно, но такая конструкция $func($arg1, $arg2), когда вызывается нечно начинающееся со знака $ немного пугает)
Ну и yield несомненно очень мощная штука.
Мне, кстати, еще очень нравится в Python множество способов передавать/принимать аргументы в функциях:
для передачи
func(arg1, arg2)
func(arg2=var2, arg1=var1)
func(*args_tuple)
func(**args_dict)для приема
def func(arg1, arg2)
def func(*args)
def func(**kwargs)В PHP есть func_num_args(), func_get_arg(), func_get_args() но это все же не то.
Декораторы часто бывают полезны.
Еще классно что можно передать функцию в качестве аргумента другой функции (в PHP с появлением лямбд тоже стало можно, но такая конструкция $func($arg1, $arg2), когда вызывается нечно начинающееся со знака $ немного пугает)
Ну и yield несомненно очень мощная штука.
Спасибо за ответ, есть над чем подумать. Хотя вот кажется, что удобство использования модулей компенсируется неудобством их создания, а может просто руку надо набить, но даже того, что я видел хватило понять, что единообразия не существует, а значит есть плюсы и минусы у каждого подхода по разделению классов на файлы модулей, раз кто-то предпочитает держать весь модуль в __init__.py, кто-то раскидывает «один класс-один файл», кто-то группирует классы по файлам, кто-то комбинирует все три метода, плюс кто-то экспортирует всё, а кто-то прямо перечисляет
Да это в общем-то без разницы. Да, единообразия не существует.
Наружу всё равно в идеале торчит только то, что в документации описано (всмысле, если можно вызвать что-то ещё, про это знать необязательно).
Наружу всё равно в идеале торчит только то, что в документации описано (всмысле, если можно вызвать что-то ещё, про это знать необязательно).
>удобство использования модулей компенсируется неудобством их создания
Модуль=файл. Без каких-либо дополнительных синтаксических наворотов. Какое ещё «неудобство создания»?
>единообразия не существует
Есть style guidelines. Это примерно как сказать «не существует единообразия в расстановке { }, значит, они плохие».
>предпочитает держать весь модуль в __init__.py
Вы явно плохо знакомы с Python'ом.
>кто-то экспортирует всё, а кто-то прямо перечисляет
Это исключительно на усмотрение создателя. Это тем более неважно, что «прямое перечисление» определяет только то, что будет импортнуто после import *, что является крайне дурным тоном по меркам питонокоммьюнити.
Модуль=файл. Без каких-либо дополнительных синтаксических наворотов. Какое ещё «неудобство создания»?
>единообразия не существует
Есть style guidelines. Это примерно как сказать «не существует единообразия в расстановке { }, значит, они плохие».
>предпочитает держать весь модуль в __init__.py
Вы явно плохо знакомы с Python'ом.
>кто-то экспортирует всё, а кто-то прямо перечисляет
Это исключительно на усмотрение создателя. Это тем более неважно, что «прямое перечисление» определяет только то, что будет импортнуто после import *, что является крайне дурным тоном по меркам питонокоммьюнити.
Прочитал статью и комментарии к ней; в очередной раз убедился в ущербности Python'а.
Если что, len(a) ничего не считает, ее сложность всегда О(1). wiki.python.org/moin/TimeComplexity
всегда нужно уточнять: если для a реализован метод __len__. для списка он реализован.
Интересно:
import time
def test(f, a):
t=time.clock()
for i in xrange(1000000):
f(a)
return time.clock()-t
a=range(1000000)
print test(len, a)
print test(bool, a)
len(a) отрабатывает быстрее всех, за ней any, за ней bool. Не ожидал.
print test(any, a)<source>
Для начала — это экономия на спичках, писать лучше как понятнее. Дальше — тест:
выводит
Самый понятный вариант оказался, как это часто бывает, самым быстрым.
import time
def measure(func):
def inner():
arr = range(100000)
start=time.clock()
func(arr)
return time.clock()-start
return inner
@measure
def test_len(arr):
for i in xrange(1000000):
if len(arr):
pass
@measure
def test_any(arr):
for i in xrange(1000000):
if any(arr):
pass
@measure
def test_bool(arr):
for i in xrange(1000000):
if bool(arr):
pass
@measure
def test_simple(arr):
for i in xrange(1000000):
if arr:
pass
print test_len()
print test_any()
print test_bool()
print test_simple()
выводит
0.138603 0.213345 0.255277 0.064151
Самый понятный вариант оказался, как это часто бывает, самым быстрым.
Для замеров производительности путем многократных повторений есть такой модуль docs.python.org/library/timeit.html
Есть ли какая-то разница писать замерялку самому или использовать этот модуль не знаю, но если есть — почему не воспользоваться?
Есть ли какая-то разница писать замерялку самому или использовать этот модуль не знаю, но если есть — почему не воспользоваться?
чтобы обращаться к элементам словаря, как к атрибутам класса, то есть, в стиле JS (myobject.myelement), можно воспользоваться таким приемом...
a.1
#Ошибка! Атрибут не может начинаться с цифры
Вообще-то конструкция a.1 совсем не в стиле js. Также как и в python, в js она выдаст ошибку.
О! Да такое сплошь и рядом! У нас в PHP тоже, когда приходят плохокодеры из Явы, Си или какого-нибудь дотнета (я так догадываюсь, что они приходят с других языков, по стилю их кода), такое творится, что в питоноводам и не снилось, например начинают строки посимвольно циклом разбирать (ага, всего то раз в 1000 медленнее чем в Си) вместо использования встроенных функций, или проверять наличие элемента в большом массиве через in_array() (то есть, не по индексу хеша, а по значениям, что требует полного перебора элементов).
Ну а программеров с явы легко распознать по излишней любви к созданию классов сотнями, они чуть ли не каждую переменную в свой объект пытаются завернуть, и фабрик вокруг понастроить, производительность естественно плачет и рыдает, посмотрите на какой-нибудь Zend Framework.
Ну и еще есть тип, видимо приходят с руби или яваскрипта, которые к каждому объекты пристраивают геттеры, сеттеры и систему событий, этих вообще убивать можно сразу.
И вообще, пытаться в один язык тащить приемы из другого языка, по моему, всегда получается плохо.
Ну а программеров с явы легко распознать по излишней любви к созданию классов сотнями, они чуть ли не каждую переменную в свой объект пытаются завернуть, и фабрик вокруг понастроить, производительность естественно плачет и рыдает, посмотрите на какой-нибудь Zend Framework.
Ну и еще есть тип, видимо приходят с руби или яваскрипта, которые к каждому объекты пристраивают геттеры, сеттеры и систему событий, этих вообще убивать можно сразу.
И вообще, пытаться в один язык тащить приемы из другого языка, по моему, всегда получается плохо.
Вот еще несколько заметок, как избавиться от С прошлого и начать жить на Питоне:
1.
плохо: lst[len(lst) — 1]
хорошо: lst[-1]
2.
плохо: lst[random.randint(0, len(lst) — 1)] #да, и такое встретишь порой
хорошо: random.choice(lst)
3. Распаковка tuple: p = (1, 2)
плохо:
x = p[0]
y = p[1]
хорошо:
x, y = p
4. Аналог Си операторам ?:
a = x if cond else y #введен в Python 2.5
1.
плохо: lst[len(lst) — 1]
хорошо: lst[-1]
2.
плохо: lst[random.randint(0, len(lst) — 1)] #да, и такое встретишь порой
хорошо: random.choice(lst)
3. Распаковка tuple: p = (1, 2)
плохо:
x = p[0]
y = p[1]
хорошо:
x, y = p
4. Аналог Си операторам ?:
a = x if cond else y #введен в Python 2.5
кстати, здесь очень много дельных советов
google-styleguide.googlecode.com/svn/trunk/pyguide.html
спасибо, enchantner!
google-styleguide.googlecode.com/svn/trunk/pyguide.html
спасибо, enchantner!
У меня есть вопрос к профи. Как удалить элемент из списка словаря, если его, возможно там нет?
В PHP, например, можно всегда писать unset($arr['val']) — одна строчка. В Питоне, если элемента не будет, возникнет исключение. Приходится писать:
Это же не гигиенично.
В PHP, например, можно всегда писать unset($arr['val']) — одна строчка. В Питоне, если элемента не будет, возникнет исключение. Приходится писать:
if 'val' in arr:
del arr['val']
Это же не гигиенично.
извините, что встреваю, но может сработать вот так:
если элемент по ключу будет не найдет, то он будет создан.
spam['egg'] = None
если элемент по ключу будет не найдет, то он будет создан.
А создать класс
не вариант?
class safedict(dict):
remove = lambda self, key:key in self and (self.__delitem__(key) or True)не вариант?
Ну опять свои правила в чужой монастырь? Эта проверка нужна, это идеология языка, суть которой принцип: явное лучше неявного.
key = func()
if key in arr:
del arr[key]
unset(arr[func()]);
Как-то неявно, что явное лучше.
Ок, объясню. Что делает unset в php? Если не ошибаюсь, давным давно в это была функция, которая все время возвращала True, начиная с 4ой версии это вообще оператор языка который в принципе ничего не может возвращать. Итого он всегда уничтожает переменную. Существование самой переменной ему не интересно и вы никогда не узнаете, а был ли мальчик (существовала ли переменная). Пайтон же подобный подход не поощряет, возможно вы указали del неверный объект (банально опечатались), пайтон услужливо скажет вам, что такого объекта нет (хотя опечататься тоже можно по-разному)). А что будет в этом случае в php? Вы можете уничтожить совсем не то, что собирались и в итоге поимеете N времени отладки, чего можно было избежать. Вот поэтому явная проверка лучше.
key in arr and arr.pop(key)Явно и легко читается.
def formatName(name):
if len(name)>=40:
return False
if " " not in name:
return False
if name[0]=="?"
return False
Лучше бы (и во всех остальных случаях тоже, а то у Вас где-то есть пробелы в таких местах, где-то нет) так:
def formatName(name):
if len(name) >= 40:
return False
if " " not in name:
return False
if name[0] == "?":
return False
Я не прав?
Ещё здесь в предпоследней строке двоеточие забыли.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Публикации
Python-way. Работа над ошибками