Python-сообщество

ToMaTkuH Как новичок в Python такому же новичку. Язык Python несравнимо вкусней по языковым возможностям, чем встроенный в Excel скриптовый язык VBA. И несмотря на это, конкретно твою задачу считаю правильней и быстрей решить на VBA. Я в нем очень хорошо разобрался. Вся фишка в том, что язык через COM очень глубоко завязан на снутренности программы, формально почти любые (к сожалению не 100% все) действия пользователя программно воспроизводимы, поэтому можно “включать запись” своей работы в программе, не зная деталей реализации объектной модели Excel, затем просматривать записанный скрипт, который автономно может воспроизвести то же, что и ты сделал “руками”, ну и соответственно корректировать эти подпрограммы. Быстрое простое вхождение + впечатляющий результат в короткий срок. Когда работаешь c Python-библиотекой, читающей и пишушей данные Excel, не завязанной на наличие установленной программы (без COM-интерфейса Excel), сразу лишаешься всех плюшек отладки - нельзя сходу на месте ошибки просмотреть точку данных, повлекшую ApplicationError, сходу не развенешь и пошагово не протрассируешь шаги выполнения с одномоментным просмотром результатов работы скрипта. А так да, вкусности баз данных, языка Python, хороши. Я думаю, что нормально работать с чтением-записью таблиц Excel можно только узнав работу VBA в Excel “изнутри”. Профи Python, поправьте меня пожалуста, если я где-то не прав.

mc-black
Профи Python, поправьте меня пожалуста, если я где-то не прав

Оки
Если надо воспроизводить то что делается ручками то у VBA есть преимущества.

Вот только незадача, обычно надо решить задачу, а это далеко не одно и тоже что тыкать по кнопкам, поскольку язык высокого уровня позволяет выразить более сложные мысли. Для этого собственно VBA и есть, а то были-бы одни макросы.

mc-black
сразу лишаешься всех плюшек отладки

Трудно согласиться. Может вам просто посмотреть отладчики и ide питона?

mc-black
так да, вкусности баз данных, языка Python, хороши

Опять таки о чем речь? В питоне нет вкусностей с базами данных таких как linq который встроен в дотнет.

mc-black
Я думаю, что нормально работать с чтением-записью таблиц Excel можно только узнав работу VBA в Excel “изнутри”

Конечно вопрос что такое по вашему “нормально”. Но на мой взгляд общая концепция программирования заключается в том чтобы рассматривать сущности с минимальными требованиями обеспечивающими решение задачи.

Если вам надо работать с таблицей и посчитать сумму, забудьте о том что файле экселя много таблиц, что ячейки могут быть разных цветов, текст разных кодировок и прочую ерунду. Тогда не прийдется сильно курочить код при переходе к sqlite или csv а и код будет проще если не будет в нем мусора.

mc-black
не завязанной на наличие установленной программы (без COM-интерфейса Excel)

COM интерфейс в больших задачах по моему опыту практически неприменим в силу своей чудовищной тормознутости. Работал в основном с вордом, но не думаю что будет существенная разница.

Отредактировано doza_and (Окт. 21, 2019 05:50:45)

mc-black
Профи Python, поправьте меня пожалуста, если я где-то не прав.

Про юнит-тесты когда-нибудь слышал?

Вот ты сделал в книге Excel ковертер валюты, например. Он принимает одну валюту и возвращает другую. Как узнать, что он работает без ошибок? Его надо сидеть и проверять. Ну, ты проверишь. А вот теперь представь десять конвертеров валют в одной книге. Как узнать, что они работают без ошибок? Их надо сидеть и проверять. Ну, ты уже проверишь их за гораздо большее время. А вот теперь представь, что ты всё проверил и тут у тебя возникает идея “а что если соединить некоторые конвертеры друг с другом?”. Конечно, ты не будешь это делать, потому что проверять потом снова эти функции три дня ты не будешь. И вот так максимум, что у тебя получится, - маленькая программка, которую чисто вручную получилось проверить.

А в питоне есть юнит-тесты - это такие маленькие роботы, проверяющие программу вместо тебя; и не за три дня, а за три миллисекунды. Поэтому в питоне можно написать одну программу, другую программу, а потом соединить их вместе. А потом можно соединять соединённые программы друг с другом.

Отредактировано py.user.next (Окт. 21, 2019 03:11:23)

py.user.next
Про юнит-тесты когда-нибудь слышал?

