Утверждение про циклы (да apply туда же) основано просто на просмотре многих Кloc кода.. можно по гитхабу погядеть, например
Не всё на ГитХабе стоит брать в пример.
На уровне асма циклы и ветвление -- базовая конструкция
Асм это когда в регистр кладёш из регистра достаёшь и туда-сюда прыгаешь. Нет там циклов, это уже логическая структура поверх языка.
Ошибка с индексами цикла -- это типичный паттерн для всех языков. Out of Index...
Я практически не пишу кода на Питоне, где такая ошибка может появится. Уже во многих мейнстримных языках есть итерация по коллекциям. В С++ на работе с индексами можно выиграть производительности, в Питоне скорее наоборот.
ООП -- основа питона.... и весь дс пронизан им вдоль и поперек. методы и классы. объекты и свойства... Даже Series -- и тот является не массивом в его счетном понимании, а сложной структурой со скрытым индексом.
ООП это подход к организации кода. Наличие объектов и классов само по себе не является ООП. Можно даже делать ООП без них. Методы и классы добавляют значительную долю удобства. В Питоне отличная система типов, но в ДС она не используется, в основном там работают с набором высоко-уровневых коллекций из сторонних библиотек.
Какие у вас проблемы с Series? Заведите два массива, один для данных другой для индекса, напишите функции для изменения, чтения, используйте доступ по номеру ячейки, держите их постоянно в согласованном состоянии. Всё будет явно и никаких классов и методов, IndexError получите в подарок.
В R тоже есть сложные типы.
Вот и я про то -- питон не для больших данных. Но его по факту туда постоянно пихают. Оркестрация -- это ИТ-шные задачки
Под оркестрацией я имею ввиду передачу данных в не питоновский код, где они будет обрабатываться на скоростях близких к C++. Например Pandas это Питон снаружи и С++ внутри. Данные хранятся в С++ структурах и вызывая методы в Питоне в делегируете операции в сишный код. Аналогично с декодированием видео, все операции происходят в сишном коде.
Вот такая вот лапша между методами и функциями постоянна. Читается очень и очень тяжело...
Где здесь функции? Это плохой код не потому, что он на Питоне, а потому что он плохо написан. Как это на R будет выглядеть?
Уберите всё мыло в отдельные функции и напишите логику человеческим языком.
[clean(div) for div in get_titles()]
Питон хорош для общих задач, для дс он страшно уныл. Наверное, мы как-то пришли к общему знаменателю.
У меня складывается ощущение, что вы сталкивались не с лучшим кодом на Питоне.
Возможности писать читаемый код на Питоне больше чем на R.
И еще много где. То есть вы пытаетесь охватить аудиторию вне домена ДС. Напоминаю, мы обсуждаем соответствие тэга статье.
В питоне циклы применяются ещё чаще
Субъективное утверждение без контекста. pandas и numpy это то, где циклы применять не стоит. Это противоречит их основной идее.
Здесь про подумать текст, а не кукбуки кодовые
Если здесь про подумать, тогда почему такой ограниченный выбор языков в тэгах? Циклы много где есть.
а не кукбуки кодовые
Часть задач решается используя особенности языка, вполне кукбуки. Для питона они не подходят. Решения через алгоритмы не привязаны к языку.
И да, я очень не люблю питон в дс за его косноязычность, ооп-шность, медленность. 1001 причина почему он плох.
Если не секрет, R случайно не первый язык? Он достаточно специфичный, уклоном в оптимизацию. У меня был коллега который очень странный код на Питоне писал. Я понял почему только когда познакомился с R. В одной из первых строк статьи Вы пишите, "При работе с индексами цикла можно легко проглядеть и допустить ошибку". В контексте Питона это звучит странно, там сделано много, чтобы не работать с индексами напрямую.
питон в дс за его косноязычность
Я hello word на многих языках писал, R очень специфичный. Он хорош для той области для которой он создавался.
ооп-шность
Я хожу по краю ДС, поправьте меня, но там данные в основном в табличном виде, и парадигма ООП не особо используется. Или вы про DataModel?
медленность
Не надо обрабатывать питоном большие данные, он не для этого, им нужно оркестрировать обработку. Рекомендую посмотреть James Powell, он много рассказывает про "restricted computation domains".
Я взаимодействую с ребятами из ДС. Для них Питон это просто еще один инструмент, они освоили его на том уровне чтобы решать свои задачи. Знания языка порой на уровне джуна по Питону. Для работы с Pandas больше и не нужно.
Я стараюсь документировать код, а аннотиции типов это самая легкая форма документации. Есть поддержка со стороны языка и инструментов.
Забыли сказать про главную проблему типизации. Если объект на тип который вы ссылаетесь, еще не определён, можно его тип взять в кавычки.
class Foo:
def foo(self) -> "Foo":
return self
Иногда аннотации позволяют выразить то, что сложно сделать в коде. Mapping это неизменяемый словарь. Родной реализации такого словаря в Питоне нет, писать самому или устанавливать зависимости не всегода хочется.
В данном случае я явно указываю свои ожидания, что возвращаемое значние менять не надо.
Dictionary для этой здачи совсем не подходит по логике. Есть более простая структура данных, которые просто идеально подходит к данной задаче - set https://www.programiz.com/swift-programming/sets. Под капотом обычно тоже самое что в словаре, только без значений.
> Обозначение Big O нотация (или просто Big O) — это способ оценки относительной производительности структуры данных или алгоритма, обычно по двум осям: времени и пространству.
Это о сложности, а о времени. Да, некоторые закономерности прослеживаются. Но вот контр пример, возьмем такую задачу: нужно нам обойти ровно миллион ссылок. Как не крути это долго. Раз мы знаем точное количество ссылок, значит время константное O(1), алгоритм выполнится за фиксированное количество шагов. Это не очень полезно, с точки зрения оценки алгоритма, но математика она такая :)
Мне нравится, как вопрос сложности разобран в книге Cracking the code interview.
Только ИТ это не только программисты, это и менеджеры и тестировщики, и прочие професии.
Разные професии, разные требования. Топовые программисты без требований сделают продукт хуже чем средненькие которые делают то, что нужно пользователям этого продукта.
Я не пользовался тем гитом который получился через неделю, но слышал, что пока оберток на перле типа git commit и git push не написали, то он был достаточно сложным и неудобным инструментом для ипользования.
Я не верю, что он написал гит за неделю. За неделю он написал код. В тот момент гит решал две проблемы, несовершенство всех существующих систем контроля версий и то, что у ядра не было возможности пользоваться системой контроля версий. Вторая послужила катализатором. Я думаю, что к этому моменту у него в голове уже было понимание какие фичи ему нужны. Так что, возможно, он гонял в голове эти идеи месяцев 5 по кругу, а потом когда приспичило взял и сделал.
На ассемблере можно написать всё, да, но то что на самом деле привнесли первые языки программирования -- новый способ мыслить о программах. Именно привнесли, а не ограничили.
Тут смешиваются два понятия: Возможность делать и способ мыслить. Да парадигмы это расширения способа мыслить, но при этом это ограничения возможности делать.
и их тестировать удобно можно и нужно, и часто без DI.
Для меня самый простой вид Dependency Injection это передача аргументов в функцию/конструктор. В таком контексте тесты без DI это редкость, и я бы их скорее компонентными или модульными назвал.
Одноразовый это всякие гуи, хендлеры взаимодействия и прочая бизнес логика которая вызывается из одного места для одной цели. Как правило у такого кода много зависимостей (от данных, от вью, особенностей местного законодательства, от чёрта лысого), нет смысла в рефакторинге, нет внятной спецификации.
У меня другая философия, для меня ядро системы это то, почему мы вообще затеяли проект: та самая бизнес логика. Всё остальное это адаптеры: обработчики сообщений, клиенты к другим сервисам, подключения к базам данных, библиотеки, утилиты. Все они имею смысл только в конексте бизнес логики.
В проекте должа быть изюминка. То, чем он отличается от другого или другими словами то почему покупка другого не решит проблему.
Именно эти бизнес требования и стоит покрывать тестами в первую очередь. Программисты не хотят разбираться с бизнесом и размазывают эту логику по хэндлерам, базам данных, и прочим библиотекам. Что делает код запутанным и плохо тестируемым.
Не всё на ГитХабе стоит брать в пример.
Асм это когда в регистр кладёш из регистра достаёшь и туда-сюда прыгаешь. Нет там циклов, это уже логическая структура поверх языка.
Я практически не пишу кода на Питоне, где такая ошибка может появится. Уже во многих мейнстримных языках есть итерация по коллекциям. В С++ на работе с индексами можно выиграть производительности, в Питоне скорее наоборот.
ООП это подход к организации кода. Наличие объектов и классов само по себе не является ООП. Можно даже делать ООП без них.
Методы и классы добавляют значительную долю удобства. В Питоне отличная система типов, но в ДС она не используется, в основном там работают с набором высоко-уровневых коллекций из сторонних библиотек.
Какие у вас проблемы с Series? Заведите два массива, один для данных другой для индекса, напишите функции для изменения, чтения, используйте доступ по номеру ячейки, держите их постоянно в согласованном состоянии. Всё будет явно и никаких классов и методов, IndexError получите в подарок.
В R тоже есть сложные типы.
Под оркестрацией я имею ввиду передачу данных в не питоновский код, где они будет обрабатываться на скоростях близких к C++. Например Pandas это Питон снаружи и С++ внутри. Данные хранятся в С++ структурах и вызывая методы в Питоне в делегируете операции в сишный код. Аналогично с декодированием видео, все операции происходят в сишном коде.
Где здесь функции? Это плохой код не потому, что он на Питоне, а потому что он плохо написан. Как это на R будет выглядеть?
Уберите всё мыло в отдельные функции и напишите логику человеческим языком.
У меня складывается ощущение, что вы сталкивались не с лучшим кодом на Питоне.
Возможности писать читаемый код на Питоне больше чем на R.
И еще много где. То есть вы пытаетесь охватить аудиторию вне домена ДС. Напоминаю, мы обсуждаем соответствие тэга статье.
Субъективное утверждение без контекста. pandas и numpy это то, где циклы применять не стоит. Это противоречит их основной идее.
Если здесь про подумать, тогда почему такой ограниченный выбор языков в тэгах? Циклы много где есть.
Часть задач решается используя особенности языка, вполне кукбуки. Для питона они не подходят. Решения через алгоритмы не привязаны к языку.
Если не секрет, R случайно не первый язык? Он достаточно специфичный, уклоном в оптимизацию. У меня был коллега который очень странный код на Питоне писал. Я понял почему только когда познакомился с R. В одной из первых строк статьи Вы пишите, "При работе с индексами цикла можно легко проглядеть и допустить ошибку". В контексте Питона это звучит странно, там сделано много, чтобы не работать с индексами напрямую.
Я hello word на многих языках писал, R очень специфичный. Он хорош для той области для которой он создавался.
Я хожу по краю ДС, поправьте меня, но там данные в основном в табличном виде, и парадигма ООП не особо используется. Или вы про DataModel?
Не надо обрабатывать питоном большие данные, он не для этого, им нужно оркестрировать обработку. Рекомендую посмотреть James Powell, он много рассказывает про "restricted computation domains".
Я взаимодействую с ребятами из ДС. Для них Питон это просто еще один инструмент, они освоили его на том уровне чтобы решать свои задачи. Знания языка порой на уровне джуна по Питону. Для работы с Pandas больше и не нужно.
Тэги расширяют охват аудитории. Но мне кажется такой маркетинговый ход не совсем правильный.
А для остальных уровней это переходит в категорию "личную жизнь".
Самообразование это не только книжки читать, это что-то своё пилить.
На меня его лекции тоже повлияли в положительную сторону.
Если в организации заботяться о соответствии нормам безопастности, то такой плагин не разрешат. Слать свои коментарии куда-то выглядит небезопасно.
Не аккуратно, опечатки. Не стоит торопиться показывать такой код.
Это видимо копипаста, откуда не нужно. six==1.16.0
Я стараюсь документировать код, а аннотиции типов это самая легкая форма документации.
Есть поддержка со стороны языка и инструментов.
Забыли сказать про главную проблему типизации.
Если объект на тип который вы ссылаетесь, еще не определён, можно его тип взять в кавычки.
Иногда аннотации позволяют выразить то, что сложно сделать в коде.
Mapping это неизменяемый словарь. Родной реализации такого словаря в Питоне нет, писать самому или устанавливать зависимости не всегода хочется.
В данном случае я явно указываю свои ожидания, что возвращаемое значние менять не надо.
Аннотации типов это просто фича языка, которая позволяет вам более точно выразить ваши ожидания от типов.
Для Питона, есть небольшая табличка со сложностью операций над основными структурами данных. https://wiki.python.org/moin/TimeComplexity
Что-то такое должно быть и для остальных языков.
Сортировка это слишком абстрактно. Quick sort да, merge sort нет.
Dictionary для этой здачи совсем не подходит по логике. Есть более простая структура данных, которые просто идеально подходит к данной задаче - set https://www.programiz.com/swift-programming/sets. Под капотом обычно тоже самое что в словаре, только без значений.
> Обозначение Big O нотация (или просто Big O) — это способ оценки относительной производительности структуры данных или алгоритма, обычно по двум осям: времени и пространству.
Это о сложности, а о времени. Да, некоторые закономерности прослеживаются.
Но вот контр пример, возьмем такую задачу: нужно нам обойти ровно миллион ссылок. Как не крути это долго. Раз мы знаем точное количество ссылок, значит время константное O(1), алгоритм выполнится за фиксированное количество шагов. Это не очень полезно, с точки зрения оценки алгоритма, но математика она такая :)
Мне нравится, как вопрос сложности разобран в книге Cracking the code interview.
Только ИТ это не только программисты, это и менеджеры и тестировщики, и прочие професии.
Разные професии, разные требования. Топовые программисты без требований сделают продукт хуже чем средненькие которые делают то, что нужно пользователям этого продукта.
>Торвальдс вон гит за неделю написал
Я не пользовался тем гитом который получился через неделю, но слышал, что пока оберток на перле типа git commit и git push не написали, то он был достаточно сложным и неудобным инструментом для ипользования.
Я не верю, что он написал гит за неделю. За неделю он написал код. В тот момент гит решал две проблемы, несовершенство всех существующих систем контроля версий и то, что у ядра не было возможности пользоваться системой контроля версий. Вторая послужила катализатором. Я думаю, что к этому моменту у него в голове уже было понимание какие фичи ему нужны. Так что, возможно, он гонял в голове эти идеи месяцев 5 по кругу, а потом когда приспичило взял и сделал.
Всегда считал, что для этого используются конечные автоматы.
Код с конечными автоматами получается хорошо структуированным и легко читается.
Я тоже прекрасно обходился, пока не научился писать простые юниттесты. После этого они стали нужны и полезны намного чаще.
Тут смешиваются два понятия: Возможность делать и способ мыслить. Да парадигмы это расширения способа мыслить, но при этом это ограничения возможности делать.
Для меня самый простой вид Dependency Injection это передача аргументов в функцию/конструктор. В таком контексте тесты без DI это редкость, и я бы их скорее компонентными или модульными назвал.
У меня другая философия, для меня ядро системы это то, почему мы вообще затеяли проект: та самая бизнес логика. Всё остальное это адаптеры: обработчики сообщений, клиенты к другим сервисам, подключения к базам данных, библиотеки, утилиты. Все они имею смысл только в конексте бизнес логики.
В проекте должа быть изюминка. То, чем он отличается от другого или другими словами то почему покупка другого не решит проблему.
Именно эти бизнес требования и стоит покрывать тестами в первую очередь. Программисты не хотят разбираться с бизнесом и размазывают эту логику по хэндлерам, базам данных, и прочим библиотекам. Что делает код запутанным и плохо тестируемым.