Python tests
7.41K subscribers
501 photos
4 videos
46 links
Тесты и задания python разработчиков

По всем вопросам- @notxxx1

@ai_machinelearning_big_data - машинное обучение

@programming_books_it - бесплатные it книги

@pythonl - 🐍

@ArtificialIntelligencedl - AI

@datascienceiot -ds книги
Download Telegram
Forwarded from Python RU
Forwarded from Python RU
Каким будет вывод этого кода?
Anonymous Quiz
52%
[0]
33%
[1]
6%
[1, 0]
4%
[0, 1]
4%
Посмотреть ответ
👩‍💻 Что выведет этот код и почему?
Please open Telegram to view this post
VIEW IN TELEGRAM
👩‍💻 Что выведет этот код и почему?

@python_job_interview
Please open Telegram to view this post
VIEW IN TELEGRAM
Каким будет результат выполнения кода?
Anonymous Quiz
33%
True
40%
False
3%
None
15%
Ошибка
9%
Узнать ответ
Какой оператор перегружается функцией __invert__()?
Anonymous Quiz
29%
!
35%
~
9%
^
5%
-
22%
Посмотреть ответ
This media is not supported in your browser
VIEW IN TELEGRAM
Python: Никогда не делай так!!!

НИКОГДА НЕ ИСПОЛЬЗУЙ МУТАБЕЛЬНЫЕ ДЕФОЛТЫ: не используй изменяемые объекты (например, списки или словари) как значения по умолчанию в аргументах функции.
Каждый вызов функции будет делить один и тот же объект, и ты получишь «призрачные» данные, которые появляются из ниоткуда. Это одна из самых коварных ловушек Python.

Всегда используй None и создавай новый объект внутри функции. Подписывайся, больше фишек каждый день !


Плохо — список живёт между вызовами
def add_item(item, bucket=[]):
bucket.append(item)
return bucket

print(add_item(1)) # [1]
print(add_item(2)) # [1, 2] — неожиданно!

# Правильно
def add_item(item, bucket=None):
if bucket is None:
bucket = []
bucket.append(item)
return bucket

print(add_item(1)) # [1]
print(add_item(2)) # [2]
Вопрос с собеседования

Что выведет этот код и почему?


a = [1, 2, 3]
b = a

a += [4, 5]

print(a)
print(b)

a = (1, 2, 3)
b = a

a += (4, 5)

print(a)
print(b)


Попробуй сначала сам ответить, а потом смотри разбор.


Часть 1. Списки
a = [1, 2, 3]
b = a

a += [4, 5]

print(a)
print(b)


Что происходит по шагам:

a = [1, 2, 3]


Переменная a ссылается на список [1, 2, 3].

b = a
Теперь b ссылается на тот же самый список, что и a.
Не копия, а один и тот же объект в памяти.

a += [4, 5]
Важно: для списков += работает как изменение объекта на месте:
это примерно то же самое, что:

a.extend([4, 5])


То есть в существующий список, на который ссылаются и a, и b, добавляются элементы 4 и 5.

Поэтому:

print(a) # [1, 2, 3, 4, 5]
print(b) # [1, 2, 3, 4, 5]


Оба указывают на один изменённый список.

Часть 2. Кортежи
a = (1, 2, 3)
b = a

a += (4, 5)

print(a)
print(b)


Кортежи неизменяемы, и здесь начинается магия.

a = (1, 2, 3)
a ссылается на кортеж (1, 2, 3).

b = a
b ссылается на тот же кортеж (1, 2, 3).

a += (4, 5)
Для кортежей += уже не может менять объект на месте (они immutable).
Поэтому Python делает так:

a = a + (4, 5)


То есть создаётся новый кортеж (1, 2, 3, 4, 5) и переменная a переназначается на него.

b при этом остаётся смотреть на старый кортеж (1, 2, 3).

Поэтому:

print(a) # (1, 2, 3, 4, 5)
print(b) # (1, 2, 3)

В чём хитрость

Для списка a += [4, 5] мутирует объект на месте, и это видно через все переменные, которые на него ссылаются.

Для кортежа a += (4, 5) создаёт новый объект и переназначает только a.

Итого:


# Часть со списком:
[1, 2, 3, 4, 5]
[1, 2, 3, 4, 5]

# Часть с кортежем:
(1, 2, 3, 4, 5)
(1, 2, 3)


Если хочешь, могу ещё один хитрый вопрос разобрать - про изменяемые значения по умолчанию в аргументах функции или про циклы и замыкания.
Media is too big
VIEW IN TELEGRAM
✔️ Как организовать архитектуру большого Python-проекта?

Главная цель - чтобы через полгода было не стыдно открывать код: понятно где что лежит, как это тестировать и куда встраивать новые фичи.

Основные принципы:
- Разделяй по ответственности, а не по типу файла
- Минимизируй связь между слоями
- Явно отделяй ядро домена от инфраструктуры (БД, HTTP, очереди)

Пример базовой структуры:
- app/
- api/ - HTTP handlers, REST, gRPC, CLI
- services/ - бизнес-логика, сценарии use case
- domain/ - сущности, модели, value objects
- repositories/ - работа с БД, кэшами, внешними сервисами
- config/ - настройки, env, схемы конфигурации
- utils/ - вспомогательные функции, которые не завязаны на домен
- tests/ - тесты по тем же модулям, что и в app/
- scripts/ - миграции, разовые утилиты, maintenance

Рекомендации:
- Один входной файл (main.py или cli.py), вся логика - в app/*
- Конфигурацию не хардкодить, а прокидывать через env и config-объекты
- Внутри services работать с абстрактными интерфейсами репозиториев, а не с конкретным ORM
- С самого начала заводить тесты, пусть даже простые, и поддерживать схему tests/ в том же дереве, что и код
- Любой новый модуль должен отвечать на вопрос: к какому слою относится и от кого ему можно зависеть

Если проект растет, не бойся дробить:
- крупный модуль на подмодули
- общие зависимости в отдельный layer (shared, common)
- разные bounded context в отдельные пакеты внутри app/

Архитектура большого проекта - это не про идеальный паттерн, а про понятные границы и минимальный хаос.

https://uproger.com/kak-organizovat-arhitekturu-bolshogo-python-proekta/

Видео: https://www.youtube.com/watch?v=Dk7A8ElHcKE
Please open Telegram to view this post
VIEW IN TELEGRAM