Да слышал немного про написание тестов для JavaScript. И про JUnit в Java. Но пока не использовал. Написание тестов к сильно ускорит написание обработчика данных в Excel в Python? В VBA юнит-тестирования нет - breakpoins, просмотр переменных, просмотр стека вызовов. Ещё ошибки здорово помогает искать строгая типизация данных, если её включить Option Explicit.

Основной плюс VBA по-моему в том, что Excel уже открыт c данными и дело пары кликов найти ячейку данных вызывающую ошибку обработки - даже чисто визуально. Можно программно переместить фокус на лист и диапазон, который вызывает исключение. При работе с IDE я буду пялиться в консоль и мысленно представлять, на каком это листе какой диапазон из чего состоит и какие ячейки вокруг и где ячейки объединены и т.п. Качественно организованные данные в Excel - редкость, часто надо обработать какой-нибудь трэш.

doza_and
обычно надо решить задачу, а это далеко не одно и тоже что тыкать по кнопкам, поскольку язык высокого уровня позволяет выразить более сложные мысли. Для этого собственно VBA и есть, а то были-бы одни макросы.

Писать на VBA - не значит тыкать по кнопкам. И да, это тоже язык программирования. Не настолько совершенный как Python, но хорошо заточенный под простые задачи по уровню немного сложней написания формул. Кстати большинство рабочих задач решаю 2 формулами: СУММЕСЛИМН и ВПР.

doza_and
и код будет проще если не будет в нем мусора

“если” здесь ключевое слово. Знаешь, что к листам Excel без мусора можно применять запрос без csv, sqlite? Через odbc-драйвер Excel. Но как-то не прижилось из-за пресловутого “если”.

doza_and
COM интерфейс в больших задачах по моему опыту практически неприменим в силу своей чудовищной тормознутости. Работал в основном с вордом, но не думаю что будет существенная разница.

Накладные расходы технологии, понятно. Обработка Excel - это маленькие задачи. И есть пара трюков, чтобы резко повысить скрость вычислений в VBA. На время процедуры отключаешь вычисление формул, прорисовку окон, механизм событий. Потом включаешь. Чего недостает VBA - это списков, кортежей, словарей со срезами и т.п. Есть словарь, который подключаешь из библиотеки, распространены коллекции (типа списков, но не 1к1). Дико тупые массивы и запутывающий динамический тип Variant.

mc-black
Да слышал немного про написание тестов для JavaScript. И про JUnit в Java.

Это относится не к языкам, а вообще к программированию 21-го века.

mc-black
Написание тестов к сильно ускорит написание обработчика данных в Excel в Python?

Видимо, ты не очень понял, что я написал выше. Без юнит-тестов ты можешь делать только наброски. Когда же речь пойдёт о том, чтобы опереться на какой-то код и построить на нём какую-то систему, то у тебя просто не будет времени проверять этот код, который ты просто используешь. А если вдруг ты найдёшь ошибку у себя в коде, на котором уже что-то построено, то ты должен будешь всё бросить и сидеть её исправлять.

Так что, конечно, ты будешь в десять раз больше времени тратить на код без юнит-тестов, чем на код с юнит-тестами. Тут дело в том, что тебе придётся каждый раз снова пересматривать функции, которые ты уже смотрел до этого. Из-за любой ошибки ты будешь увязать в коде, как в болоте. А чем больше он будет становиться, тем больше будет это время увязания. И если раньше ты исправлял ошибку или менял что-то в программе за один час, то через месяц разработки ты уже будешь исправлять ошибку или менять что-то в программе минимум за неделю.

Я тебе просто могу посоветовать написать хоть что-то. Напиши программу, где чистого кода на тысячу строк хотя бы. Прямо на VB можешь писать, он работает и без Microsoft Office. Думаю, ты в такой маленькой программке очень быстро столкнёшься со стандартными проблемами и забросишь её как тупиковую.


tags: unittest

Отредактировано py.user.next (Окт. 22, 2019 01:55:10)

mc-black
конкретно твою задачу считаю правильней и быстрей решить на VBA

Ну, что же, вполне логично, если ToMaTkuH знает этот язык. Есть ещё минус, как уже говорили, что com может тормозить. Это не критично, если в таблицы мелкие и их несколько штук. Если там много данных или таблиц много, то уже ощутимы будут тормоза. Ещё один, может быть не очень существенный минус: скрипт VBA будет работать только под вендой.
На мой взгляд, намного проще обойтись библиотечкой для питона и сваять простенький скрипт, который никак не будет привязан к MS офису и конкретно к ОС win. Скрипт будет кроссплатформенным. Если дома нет венды и надо обработать документы, то можно будет и в другой ОС это сделать с успехом, без всяких танцев. Есть один хороший плюс такого подхода (написание скрипта на питоне): ТС уже немного знает язык и стремится освоить его. Разработка такого скрипта даст ему возможность пополнить свои знания и умения.

