> You can learn to use Python and see almost immediate gains in productivity and lower maintenance costs.
Это типиичная ниша для языка, взять разные инструменты и собрать из них что то новое.
> Так что, по сути, название "создаём ******* с помощью Python" – кликбейт
Реклама, маркетинг, один раз без асбеста, всегда без асбеста.
Язык в общем-то тут действительно вторичен, но вот экосистема играет важную роль. Я не в курсе про аналоги streamlit на Java, C++ и других мейнстримных языках. Может что-то на javascrit совместимых языках есть.
Этот код аналог второго примера. А сложность она вся в третьем.
Контекст сириус бизнес, это готовность к изменениям. Под готовностью для изменений я подразумеваю возможность добавлять новый функционал, не трогая существующий.
Ваш пример решает текущую задачу в этом контексте он хороший. Но если его понадобится сильно расширить, то в этом контексте я бы назвал его плохим. Добавляя в него новые фичи без рефакторинга, вы получите крупный монолит.
Я не вижу особого отличия от того, чтобы вызвать функцию или создать экземпляр класса и вызвать его метод. Немного по разному код скомпонован, но верхнеуровневая функция жестко зависит от внешнего кода и там, и там.
В функции есть три подвижные части, которые могут менять по разным причинам: upload/download/logic
test_api(requests_mock)
В данном тесте мы мокаем 2 из них да и еще и одинаковым моком. То есть после развития этого кода, окажется, что в каждый тест надо 2-3 мока передавать. Для дальгейшего развития такой подход обернется адом. Так же это плохо паралелится, один человек меняет загрузку , другой скачивание и оба тесты.
3 подвижных части, даже если взять по 2 варианте, успех и ошибка, то это 8 сценариев для outside-in тестирования. Логичекси исключим сценарии после ошибки, будет 5 тестов. Для 100% покрытия важной логики такой подход мне кажется сложным, количество тестов растёт экспоненциально относительно подвижных частей.
Кроме наследования, всё остальные столпы ООП в коде пристутствуют.
Когда руками зависимости собираешь, то без разницы что передавать функцию или класс. В примере я использую функции, а по жизни часто callable классы, их настраивать удобно.
Для аннотаций типов использую Protocol, тогда анализаторы принимают и класс и функцию.
from typing import Protocol
class Uploader(Protocol):
def __call__(self, path, data):
...
class UploadClass(Protocol):
def __init__(self, session):
self._sesion = session
def __call__(self, path, data):
return self._sesion.post(path, data)
У меня проблема с Series ровно одна -- он безумно заморочный. Я привык к malloc и понятному и честному представлению массивов в памяти. Series -- это объект со своим барахлом. Вы, наверное, с ndarray спутали. Series для расчетов -- медленно, неудобно, заморочно.
Без контекста сложно ответить. Series это прежде всего индекс к данным. Под капотом там врде несколько ndarray
но его и писали астрономы а не недотыкомки аналитики
Как только производительнось выходит на первый план, код и апи сильно проседают по простоте и удобству. Про BlockManager почитаю. Врядли ужаснусь, я уже много разного кода видел.
Я регулярно привожу примеры. И почти всегда пример на R круче питонского.
А можно пару ссылок? По моим наблюдениям большая часть программистов пишет непонятный код. В ДС с этим должно быть еще хуже. По уму сравнивать нужно код одного качества, но что такое качество это сильно субъективно. В ДС уже сложились некоторые традиции, которые меня с точки зрения Питона несколько огорчают. `from pandas import DataFrame` выглядит лучше, чем то, что приянто.
Питон же в DS имеет огромное количество архитектурных изъянов.
Языку широкого профиля сложно тягаться с узкоспециализированным.
Уточню, вы имеет именно Питон как язык или тот инструментарий для ДС который для него существует? В R базовые инструменты являются частью языка.
Утверждение про циклы (да 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 это неизменяемый словарь. Родной реализации такого словаря в Питоне нет, писать самому или устанавливать зависимости не всегода хочется.
В данном случае я явно указываю свои ожидания, что возвращаемое значние менять не надо.
Программирование это инструмент для решения задач, решая маленькие задачи не научишься решать большие.
Это и есть тот самый опыт который можно получить решая такие задачки.
Они не сложные, они объемные. Даже глубокого знания Питона не требуется. И да обучение программированию требует огромного количества времени.
Как-то давно игрался с ним. Мне бы не хватило терпения что-то такое на нем сделать.
Если у вас есть проект со смыслом, тут вообще все средства хороши.
Мне важно, чтобы результат приятно смотрелся, и организацию этого уходит 80% времени.
Обычно стараюсь смотреть на что-то высоко-уровневое, когда ты декларируешь что нужно показать, а как именно делает за тебя библиотека.
Что-то типа https://github.com/chriskiehl/Gooey или того-же стримлита.
Я бы GUI выкинул: и скучно и нудно и, мне кажется, не перспективно. Вот консольные приложения было бы полезно.
В плане визуализации я сейчас начал экспериментировать с https://streamlit.io/. Просто и симпатично.
Это как раз и есть программирование на Питоне.
Вот что на https://www.python.org написанно:
> You can learn to use Python and see almost immediate gains in productivity and lower maintenance costs.
Это типиичная ниша для языка, взять разные инструменты и собрать из них что то новое.
> Так что, по сути, название "создаём ******* с помощью Python" – кликбейт
Реклама, маркетинг, один раз без асбеста, всегда без асбеста.
Язык в общем-то тут действительно вторичен, но вот экосистема играет важную роль. Я не в курсе про аналоги streamlit на Java, C++ и других мейнстримных языках. Может что-то на javascrit совместимых языках есть.
Хорошая реклама, это когда её почти не заметно.
Спасибо, чуть упростил.
Мне тоже понравилось.
Этот код аналог второго примера. А сложность она вся в третьем.
Контекст сириус бизнес, это готовность к изменениям. Под готовностью для изменений я подразумеваю возможность добавлять новый функционал, не трогая существующий.
Ваш пример решает текущую задачу в этом контексте он хороший. Но если его понадобится сильно расширить, то в этом контексте я бы назвал его плохим. Добавляя в него новые фичи без рефакторинга, вы получите крупный монолит.
Я не вижу особого отличия от того, чтобы вызвать функцию или создать экземпляр класса и вызвать его метод. Немного по разному код скомпонован, но верхнеуровневая функция жестко зависит от внешнего кода и там, и там.
В функции есть три подвижные части, которые могут менять по разным причинам: upload/download/logic
В данном тесте мы мокаем 2 из них да и еще и одинаковым моком. То есть после развития этого кода, окажется, что в каждый тест надо 2-3 мока передавать. Для дальгейшего развития такой подход обернется адом. Так же это плохо паралелится, один человек меняет загрузку , другой скачивание и оба тесты.
3 подвижных части, даже если взять по 2 варианте, успех и ошибка, то это 8 сценариев для outside-in тестирования. Логичекси исключим сценарии после ошибки, будет 5 тестов.
Для 100% покрытия важной логики такой подход мне кажется сложным, количество тестов растёт экспоненциально относительно подвижных частей.
Кроме наследования, всё остальные столпы ООП в коде пристутствуют.
Когда руками зависимости собираешь, то без разницы что передавать функцию или класс. В примере я использую функции, а по жизни часто callable классы, их настраивать удобно.
Для аннотаций типов использую Protocol, тогда анализаторы принимают и класс и функцию.
Поменьше.
Без контекста сложно ответить. Series это прежде всего индекс к данным. Под капотом там врде несколько
ndarrayКак только производительнось выходит на первый план, код и апи сильно проседают по простоте и удобству. Про BlockManager почитаю. Врядли ужаснусь, я уже много разного кода видел.
А можно пару ссылок? По моим наблюдениям большая часть программистов пишет непонятный код. В ДС с этим должно быть еще хуже. По уму сравнивать нужно код одного качества, но что такое качество это сильно субъективно.
В ДС уже сложились некоторые традиции, которые меня с точки зрения Питона несколько огорчают. `from pandas import DataFrame` выглядит лучше, чем то, что приянто.
Языку широкого профиля сложно тягаться с узкоспециализированным.
Уточню, вы имеет именно Питон как язык или тот инструментарий для ДС который для него существует? В R базовые инструменты являются частью языка.
Не всё на ГитХабе стоит брать в пример.
Асм это когда в регистр кладёш из регистра достаёшь и туда-сюда прыгаешь. Нет там циклов, это уже логическая структура поверх языка.
Я практически не пишу кода на Питоне, где такая ошибка может появится. Уже во многих мейнстримных языках есть итерация по коллекциям. В С++ на работе с индексами можно выиграть производительности, в Питоне скорее наоборот.
ООП это подход к организации кода. Наличие объектов и классов само по себе не является ООП. Можно даже делать ООП без них.
Методы и классы добавляют значительную долю удобства. В Питоне отличная система типов, но в ДС она не используется, в основном там работают с набором высоко-уровневых коллекций из сторонних библиотек.
Какие у вас проблемы с 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 это неизменяемый словарь. Родной реализации такого словаря в Питоне нет, писать самому или устанавливать зависимости не всегода хочется.
В данном случае я явно указываю свои ожидания, что возвращаемое значние менять не надо.