Чем питон для данных отличается от учебного
Python для ИИ с нуля · Урок 1 / 22
Два разных питона
В учебниках питон выглядит так: переменная, цикл, функция, задача про факториал. В работе с данными и моделями вы пишете совсем другой код. Он короче, он почти целиком состоит из вызовов чужих библиотек, и главная его сложность — не алгоритм, а то, что данные внутри оказываются не такими, как вы думали.
Типичный рабочий скрипт — тридцать строк: прочитать файл, привести пару колонок к нужному типу, отфильтровать, сгруппировать, сохранить результат. Ни одного собственного цикла. Зато три места, где всё может тихо поехать: кодировка файла, тип колонки и то, что фильтр вернул копию, а вы правите её и удивляетесь, почему исходник не меняется.
Что это меняет на практике
- Правильность важнее скорости написания. Скрипт, который отработал за секунду и выдал неверную сумму, хуже, чем скрипт, который упал.
- Читаемость важнее краткости. Однострочник из пяти вложенных генераторов вы не поймёте через месяц, а вернуться к анализу придётся почти наверняка.
- Промежуточный вывод — часть кода. После каждого нетривиального шага вы смотрите на форму данных, а не верите, что всё прошло.
- Код живёт дольше, чем кажется. «Разовый» скрипт для отчёта обычно запускают ещё раз через квартал — и это делаете вы же.
Минимальный ритуал проверки
Возьмите привычку после загрузки данных всегда выполнять три строки. Они занимают пять секунд и ловят большинство глупых ошибок:
print(df.shape) # сколько строк и колонок реально пришло print(df.dtypes) # какие типы у колонок print(df.head(3)) # как выглядят первые строки
Если строк 0 — путь или фильтр неверный. Если числовая колонка имеет тип object — в ней где-то текст, запятая вместо точки или пробел. Если колонок больше, чем ожидали, — в файле лишний разделитель.
Проверка на маленьком известном примере
Самая полезная привычка курса: прежде чем гнать расчёт на полном датасете, соберите крошечный пример, где вы знаете ответ руками. Пять строк, где среднее равно 10, а групп две. Если ваш код на нём даёт 10 и две группы — можно запускать на реальных данных. Если нет — вы поймали баг за минуту, а не через неделю в отчёте.
Это же правило спасает при работе с ИИ-ассистентом. Модель пишет синтаксически корректный код почти всегда. Логически верный — существенно реже. Проверка на известном примере — единственный дешёвый способ отличить одно от другого.
Шпаргалка
- Рабочий код для данных — это склейка библиотек, а не алгоритмы.
- После каждой загрузки смотрите shape, dtypes, head.
- Маленький пример с известным ответом ловит больше багов, чем чтение кода.
- Читает ваш код в основном будущий вы — пишите для него.