Отредактировано Rafik (Окт. 22, 2019 13:41:55)

py.user.next
Напиши программу, где чистого кода на тысячу строк хотя бы.

Как раз пишу такую. База sqlite3 на python3 с консольным интерфейсом. Очень слабо пока пользуюсь возможностями языка. Строк сильно меньше 1000, больших сложностей нет. Очень мало вермени могу уделять этому увлечению. Что посоветуете почесть про unit-тестирование кода в Python?

Больше, чем на 1000 строк я написал только одну программку на Masm32+Win32 API. В отадчик смотреть приходилось больше, чем в редактор. Размеется ни о каком юнит-тестировании речь не шла. Минимально логировал. Тестировал запуском GIU и в Olly Debug глазами и руками. На проект у меня было неограниченное количество времени. Тем не менее был 1 редко воспроизводимый баг, который в итоге так и не нашел. Как тестировать код я понятия тогда не имел (и смутно имею до сих пор). Баг воспроизводился у меня только моими руками с очень малой вероятностью. До последнего времени полагал, что тестирование - тема сложных коммерческих проектов. Сейчас придерживаюсь мнения, что код надо хорошо структурировать и рефакторить, новые процедуры требуют проверки работы в режиме отладки.

Rafik
Разработка такого скрипта даст ему возможность пополнить свои знания и умения.

Согласен.

Отредактировано mc-black (Окт. 23, 2019 22:18:43)

mc-black
Сейчас придерживаюсь мнения, что код надо хорошо структурировать и рефакторить, новые процедуры требуют проверки работы в режиме отладки.

:) Далее мои банальные думы.

Для разных проектов подходят разные методы. Пару чисел сложить можно в калькуляторе. Пару строк попарно в Экселе. Обычно чем больше код тем сложнее методы.

Рефакторить? Режим отладки? В больших проектах такое редкость. Вы перечисляете пожарные меры исправления грубых ошибок, которые в большом проекте обычно не допускают.

mc-black
Что посоветуете почесть про unit-тестирование кода в Python?

Есть книжка бесплатная Dive Into Python 3. В ней есть хорошая глава по юнит-тестированию с примером.
В разные годы она доступна по разным адресам в инете. Можно скачать и в виде pdf. В html её удобнее читать (можно делать закладки).
https://diveintopython3.problemsolving.io/unit-testing.html
https://diveinto.org/python3/unit-testing.html

А вообще по юнит-тестированию есть центральная книжка. Я её не читал ещё и не помню, как она называется и кто автор. Там описано в общем виде, как делать качественные юнит-тесты и как делать все юнит-тесты. В юнит-тестировании проблемы в основном такие: какие тесты делать; сколько тестов делать; какие тесты не делать; как вспомнить, какие тесты уже сделаны; как вспомнить, какие тесты ещё не сделаны.

В питоне можешь использовать для юнит-тестирования пакеты в порядке стадий от начинающий к профессионал: doctest (встроенный), unittest (встроенный), py.test (надо установить).

mc-black
Тем не менее был 1 редко воспроизводимый баг

На баге никогда не написано, когда он всплывёт. Но каждый всплывший баг надо исправлять.

mc-black
Сейчас придерживаюсь мнения, что код надо хорошо структурировать и рефакторить, новые процедуры требуют проверки работы в режиме отладки.

Вот чтобы рефакторить, нужно сделать юнит-тесты. Нельзя переделать функцию, не проверив все её похождения после переделки. Если же алгоритм ещё не простой, то юнит-тесты тем более нужны. Когда такое происходит, сначала пишешь все юнит-тесты, а потом пишешь функцию. И потом уже, когда ты будешь писать функцию, ты будешь запускать готовые юнит-тесты раз за разом, пока функция не будет работать правильно во всех своих закутках (пока все юнит-тесты не напишут OK зелёным цветом).

Отредактировано py.user.next (Окт. 26, 2019 12:49:07)

py.user.next

doza_and

Rafik

Уважаемые, спасибо развернуютую за обратную связь! Это ценно.
Продолжу нарабатывать свою первую Python-программу от 1000 строк кода, писать unit-тесты и перенимать практики серьезного промышленного кодинга в свой хобби-проект. Все-таки путь в 1000 ли начинается c одного шага (оптимально - в нужном направлении).

Отредактировано mc-black (Окт. 26, 2019 10:12:16)