всем привет!

>>Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.
>это идеология. :) всё, что укладывается в pep8 и pep20 - питоноугодно. всё, что нет - нет
Поутру перечитал и решил добавить. Вопрос сугубо технический =) Если его перефразировать, то звучит примерно так:

Я привык считать приведение типов, работу с нетипизированными массивами (читай списками) медленными операциями. Определение длинны строки -- медленная операция. Но вот, например, классическая задачка по программированию: определить разряд числа. Классическим питон-решением является:

number_length(num):
    return len(str(num))

если не вспоминать про проверку типа получаемых данных и прочие защиты от дурака.

С точки зрения "классического" программирования это решение неэлегантно и неторопливо. Гораздо быстрее будет работать такой вариант:

number_length(num):
    n = 0
    while num > 0:
        n = n + 1
	num = num // 10
    return n

Вот и вопрос отсюда: как оптимальнее с точки зрения питона? Конечно, я бы мог написать несколько тестов для проверки этого факта, но всегда было интересно мнение непосредственно питонщиков по этому вопросу.

P.S.: Кто-то классическое решение такой задачки мне даже лайкнул на checkio.org.

>Я привык считать приведение типов, работу с нетипизированными массивами (читай списками) медленными операциями. Определение длинны строки -- медленная операция. Но вот, например, классическая задачка по программированию: определить разряд числа. Классическим питон-решением является:

какое очевидное - такое и правильное :) дзен python :)

со списками... поэтому у тебя в python аж три списка - list, tuple и set :) посмотри, с какой скоростью сравниваются два set-а по 200000 значений в них ;)


не, я теорией не интересуюсь, мне важнее практика. какой вариант читабельнее - тот и лучше, pep8 и pep20 не зря являются основой основ :)

>Вот и вопрос отсюда: как оптимальнее с точки зрения питона? Конечно, я бы мог написать несколько тестов для проверки этого факта, но всегда было интересно мнение непосредственно питонщиков по этому вопросу.

мнение тех, кто постиг дао, дзен, pep8 и pep20, думаю, будет однозначным - какое читабельнее, то и лучше. для скорости - расширения C и разные numpy, а в обычных вещах никто на спичках экономить не будет (разумеется, если это не сверхнеоптимальное решение)

>всем привет!
Привет.

Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.

Питон всё таки язык транслируемый и достаточно неторопливый.

>>ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать
>Ну фиг знает. Это кушает python3. И это я очень долго и упорно всё гуглил и обкатывал. И они таки есть. Потому как байт-массив из юникода не получается и потому приходится промежуточно транслировать всё в ascii. Уж не знаю тонкостей, но работает.

именно поэтому я выбираю python2. там всё просто - str это байт-строка, unicode это unicode-строка. в python3 столько заморочек по этому поводу, что проще повеситься. поэтому, когда стоят такие задачи, python2 - то, что доктор прописал. а сейчас это в python2 не запускается :(

>ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать
Ну фиг знает. Это кушает python3. И это я очень долго и упорно всё гуглил и обкатывал. И они таки есть. Потому как байт-массив из юникода не получается и потому приходится промежуточно транслировать всё в ascii. Уж не знаю тонкостей, но работает.

>Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.

>Питон всё таки язык транслируемый и достаточно неторопливый.

это идеология. :) всё, что укладывается в pep8 и pep20 - питоноугодно. всё, что нет - нет

ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать