TGINSIGHT SIMILAR POSTS
Изходен канал @clockstackwheels · Post #962 · 17.02
В этом году я читаю небольшой курс лекций студентам Высшей Инжиниринговой Школы НИЯУ МИФИ, вот на прошлой неделе начал. Тема: архитектура приложений. Сначала SOLID, простые паттерны, а потом сложные паттерны и DDD. Долго думал над тем, какие примеры приводить. Классические книжные не хотелось, типа вот у нас класс "Животное", у него наследник "Кошка". Это понятно для жизни, но далеко от реального программирования. И примеры со своей работы не хотелось, потому что без знания специфики не будет понятно, что такое "Цифровая ведомость объёмов работ", и почему в ней есть те или иные ограничения. Так что придумал вот такой сценарий для студентов: примеры из видеоигр. Любая видеоигра это программа, написанная разработчиками на языке программирования. Это реальные люди, которые сталкивались с реальной необходимостью применить какие-либо паттерны и архитектурные подходы. Я, конечно, не знаю, как та или иная функция была реализована в игре на самом деле — вполне возможно, что из-за спешки, производственного ада, использования устаревших технологий или проблем планирования что-то написано очень плохо, коряво, без архитектуры и с огромным техническим долгом. Но я просто показывал ситуации, в которых какой-то конкретный структурный подход кажется уместным, и рассказывал, как можно такую ситуацию реализовать на практике. Вроде получилось неплохо, студентам зашло. Обратная связь по лекции пришла положительная, так что будем продолжать :) #dev
Hashtags
Търсене: #interpreter
@djangoproject · Post #156 · 06.09.2016 г., 01:43
https://wiki.python.org/moin/GlobalInterpreterLock In #CPython, the #global#interpreter lock, or #GIL, is a mutex that prevents multiple native #threads from executing Python bytecodes at once. This lock is necessary mainly because CPython's memory management is not thread-safe. (However, since the GIL exists, other features have grown to depend on the guarantees that it enforces.)
@djangoproject · Post #159 · 12.09.2016 г., 17:37
https://docs.python.org/3/library/atexit.html The #atexit module defines #functions to #register and #unregister cleanup functions. Functions thus registered are automatically executed upon normal interpreter termination. atexit runs these functions in the reverse order in which they were registered; if you register A, B, and C, at #interpreter#termination time they will be run in the order C, B, A.