TGTGInsighttelegram intelligenceLIVE / telegram public index
← Python Заметки

TGINSIGHT SIMILAR POSTS

Најди сличен содржај

Изворен канал @pythonotes · Post #197 · 4 јан.

Подразумеваемые неймспейсы или неявные пакеты. Этот функционал добавлен в Python 3.3 Что он означает? Ранее, до 3.3 пакетами считались лишь директории, в которых есть файл __init__.py. Этот файл одновременно являлся свидетельством того, что директория это Python-пакет, и служил "телом" этого пакета. То есть местом, где можно написать код, как это делается внутри модуля. Этот код исполняется в момент импорта пакета, так что его принято называть "код инициализации пакета". Начиная с версии 3.3 Любая директория считается пакетом и Python будет пытаться использовать любую директорию для импорта. Конечно, не любую в файловой системе, а только те что находятся в sys.path. Это значит, что теперь __init__.py нужно делать только если: 🔸 вам требуется создать код инициализации пакета 🔸 нужна совместимость со старыми версиями Python На мой взгляд это немного упрощает разработку, делает её чище, но с другой стороны убивает некоторую однозначность происходящего. Например, я создал репозиторий со своей библиотекой и рядом положил код примеров или тестов. repo_name/ my_library/ __init__.py main.py examples/ exam1.py exam2.py В этом репозитории пакетом является только my_library, остальные директории это не пакеты, это просто дополнительный код в файлах. Директория examples не добавлена в sys.path, в ней нет рабочих модулей. Но если она лежит рядом с my_library, то Python вполне сможет импортнуть из неё модули, так как посчитает что examples это валидный пакет. Конечно, пример несколько надуманный. Никто не будет добавлять корень репозитория в sys.path. Но, я думаю, суть ясна. Иногда директория это просто директория а не пакет! #basic#pep

Hashtags

Резултати

Пронајдени 3 слични објави

Пребарај: #threading

当前筛选 #threading清除筛选
djangoproject

@djangoproject · Post #157 · 06.09.2016 г., 19:55

https://docs.python.org/2/library/multiprocessing.html #multiprocessing is a package that supports spawning processes using an #API similar to the #threading module. The multiprocessing package offers both local and remote #concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of #threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows.

djangoproject

@djangoproject · Post #118 · 08.08.2016 г., 11:44

https://docs.python.org/3/library/multiprocessing.html multiprocessing is a package that supports spawning processes using an API similar to the threading module. The multiprocessing package offers both local and remote concurrency, effectively side-stepping the Global Interpreter Lock by using subprocesses instead of threads. Due to this, the multiprocessing module allows the programmer to fully leverage multiple processors on a given machine. It runs on both Unix and Windows. The #multiprocessing module also introduces #APIs which do not have analogs in the #threading#module. A prime example of this is the Pool object which offers a convenient means of parallelizing the execution of a function across multiple input values, distributing the input data across processes (data #parallelism). The following example demonstrates the common practice of defining such functions in a module so that child processes can successfully import that module. This basic example of data parallelism using Pool,

djangoproject

@djangoproject · Post #107 · 02.08.2016 г., 15:22

https://github.com/python/asyncio The #asyncio#module provides infrastructure for writing #single-threaded concurrent code using #coroutines, #multiplexing#I/O access over sockets and other resources, running network clients and servers, and other related primitives. Here is a more detailed list of the package contents: a pluggable event loop with various system-specific implementations; transport and protocol abstractions (similar to those in Twisted); concrete support for TCP, UDP, SSL, subprocess pipes, delayed calls, and others (some may be system-dependent); a Future class that mimics the one in the concurrent.futures module, but adapted for use with the event loop; #coroutines and #tasks based on yield from (PEP 380), to help write concurrent code in a sequential fashion; cancellation support for Futures and coroutines; synchronization primitives for use between coroutines in a single thread, mimicking those in the #threading module; an interface for passing work off to a threadpool, for times when you absolutely, positively have to use a library that makes blocking I/O calls. Note: The implementation of asyncio was previously called "Tulip".