Вся инкапсуляция завязана на "ты это поле не трогай, оно начинается с _ или __ и оно не для тебя"
Вся инкапсуляция в пайтоне не "завязана" на сокрытии данных, просто потому что инкапсуляция в принципе это не про сокрытие.
Ключевая идея инкапсуляции в объединении данных и методов. Тоесть это про "упаковку" данных и методов в какую-то единицу, будь то класс, функция, модуль и тд., и управлением доступом к этим данным для поддержания целостности объекта.
Тоесть когда мы выносим сущность "Деньги" в отдельный класс который занимается специфическим для денег округлением вместо того чтобы всюду по приложению вызывать функцию round это и является инкапсуляцией. И то что в пайтоне "приватность" основана на соглашении никак не влияет на наличие инкапсуляции в языке. Даже если бы и такого соглашения не было - инкапсуляция в пайтоне всеравно была бы. Так-то она существует даже в С или ассемблере, например.
Инкапсуляция в первую очередь это про групирование кода, а потом уже про ограничение доступа к внутреннему состоянию объекта, причем ограничивать доступ можно не только с помощью приватных методов.
В принципе согласен, но на самом деле сложно разделить вопросы чётко на такие категории. На собеседованиях могут спросить что угодно, к тому же на один и тот же вопрос можно ответить с разной степенью "глубины". В любом случае если кто-то в PR предложит такое разделение - буду только рад.
Китайский репозиторий на китайском языке с вопросами для подготовки к собеседованию конечно хорошо, но у меня есть менее популярный репозиторий, но на русском (присоединяйтесь кстати - PR are welcome)
И кстати по поводу "не принимает аргументов", мне кажется что тут наезд на джангу несправедливый, ведь эта проблема решается с помощью functools.partial (такой подход используется во многих батарейках для пайтона, в том числе и в стдлибе)
>callable default ...не принимает аргументов, поэтому есть только два юз-кейса, когда это нужно: random и datetime.now, который и так уже есть в виде auto_now_add.
А вот auto_now_add лучше вообще не использовать, а как раз указывать datetime.now или timezone.now в default. Почему? Да потому что если использовать auto_now_add, то в тестах не получится создать модель с нужной датой, придётся или использовать батарейки типа time-machine или после создания модели перезаписывать время через .update()
Не уверен что формулировка автора "некоторые сигналы будут не доставлены" верна. IO задачи то будут выполнены, вот только при существовании рядом с ними CPU-bound задач выполнены они будут не так быстро, как могли бы.
Неплохая статья, но блок-схема немного удручает. Если следовать ей, то для задачи поддержания постоянного socket-конекшена (а может и большого количества, подключений, в блок-схеме же про это ничего не сказано), нужно использовать multiprocessing, а не asyncio.
Вся инкапсуляция в пайтоне не "завязана" на сокрытии данных, просто потому что инкапсуляция в принципе это не про сокрытие.
Ключевая идея инкапсуляции в объединении данных и методов. Тоесть это про "упаковку" данных и методов в какую-то единицу, будь то класс, функция, модуль и тд., и управлением доступом к этим данным для поддержания целостности объекта.
Тоесть когда мы выносим сущность "Деньги" в отдельный класс который занимается специфическим для денег округлением вместо того чтобы всюду по приложению вызывать функцию round это и является инкапсуляцией. И то что в пайтоне "приватность" основана на соглашении никак не влияет на наличие инкапсуляции в языке. Даже если бы и такого соглашения не было - инкапсуляция в пайтоне всеравно была бы. Так-то она существует даже в С или ассемблере, например.
Инкапсуляция в первую очередь это про групирование кода, а потом уже про ограничение доступа к внутреннему состоянию объекта, причем ограничивать доступ можно не только с помощью приватных методов.
Что имелось в виду?
В принципе согласен, но на самом деле сложно разделить вопросы чётко на такие категории. На собеседованиях могут спросить что угодно, к тому же на один и тот же вопрос можно ответить с разной степенью "глубины". В любом случае если кто-то в PR предложит такое разделение - буду только рад.
Китайский репозиторий на китайском языке с вопросами для подготовки к собеседованию конечно хорошо, но у меня есть менее популярный репозиторий, но на русском (присоединяйтесь кстати - PR are welcome)
https://github.com/yakimka/python_interview_questions
Для минусующих - "Типичный Алёша", это человек который не боится критики, может сделать выводы из своих неудач и стать, благодаря им, лучше.
Типичный Алёша
Затем что он так называется
А трей так и не добавили?
Текст статьи тоже много вопросов вызывает
Скорее всего там уже занято
А о чём статья? О том что в стдлибе пайтона есть multiprocessing?
>Нельзя сериализовать лямбду в миграции
А каким образом вы предлагаете сериализовать лямбды?
И кстати по поводу "не принимает аргументов", мне кажется что тут наезд на джангу несправедливый, ведь эта проблема решается с помощью
functools.partial(такой подход используется во многих батарейках для пайтона, в том числе и в стдлибе)>callable default ...не принимает аргументов, поэтому есть только два юз-кейса, когда это нужно: random и datetime.now, который и так уже есть в виде auto_now_add.
А вот
auto_now_addлучше вообще не использовать, а как раз указыватьdatetime.nowилиtimezone.nowвdefault. Почему? Да потому что если использоватьauto_now_add,то в тестах не получится создать модель с нужной датой, придётся или использовать батарейки типа time-machine или после создания модели перезаписывать время через.update()Для разработчика? Насколько я понимаю, это должно помочь.
Если для того чтобы изменить это разработчикам языка нужно сделать умный планировщик.
Скорее всего автор имел в виду это https://bugs.python.org/issue7946
Вот отличная иллюстрация проблемы https://youtu.be/Obt-vMVdM8s?t=1803
Не уверен что формулировка автора "некоторые сигналы будут не доставлены" верна. IO задачи то будут выполнены, вот только при существовании рядом с ними CPU-bound задач выполнены они будут не так быстро, как могли бы.
https://ru.wiktionary.org/wiki/%D1%81_%D0%BF%D0%BE%D0%BB%D0%B8%D1%87%D0%BD%D1%8B%D0%BC
Неплохая статья, но блок-схема немного удручает. Если следовать ей, то для задачи поддержания постоянного socket-конекшена (а может и большого количества, подключений, в блок-схеме же про это ничего не сказано), нужно использовать multiprocessing, а не asyncio.
По первому же примеру видто что вы не питонист
Иначе вы бы знали, что у питона батарейки в комплекте:
Видимо с момента написания статьи прошло довольно много времени и на свежей версии dearpygui примеры уже не работают