Форум сайта python.su
ToMaTkuH Как новичок в Python такому же новичку. Язык Python несравнимо вкусней по языковым возможностям, чем встроенный в Excel скриптовый язык VBA. И несмотря на это, конкретно твою задачу считаю правильней и быстрей решить на VBA. Я в нем очень хорошо разобрался. Вся фишка в том, что язык через COM очень глубоко завязан на снутренности программы, формально почти любые (к сожалению не 100% все) действия пользователя программно воспроизводимы, поэтому можно “включать запись” своей работы в программе, не зная деталей реализации объектной модели Excel, затем просматривать записанный скрипт, который автономно может воспроизвести то же, что и ты сделал “руками”, ну и соответственно корректировать эти подпрограммы. Быстрое простое вхождение + впечатляющий результат в короткий срок. Когда работаешь c Python-библиотекой, читающей и пишушей данные Excel, не завязанной на наличие установленной программы (без COM-интерфейса Excel), сразу лишаешься всех плюшек отладки - нельзя сходу на месте ошибки просмотреть точку данных, повлекшую ApplicationError, сходу не развенешь и пошагово не протрассируешь шаги выполнения с одномоментным просмотром результатов работы скрипта. А так да, вкусности баз данных, языка Python, хороши. Я думаю, что нормально работать с чтением-записью таблиц Excel можно только узнав работу VBA в Excel “изнутри”. Профи Python, поправьте меня пожалуста, если я где-то не прав.
Офлайн
mc-blackОки
Профи Python, поправьте меня пожалуста, если я где-то не прав
mc-blackТрудно согласиться. Может вам просто посмотреть отладчики и ide питона?
сразу лишаешься всех плюшек отладки
mc-blackОпять таки о чем речь? В питоне нет вкусностей с базами данных таких как linq который встроен в дотнет.
так да, вкусности баз данных, языка Python, хороши
mc-blackКонечно вопрос что такое по вашему “нормально”. Но на мой взгляд общая концепция программирования заключается в том чтобы рассматривать сущности с минимальными требованиями обеспечивающими решение задачи.
Я думаю, что нормально работать с чтением-записью таблиц Excel можно только узнав работу VBA в Excel “изнутри”
mc-blackCOM интерфейс в больших задачах по моему опыту практически неприменим в силу своей чудовищной тормознутости. Работал в основном с вордом, но не думаю что будет существенная разница.
не завязанной на наличие установленной программы (без COM-интерфейса Excel)
Отредактировано doza_and (Окт. 21, 2019 05:50:45)
Офлайн
mc-blackПро юнит-тесты когда-нибудь слышал?
Профи Python, поправьте меня пожалуста, если я где-то не прав.
Отредактировано py.user.next (Окт. 21, 2019 03:11:23)
Офлайн
py.user.nextДа слышал немного про написание тестов для JavaScript. И про JUnit в Java. Но пока не использовал. Написание тестов к сильно ускорит написание обработчика данных в Excel в Python? В VBA юнит-тестирования нет - breakpoins, просмотр переменных, просмотр стека вызовов. Ещё ошибки здорово помогает искать строгая типизация данных, если её включить Option Explicit.
Про юнит-тесты когда-нибудь слышал?
doza_andПисать на VBA - не значит тыкать по кнопкам. И да, это тоже язык программирования. Не настолько совершенный как Python, но хорошо заточенный под простые задачи по уровню немного сложней написания формул. Кстати большинство рабочих задач решаю 2 формулами: СУММЕСЛИМН и ВПР.
обычно надо решить задачу, а это далеко не одно и тоже что тыкать по кнопкам, поскольку язык высокого уровня позволяет выразить более сложные мысли. Для этого собственно VBA и есть, а то были-бы одни макросы.
doza_and“если” здесь ключевое слово. Знаешь, что к листам Excel без мусора можно применять запрос без csv, sqlite? Через odbc-драйвер Excel. Но как-то не прижилось из-за пресловутого “если”.
и код будет проще если не будет в нем мусора
doza_andНакладные расходы технологии, понятно. Обработка Excel - это маленькие задачи. И есть пара трюков, чтобы резко повысить скрость вычислений в VBA. На время процедуры отключаешь вычисление формул, прорисовку окон, механизм событий. Потом включаешь. Чего недостает VBA - это списков, кортежей, словарей со срезами и т.п. Есть словарь, который подключаешь из библиотеки, распространены коллекции (типа списков, но не 1к1). Дико тупые массивы и запутывающий динамический тип Variant.
COM интерфейс в больших задачах по моему опыту практически неприменим в силу своей чудовищной тормознутости. Работал в основном с вордом, но не думаю что будет существенная разница.
Офлайн
mc-blackЭто относится не к языкам, а вообще к программированию 21-го века.
Да слышал немного про написание тестов для JavaScript. И про JUnit в Java.
mc-blackВидимо, ты не очень понял, что я написал выше. Без юнит-тестов ты можешь делать только наброски. Когда же речь пойдёт о том, чтобы опереться на какой-то код и построить на нём какую-то систему, то у тебя просто не будет времени проверять этот код, который ты просто используешь. А если вдруг ты найдёшь ошибку у себя в коде, на котором уже что-то построено, то ты должен будешь всё бросить и сидеть её исправлять.
Написание тестов к сильно ускорит написание обработчика данных в Excel в Python?
Отредактировано py.user.next (Окт. 22, 2019 01:55:10)
Офлайн
mc-blackНу, что же, вполне логично, если ToMaTkuH знает этот язык. Есть ещё минус, как уже говорили, что com может тормозить. Это не критично, если в таблицы мелкие и их несколько штук. Если там много данных или таблиц много, то уже ощутимы будут тормоза. Ещё один, может быть не очень существенный минус: скрипт VBA будет работать только под вендой.
конкретно твою задачу считаю правильней и быстрей решить на VBA
Отредактировано Rafik (Окт. 22, 2019 13:41:55)
Офлайн
py.user.nextКак раз пишу такую. База sqlite3 на python3 с консольным интерфейсом. Очень слабо пока пользуюсь возможностями языка. Строк сильно меньше 1000, больших сложностей нет. Очень мало вермени могу уделять этому увлечению. Что посоветуете почесть про unit-тестирование кода в Python?
Напиши программу, где чистого кода на тысячу строк хотя бы.
RafikСогласен.
Разработка такого скрипта даст ему возможность пополнить свои знания и умения.
Отредактировано mc-black (Окт. 23, 2019 22:18:43)
Офлайн
mc-black
Сейчас придерживаюсь мнения, что код надо хорошо структурировать и рефакторить, новые процедуры требуют проверки работы в режиме отладки.
Офлайн
mc-blackЕсть книжка бесплатная Dive Into Python 3. В ней есть хорошая глава по юнит-тестированию с примером.
Что посоветуете почесть про unit-тестирование кода в Python?
mc-blackНа баге никогда не написано, когда он всплывёт. Но каждый всплывший баг надо исправлять.
Тем не менее был 1 редко воспроизводимый баг
mc-blackВот чтобы рефакторить, нужно сделать юнит-тесты. Нельзя переделать функцию, не проверив все её похождения после переделки. Если же алгоритм ещё не простой, то юнит-тесты тем более нужны. Когда такое происходит, сначала пишешь все юнит-тесты, а потом пишешь функцию. И потом уже, когда ты будешь писать функцию, ты будешь запускать готовые юнит-тесты раз за разом, пока функция не будет работать правильно во всех своих закутках (пока все юнит-тесты не напишут OK зелёным цветом).
Сейчас придерживаюсь мнения, что код надо хорошо структурировать и рефакторить, новые процедуры требуют проверки работы в режиме отладки.
Отредактировано py.user.next (Окт. 26, 2019 12:49:07)
Офлайн
py.user.next
doza_and
RafikУважаемые, спасибо развернуютую за обратную связь! Это ценно.
Отредактировано mc-black (Окт. 26, 2019 10:12:16)
Офлайн