[TASK] Python (https://github.com/SENATOROVAI/python/issues/1)#503
Open
oh-ddy wants to merge 25 commits intoSENATOROVAI:mainfrom
Open
[TASK] Python (https://github.com/SENATOROVAI/python/issues/1)#503oh-ddy wants to merge 25 commits intoSENATOROVAI:mainfrom
oh-ddy wants to merge 25 commits intoSENATOROVAI:mainfrom
Conversation
Прогнал на нем все линтеры, описал по датам что нового узнал
- Добавлены файлы окружений: requirements.txt, environment.yml - Обновлён .gitignore для игнорирования локальных зависимостей - Подготовка к воспроизводимой настройке проекта
oh-ddy
commented
Dec 10, 2025
Comment on lines
+1
to
+245
| """Choosing understandable names.""" | ||
|
|
||
| # *Имена формально называются идентификаторами* | ||
| # | ||
| # | ||
| # ### Схемы регистра имен | ||
| # | ||
| # | ||
| # Так как в идентификаторах Python различается регистр символов и они не могут содержать пробельные | ||
| # символы, программисты используют несколько схем в идентификаторах, состоящих из нескольких слов. | ||
| # | ||
| # | ||
| # 1. Змеиный регистр (snake_case) разделяет слова символом подчеркивания, который напоминает ползущую | ||
| # между словами змею. В этом случае все буквы записываются в нижнем регистре, а константы часто | ||
| # записываются в верхнем змеином регистре (UPPER_SNAKE_CASE). | ||
| # | ||
| # 2. Верблюжий регистр (camelCase) — слова записываются в нижнем регистре, но второе и следующие | ||
| # слова начинаются с заглавной. Эта схема в большин- | ||
| # стве случаев подразумевает, что первое слово начинается с буквы нижнего регистра. | ||
| # Буквы верхнего регистра напоминают верблюжьи горбы. | ||
| # | ||
| # 3. Схема Pascal (PascalCase) — названа так, потому что применяется в языке программирования Pascal | ||
| # Аналогична схеме верблюжьего регистра, но первое слово в ней тоже начинается с заглавной. | ||
| # | ||
| # | ||
| # ### Соглашения об именах PEP 8 | ||
| # | ||
| # | ||
| # - **Символы в идентификаторах**: | ||
| # - Должны быть **ASCII-символами** (латинские буквы без диакритических знаков) | ||
| # | ||
| # | ||
| # - **Стили именования**: | ||
| # - **Модули**: короткие, только строчные буквы (`lowercase`) | ||
| # - **Классы**: записываются в **PascalCase** (CapWords). | ||
| # - **Константы**: записываются в **UPPER_SNAKE_CASE** (все заглавные с подчёркиваниями). | ||
| # - **Функции, методы и переменные**: записываются в **snake_case** (строчные с подчёркиваниями). | ||
| # | ||
| # | ||
| # - **Специальные аргументы**: | ||
| # - Первый аргумент **метода экземпляра** — всегда `self` (в нижнем регистре) | ||
| # - Первый аргумент **метода класса** — всегда `cls` (в нижнем регистре) | ||
| # | ||
| # | ||
| # - **Атрибуты классов**: | ||
| # - **Приватные** атрибуты начинаются с символа подчёркивания (`_`) | ||
| # - **Публичные** атрибуты **не начинаются** с подчёркивания | ||
| # | ||
| # | ||
| # - **Гибкость применения правил**: | ||
| # - PEP 8 **не обязателен к неукоснительному соблюдению** | ||
| # - Допустимо использовать идентификаторы на других языках | ||
| # - Можно использовать другие стили (например, camelCase), если это улучшает читаемость | ||
| # | ||
| # - **Главный принцип читаемости**: | ||
| # - Важнее не выбор конкретной схемы именования, а **последовательность её применения** в рамках проекта или модуля | ||
| # | ||
| # | ||
| # ### Длина имен | ||
| # | ||
| # | ||
| # **Рекомендации по выбору имён переменных и функций** | ||
| # | ||
| # **Общий принцип** | ||
| # - Код читают чаще, чем пишут → **предпочтение более длинным, понятным именам**, | ||
| # даже если их дольше вводить | ||
| # | ||
| # | ||
| # **Слишком короткие имена — проблема читаемости** | ||
| # | ||
| # | ||
| # - **Одно- или двухбуквенные имена** (например, `g`) неясны: неизвестно, какое слово они обозначают | ||
| # | ||
| # | ||
| # - **Сокращения** (`mon` → monitor/month/monster?) вводят в заблуждение | ||
| # | ||
| # | ||
| # - **Однословные имена** (`start`) не указывают контекст: начало чего? | ||
| # | ||
| # | ||
| # - Такие имена могут быть понятны автору в момент написания, | ||
| # но **непонятны другим или самому через время** | ||
| # | ||
| # | ||
| # **Допустимые исключения для коротких имён** | ||
| # | ||
| # | ||
| # - `i`, `j`, `k` — для индексов в циклах `for` | ||
| # | ||
| # | ||
| # - `x`, `y` — для декартовых координат | ||
| # | ||
| # | ||
| # - Иногда допустимы `w`/`h` (width/height) или `n` (number), | ||
| # но это **не всегда очевидно** другим | ||
| # | ||
| # | ||
| # **Слишком длинные имена — когда это оправдано** | ||
| # | ||
| # | ||
| # - Чем **шире область видимости** (например, глобальная переменная в большом проекте), | ||
| # тем **более содержательным должно быть имя** | ||
| # | ||
| # | ||
| # - Пример: `payment` — нормально для локальной переменной; | ||
| # `salesClientMonthlyPayment` — лучше для глобального контекста | ||
| # | ||
| # | ||
| # - **Уточняющие слова устраняют неоднозначность** → лучше перестраховаться, чем недоговорить | ||
| # | ||
| # | ||
| # **Не пропускайте буквы** | ||
| # | ||
| # | ||
| # - Имена вроде `memcpy` или `strcmp` (из C) **устарели** и плохо читаются | ||
| # | ||
| # | ||
| # - Имя должно быть **произносимым и понятным** | ||
| # | ||
| # | ||
| # - Предпочтение **естественным фразам**: `number_of_trials` лучше, чем `number_trials` | ||
| # | ||
| # | ||
| # **Префиксы: когда полезны, а когда избыточны** | ||
| # | ||
| # | ||
| # - **Избыточные префиксы**: | ||
| # - `catWeight` в классе `Cat` — излишне, так как `weight` и так относится к кошке | ||
| # - **Венгерская нотация** (`strName`, `iVacationDays`) — устарела: | ||
| # современные IDE и типизация делают её ненужной | ||
| # | ||
| # | ||
| # - **Полезные префиксы**: | ||
| # - `is_`, `has_` для **логических значений**: | ||
| # `is_vehicle`, `has_key()` → код читается как естественный язык | ||
| # - **Единицы измерения** в имени (`weight_kg`, `speed_mph`) — **не венгерская нотация** | ||
| # Пример: ошибка Mars Climate Orbiter (1999) из-за путаницы между | ||
| # фунтами и ньютонами обошлась в $125 млн | ||
| # | ||
| # | ||
| # **Последовательные числовые суффиксы — признак плохого дизайна** | ||
| # | ||
| # | ||
| # - Имена вроде `payment1`, `payment2`, `payment3` **не объясняют различий** | ||
| # | ||
| # | ||
| # - Лучшие альтернативы: | ||
| # - Объединить в коллекцию: `payments = [p1, p2, p3]` | ||
| # - Передавать параметр: `makePayment(priority=1, amount)` | ||
| # - Использовать осмысленные имена: `makeHighPriorityPayment()`, `make1stQuarterPayment()` | ||
| # | ||
| # | ||
| # - Числовые суффиксы допустимы **только при веской причине**, а не из лени | ||
| # | ||
| # | ||
| # **Выбирайте имена, пригодные для поиска** | ||
| # | ||
| # | ||
| # - Короткие и обобщённые имена (`num`, `a`, `email`) вызывают **ложные совпадения** | ||
| # при поиске (Ctrl+F) | ||
| # | ||
| # | ||
| # - **Уникальные, конкретные имена** проще найти и понять: | ||
| # - Вместо `email` → `emailAddress`, `replyToAddress`, `downloadEmailAttachment` | ||
| # | ||
| # | ||
| # - Даже при наличии инструментов рефакторинга в IDE, **пишите так, будто их нет** — | ||
| # это стимулирует выбор более осмысленных имён | ||
| # | ||
| # | ||
| # ## Не заменяйте встроенные имена | ||
| # | ||
| # | ||
| # - **Никогда не используйте встроенные имена Python** (например, `list`, `set`, `str`, `open`) | ||
| # **в качестве имён своих переменных**. | ||
| # - Это **перезаписывает встроенные функции**, что может привести к ошибкам. | ||
| # - Пример: после `list = ['cat', 'dog']` вызов `list(range(5))` вызовет | ||
| # `TypeError: 'list' object is not callable`. | ||
| # | ||
| # | ||
| # - **Как проверить, является ли имя встроенным**: | ||
| # - Введите имя в интерактивной оболочке Python. | ||
| # - Если возвращается объект (например, `<built-in function open>`), имя занято. | ||
| # - Попробуйте импортировать как модуль. | ||
| # - `NameError` или `ModuleNotFoundError` означают, что имя свободно. | ||
| # | ||
| # | ||
| # - **Часто переопределяемые встроенные имена** (избегайте их!): | ||
| # - `all`, `any`, `date`, `email`, `file`, `format`, `hash`, `id`, `input`, `list`, `min`, | ||
| # `max`, `object`, `open`, `random`, `set`, `str`, `sum`, `test`, `type`. | ||
| # | ||
| # | ||
| # - **Не называйте свои `.py`-файлы так же, как сторонние модули**. | ||
| # - Пример: файл `pyperclip.py` в рабочей директории **перекрывает** установленный | ||
| # модуль `pyperclip`. | ||
| # - При `import pyperclip` импортируется ваш файл, а не настоящий модуль → | ||
| # вызов `pyperclip.copy()` завершится ошибкой `AttributeError`. | ||
| # | ||
| # | ||
| # - **Общее правило**: избегайте конфликтов имён с встроенными функциями, модулями и сторонними | ||
| # библиотеками — это частая причина неочевидных ошибок, особенно `AttributeError` при отсутствии | ||
| # ожидаемых функций. | ||
| # | ||
| # | ||
| # ## Итоги | ||
| # | ||
| # ### Плохие примеры имён | ||
| # - **`data`** — бессодержательно, так как *все* переменные содержат данные. | ||
| # - **`var`** — тавтология (аналог клички «Собака» для собаки). | ||
| # - **`temp`** — неинформативно; все переменные временные по своей природе. | ||
| # - Такие имена распространены, но их **следует избегать**. | ||
| # | ||
| # ### Хорошая альтернатива | ||
| # - Вместо обобщённых имён используйте **конкретные и описательные**: | ||
| # - Например: `temperatureVariance` вместо `tempVarData`. | ||
| # | ||
| # ### Основные принципы выбора имён | ||
| # - Выбор имён не связан с алгоритмами, но **критически важен для читаемости кода**. | ||
| # - Следуйте рекомендациям PEP 8: | ||
| # - Модули — `lowercase`. | ||
| # - Классы — `PascalCase`. | ||
| # - Функции/переменные — `snake_case`. | ||
| # - Константы — `UPPER_SNAKE_CASE`. | ||
| # - Имена **не должны быть слишком короткими или слишком длинными**. | ||
| # - Лучше слегка избыточное, чем недостаточно содержательное имя. | ||
| # | ||
| # ### Требования к хорошему имени | ||
| # - **Лаконичное**, но **информативное**. | ||
| # - **Уникальное** — легко находится через поиск (Ctrl+F). | ||
| # - **Понятное** даже тем, для кого английский не родной. | ||
| # - **Без шуток, каламбуров и культурных отсылок** — они не универсальны и часто непонятны. | ||
| # - **Прямолинейное, традиционное, без юмора**. | ||
| # | ||
| # ### Избегайте конфликтов с встроенными именами | ||
| # - Не используйте имена, зарезервированные стандартной библиотекой Python: | ||
| # - `all`, `any`, `date`, `email`, `file`, `format`, `hash`, `id`, `input`, `list`, `min`, | ||
| # `max`, `object`, `open`, `random`, `set`, `str`, `sum`, `test`, `type`. | ||
| # - Их переопределение вызывает **скрытые и трудноуловимые ошибки**. | ||
| # | ||
| # ### Главный вывод | ||
| # - Компьютеру безразличны имена — они нужны **людям**. | ||
| # - Хорошо читаемый код → понятный код → легко изменяемый код → проще исправлять ошибки и | ||
| # добавлять функции. | ||
| # - **Понятные имена — основа качественного программного обеспечения.** | ||
| # |
Member
Author
There was a problem hiding this comment.
Please do a review in python_issue folder
Member
Author
There was a problem hiding this comment.
https://www.kaggle.com/ohdddy/code?orderBy=dateUpdated - kaggle notebooks
Comment on lines
+1
to
+245
| """Choosing understandable names.""" | ||
|
|
||
| # *Имена формально называются идентификаторами* | ||
| # | ||
| # | ||
| # ### Схемы регистра имен | ||
| # | ||
| # | ||
| # Так как в идентификаторах Python различается регистр символов и они не могут содержать пробельные | ||
| # символы, программисты используют несколько схем в идентификаторах, состоящих из нескольких слов. | ||
| # | ||
| # | ||
| # 1. Змеиный регистр (snake_case) разделяет слова символом подчеркивания, который напоминает ползущую | ||
| # между словами змею. В этом случае все буквы записываются в нижнем регистре, а константы часто | ||
| # записываются в верхнем змеином регистре (UPPER_SNAKE_CASE). | ||
| # | ||
| # 2. Верблюжий регистр (camelCase) — слова записываются в нижнем регистре, но второе и следующие | ||
| # слова начинаются с заглавной. Эта схема в большин- | ||
| # стве случаев подразумевает, что первое слово начинается с буквы нижнего регистра. | ||
| # Буквы верхнего регистра напоминают верблюжьи горбы. | ||
| # | ||
| # 3. Схема Pascal (PascalCase) — названа так, потому что применяется в языке программирования Pascal | ||
| # Аналогична схеме верблюжьего регистра, но первое слово в ней тоже начинается с заглавной. | ||
| # | ||
| # | ||
| # ### Соглашения об именах PEP 8 | ||
| # | ||
| # | ||
| # - **Символы в идентификаторах**: | ||
| # - Должны быть **ASCII-символами** (латинские буквы без диакритических знаков) | ||
| # | ||
| # | ||
| # - **Стили именования**: | ||
| # - **Модули**: короткие, только строчные буквы (`lowercase`) | ||
| # - **Классы**: записываются в **PascalCase** (CapWords). | ||
| # - **Константы**: записываются в **UPPER_SNAKE_CASE** (все заглавные с подчёркиваниями). | ||
| # - **Функции, методы и переменные**: записываются в **snake_case** (строчные с подчёркиваниями). | ||
| # | ||
| # | ||
| # - **Специальные аргументы**: | ||
| # - Первый аргумент **метода экземпляра** — всегда `self` (в нижнем регистре) | ||
| # - Первый аргумент **метода класса** — всегда `cls` (в нижнем регистре) | ||
| # | ||
| # | ||
| # - **Атрибуты классов**: | ||
| # - **Приватные** атрибуты начинаются с символа подчёркивания (`_`) | ||
| # - **Публичные** атрибуты **не начинаются** с подчёркивания | ||
| # | ||
| # | ||
| # - **Гибкость применения правил**: | ||
| # - PEP 8 **не обязателен к неукоснительному соблюдению** | ||
| # - Допустимо использовать идентификаторы на других языках | ||
| # - Можно использовать другие стили (например, camelCase), если это улучшает читаемость | ||
| # | ||
| # - **Главный принцип читаемости**: | ||
| # - Важнее не выбор конкретной схемы именования, а **последовательность её применения** в рамках проекта или модуля | ||
| # | ||
| # | ||
| # ### Длина имен | ||
| # | ||
| # | ||
| # **Рекомендации по выбору имён переменных и функций** | ||
| # | ||
| # **Общий принцип** | ||
| # - Код читают чаще, чем пишут → **предпочтение более длинным, понятным именам**, | ||
| # даже если их дольше вводить | ||
| # | ||
| # | ||
| # **Слишком короткие имена — проблема читаемости** | ||
| # | ||
| # | ||
| # - **Одно- или двухбуквенные имена** (например, `g`) неясны: неизвестно, какое слово они обозначают | ||
| # | ||
| # | ||
| # - **Сокращения** (`mon` → monitor/month/monster?) вводят в заблуждение | ||
| # | ||
| # | ||
| # - **Однословные имена** (`start`) не указывают контекст: начало чего? | ||
| # | ||
| # | ||
| # - Такие имена могут быть понятны автору в момент написания, | ||
| # но **непонятны другим или самому через время** | ||
| # | ||
| # | ||
| # **Допустимые исключения для коротких имён** | ||
| # | ||
| # | ||
| # - `i`, `j`, `k` — для индексов в циклах `for` | ||
| # | ||
| # | ||
| # - `x`, `y` — для декартовых координат | ||
| # | ||
| # | ||
| # - Иногда допустимы `w`/`h` (width/height) или `n` (number), | ||
| # но это **не всегда очевидно** другим | ||
| # | ||
| # | ||
| # **Слишком длинные имена — когда это оправдано** | ||
| # | ||
| # | ||
| # - Чем **шире область видимости** (например, глобальная переменная в большом проекте), | ||
| # тем **более содержательным должно быть имя** | ||
| # | ||
| # | ||
| # - Пример: `payment` — нормально для локальной переменной; | ||
| # `salesClientMonthlyPayment` — лучше для глобального контекста | ||
| # | ||
| # | ||
| # - **Уточняющие слова устраняют неоднозначность** → лучше перестраховаться, чем недоговорить | ||
| # | ||
| # | ||
| # **Не пропускайте буквы** | ||
| # | ||
| # | ||
| # - Имена вроде `memcpy` или `strcmp` (из C) **устарели** и плохо читаются | ||
| # | ||
| # | ||
| # - Имя должно быть **произносимым и понятным** | ||
| # | ||
| # | ||
| # - Предпочтение **естественным фразам**: `number_of_trials` лучше, чем `number_trials` | ||
| # | ||
| # | ||
| # **Префиксы: когда полезны, а когда избыточны** | ||
| # | ||
| # | ||
| # - **Избыточные префиксы**: | ||
| # - `catWeight` в классе `Cat` — излишне, так как `weight` и так относится к кошке | ||
| # - **Венгерская нотация** (`strName`, `iVacationDays`) — устарела: | ||
| # современные IDE и типизация делают её ненужной | ||
| # | ||
| # | ||
| # - **Полезные префиксы**: | ||
| # - `is_`, `has_` для **логических значений**: | ||
| # `is_vehicle`, `has_key()` → код читается как естественный язык | ||
| # - **Единицы измерения** в имени (`weight_kg`, `speed_mph`) — **не венгерская нотация** | ||
| # Пример: ошибка Mars Climate Orbiter (1999) из-за путаницы между | ||
| # фунтами и ньютонами обошлась в $125 млн | ||
| # | ||
| # | ||
| # **Последовательные числовые суффиксы — признак плохого дизайна** | ||
| # | ||
| # | ||
| # - Имена вроде `payment1`, `payment2`, `payment3` **не объясняют различий** | ||
| # | ||
| # | ||
| # - Лучшие альтернативы: | ||
| # - Объединить в коллекцию: `payments = [p1, p2, p3]` | ||
| # - Передавать параметр: `makePayment(priority=1, amount)` | ||
| # - Использовать осмысленные имена: `makeHighPriorityPayment()`, `make1stQuarterPayment()` | ||
| # | ||
| # | ||
| # - Числовые суффиксы допустимы **только при веской причине**, а не из лени | ||
| # | ||
| # | ||
| # **Выбирайте имена, пригодные для поиска** | ||
| # | ||
| # | ||
| # - Короткие и обобщённые имена (`num`, `a`, `email`) вызывают **ложные совпадения** | ||
| # при поиске (Ctrl+F) | ||
| # | ||
| # | ||
| # - **Уникальные, конкретные имена** проще найти и понять: | ||
| # - Вместо `email` → `emailAddress`, `replyToAddress`, `downloadEmailAttachment` | ||
| # | ||
| # | ||
| # - Даже при наличии инструментов рефакторинга в IDE, **пишите так, будто их нет** — | ||
| # это стимулирует выбор более осмысленных имён | ||
| # | ||
| # | ||
| # ## Не заменяйте встроенные имена | ||
| # | ||
| # | ||
| # - **Никогда не используйте встроенные имена Python** (например, `list`, `set`, `str`, `open`) | ||
| # **в качестве имён своих переменных**. | ||
| # - Это **перезаписывает встроенные функции**, что может привести к ошибкам. | ||
| # - Пример: после `list = ['cat', 'dog']` вызов `list(range(5))` вызовет | ||
| # `TypeError: 'list' object is not callable`. | ||
| # | ||
| # | ||
| # - **Как проверить, является ли имя встроенным**: | ||
| # - Введите имя в интерактивной оболочке Python. | ||
| # - Если возвращается объект (например, `<built-in function open>`), имя занято. | ||
| # - Попробуйте импортировать как модуль. | ||
| # - `NameError` или `ModuleNotFoundError` означают, что имя свободно. | ||
| # | ||
| # | ||
| # - **Часто переопределяемые встроенные имена** (избегайте их!): | ||
| # - `all`, `any`, `date`, `email`, `file`, `format`, `hash`, `id`, `input`, `list`, `min`, | ||
| # `max`, `object`, `open`, `random`, `set`, `str`, `sum`, `test`, `type`. | ||
| # | ||
| # | ||
| # - **Не называйте свои `.py`-файлы так же, как сторонние модули**. | ||
| # - Пример: файл `pyperclip.py` в рабочей директории **перекрывает** установленный | ||
| # модуль `pyperclip`. | ||
| # - При `import pyperclip` импортируется ваш файл, а не настоящий модуль → | ||
| # вызов `pyperclip.copy()` завершится ошибкой `AttributeError`. | ||
| # | ||
| # | ||
| # - **Общее правило**: избегайте конфликтов имён с встроенными функциями, модулями и сторонними | ||
| # библиотеками — это частая причина неочевидных ошибок, особенно `AttributeError` при отсутствии | ||
| # ожидаемых функций. | ||
| # | ||
| # | ||
| # ## Итоги | ||
| # | ||
| # ### Плохие примеры имён | ||
| # - **`data`** — бессодержательно, так как *все* переменные содержат данные. | ||
| # - **`var`** — тавтология (аналог клички «Собака» для собаки). | ||
| # - **`temp`** — неинформативно; все переменные временные по своей природе. | ||
| # - Такие имена распространены, но их **следует избегать**. | ||
| # | ||
| # ### Хорошая альтернатива | ||
| # - Вместо обобщённых имён используйте **конкретные и описательные**: | ||
| # - Например: `temperatureVariance` вместо `tempVarData`. | ||
| # | ||
| # ### Основные принципы выбора имён | ||
| # - Выбор имён не связан с алгоритмами, но **критически важен для читаемости кода**. | ||
| # - Следуйте рекомендациям PEP 8: | ||
| # - Модули — `lowercase`. | ||
| # - Классы — `PascalCase`. | ||
| # - Функции/переменные — `snake_case`. | ||
| # - Константы — `UPPER_SNAKE_CASE`. | ||
| # - Имена **не должны быть слишком короткими или слишком длинными**. | ||
| # - Лучше слегка избыточное, чем недостаточно содержательное имя. | ||
| # | ||
| # ### Требования к хорошему имени | ||
| # - **Лаконичное**, но **информативное**. | ||
| # - **Уникальное** — легко находится через поиск (Ctrl+F). | ||
| # - **Понятное** даже тем, для кого английский не родной. | ||
| # - **Без шуток, каламбуров и культурных отсылок** — они не универсальны и часто непонятны. | ||
| # - **Прямолинейное, традиционное, без юмора**. | ||
| # | ||
| # ### Избегайте конфликтов с встроенными именами | ||
| # - Не используйте имена, зарезервированные стандартной библиотекой Python: | ||
| # - `all`, `any`, `date`, `email`, `file`, `format`, `hash`, `id`, `input`, `list`, `min`, | ||
| # `max`, `object`, `open`, `random`, `set`, `str`, `sum`, `test`, `type`. | ||
| # - Их переопределение вызывает **скрытые и трудноуловимые ошибки**. | ||
| # | ||
| # ### Главный вывод | ||
| # - Компьютеру безразличны имена — они нужны **людям**. | ||
| # - Хорошо читаемый код → понятный код → легко изменяемый код → проще исправлять ошибки и | ||
| # добавлять функции. | ||
| # - **Понятные имена — основа качественного программного обеспечения.** | ||
| # |
15 tasks
Otabek1121
added a commit
to Otabek1121/Data-Science-For-Beginners-from-scratch-SENATOROV
that referenced
this pull request
Jan 28, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes https://github.com/SENATOROVAI/python/issues/1