Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 32
Кто этот человек, который не знал о таких возможностях? Это же все, практически курс туториала по питону
Опытные программисты не найдут в ней ничего нового. Статья для начинающих
Добавьте тогда тег «tutorial» и сделайте предвступление об этом.
А так по заголовку ожидания были завышенными.
А так по заголовку ожидания были завышенными.
Программирую на python больше 2 лет. Не знаю, могу ли я назвать себя опытным, но из статьи узнал много полезного.
У меня плохие новости. За два года вы должны были продвинуться гораздо гораздо глубже. Это же первые месяцы, максимум.
Прелесть питона, то что для начала работы, хватает порой, выучить статью на вики по синтаксису. Многое в нём понятно интуитивно. Это если знаешь другой ЯП.
С вами не согласен. Метаклассы например достаточно сложная тема. На уровне синтаксиса можно выучить почти любой язык за короткий срок, но когда дело доходит до «подводных камней», статьи из вики уже бывает недостаточно.
Метаклассы это очень редко, многие успешно клепающий к примеры сайты на Джанге, Пирамиде или Флаке знают про них только то что они существуют)
Я не спорю. Многие вещи и через годы работы можно открывать для себя. Но я имел ввиду именно «начать».
Просто у меня был уже опыт изучения языков подобным способом. В голове образуется какая то каша, а знания остаются поверхностными. Вики можно использовать как справочник, нежели как учебник. Вот в той же джанги ModelBase — метакласс.
На всякий случай про метаклассы на stack-overflow есть очень хорошее объяснение :) stackoverflow.com/questions/100003/what-is-a-metaclass-in-python
Я на питон только начинаю смотреть. И он прекрасен. Спасибо!!!
Я когда с php перешёл только на питон. При том сразу же в действующий старый проект. По началу ругался. Так как примерно 8 лет за плечами на пхп и две недели на питоне. Не давали возможности быстро решать поставленные задачи. В то время когда как решить их на пхп я знал. Но уже спустя 2 месяца, не существовала способа, заставить меня вернуться на пхп.
В свое время это было бы мне очень полезно. В питоне много тонкостей и автор рассмотрел те что вполне пользительны и неочевидны для годовалых питонистов, а возможно и опытнее.
Вот это в Python 2.x почти всегда неправильно (то, что используется Python 2.x, можно понять из синтаксиса print):
Если unicode_literals не импортированы сверху файла, то 'выход из блока' тут — это байтовая строка, которая закодирована в ту кодировку, в которой хранится исходный код.
print байтовые строки выводит «как есть», никак не преобразуя — просто передает байты на выход. Поэтому если кодировка, которую использует консоль, не совпадает с кодировкой исходного кода, то консоль будет декодирует байты неправильно, и получим мусор на выходе. С ascii текстом это обычно не проблема, т.к. большинство кодировок кодирую ascii одинаково, но тут есть не-ascii символы. Для того, чтобы print использовал кодировку консоли, нужно печатать юникодные строки:
В этом случае Python перед тем, как передать строку на выход, закодирует ее именно в кодировку консоли. Там не все так просто (иногда кодировку консоли сложно определить), но все же печать юникодных строк гораздо надежнее.
Тут еще может смутить то, что если код набрать в интерпретаторе (REPL), то обычно print 'выход из блока' работает, т.к. константа берется из консоли, а sys.stdin.encoding обычно совпадает с sys.stdout.encoding. А если потом код сохранить в py файл, то все может сломаться, т.к. кодировка файла вполне может не совпадать с кодировкой консоли.
print 'выход из блока'Если unicode_literals не импортированы сверху файла, то 'выход из блока' тут — это байтовая строка, которая закодирована в ту кодировку, в которой хранится исходный код.
print байтовые строки выводит «как есть», никак не преобразуя — просто передает байты на выход. Поэтому если кодировка, которую использует консоль, не совпадает с кодировкой исходного кода, то консоль будет декодирует байты неправильно, и получим мусор на выходе. С ascii текстом это обычно не проблема, т.к. большинство кодировок кодирую ascii одинаково, но тут есть не-ascii символы. Для того, чтобы print использовал кодировку консоли, нужно печатать юникодные строки:
print u'выход из блока'В этом случае Python перед тем, как передать строку на выход, закодирует ее именно в кодировку консоли. Там не все так просто (иногда кодировку консоли сложно определить), но все же печать юникодных строк гораздо надежнее.
Тут еще может смутить то, что если код набрать в интерпретаторе (REPL), то обычно print 'выход из блока' работает, т.к. константа берется из консоли, а sys.stdin.encoding обычно совпадает с sys.stdout.encoding. А если потом код сохранить в py файл, то все может сломаться, т.к. кодировка файла вполне может не совпадать с кодировкой консоли.
>>Оказывается у Python 2.x есть ограничения на целое число, в этом мы можем убедиться просмотрев константу sys.maxsize
Не очень хорошо сформулировано. Ведь задавать и использовать большие числа можно без проблем.
Не очень хорошо сформулировано. Ведь задавать и использовать большие числа можно без проблем.
>>> import sys
>>> print sys.version
2.7.4 (default, Sep 26 2013, 03:20:26)
>>> print sys.maxsize*10**10+1
92233720368547758070000000001
Большие числа конвертируются в long
В Python3
>>> import sys
>>> sys.version
'2.7.1 (r271:86832, Jul 31 2011, 19:30:53) \n[GCC 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00)]'
>>> sys.maxsize * 10 ** 10 + 1
92233720368547758070000000001L
>>> type(sys.maxsize * 10 ** 10 + 1)
<type 'long'>
>>>
В Python3
>>> import sys
>>> type(sys.maxsize * 10 ** 10 + 1)
<class 'int'>
>>> sys.maxsize * 10 ** 10 + 1
92233720368547758070000000001
>>> sys.version
'3.3.2 (v3.3.2:d047928ae3f6, May 13 2013, 13:52:24) \n[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)]'
>>>
Тем не менее, говорить о том, что в Python 3 конвертации не произошло, не следует. Если вы говорите, что её не произошло, то это намекает на то, что она могла произойти. Но на самом деле конвертации не произошло, потому что в Python 3 объединили два типа.
а можно об этом подробнее?
Там не о чем особо подробно говорить. Просто в третьем питоне убрали старый int, а старый long переименовали в int.
docs.pythonsprints.com/python3_porting/py-porting.html#long-integers
docs.pythonsprints.com/python3_porting/py-porting.html#long-integers
Я писал про то, что не совсем корректно говорить, что «есть ограничения на целое число». long это тоже целое.
g <название языка программирования> hidden features stackoverflow
Написано хорошо, но заголовок… Извини, но это чуть больше чем азы, а не некоторые возможности о которых мы не знали)
Пишу Python 3. Использую исключительно для научных вычислений (SciPy + NumPy etc.). Вчера писал контест на codeforces (я не олимпиадник и рейтинг у меня низкий, но занимаюсь иногда, чтобы мозг размять) и решал задачу, где нужен был dict. И меня дико удивило, что я на третьем питоне не мог сдать задачу — не проходила по времени. После контеста посмотрел на чем сдают люди, и перписал на Python 2.7. Программа стала работать быстрее чем в 2 раза и кушать памяти на 500 Кб меньше. Вот этого я точно не знал о Python.
В прошлом топике про неочевидные особенности Питона дали ссылку на alexbers.com/python_quiz/ — там, действительно, хорошая подборка таких «подводных камней».
Нормальная статья для исследующего возможности Питона и делящегося своими наработками. Если кто метаклассно крут в Питоне, то какой смысл комментировать? А если есть вопросы по логике решений - имеет смысл обсуждать. Я давно пишу на Питоне, но не перестаю пользоваться справочниками или подобными статьями, так как есть решения, которыми не часто пользуешься. Автор - молодец
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Некоторые возможности Python о которых вы возможно не знали