python embeddable что это

Электрический блогнот

мои заметки на полях

python embedded или как добавить python в свое приложение

У Pyhon есть прекрасный инсталлятор, который все сдеает сам и установит Python со всеми стандартными модулями. Но, что делать, если ваше приложение использует python скрипты, а заставлять пользователя скачивать и устанавливать весь Python вам не хочется. Для этого существует Python Embedded (встраиваемый). Этот пакет не требует установки и может быть просто скопирован в папку с вашим приложением. Так же вы сможете установить все необходимые модули для работы и создать миниокружение для работы. Тем самым полностью избавить пользователя от лишних действий. Он даже и не узнает, что часть вашего приложения запускает Python. Этот прием я использовал в приложении Fpska (конвертация видео в 60 fps).
Далее я подробно распишу, как внедрить Python в свое приложение. Все эллементарно. Несколько простых шагов.

Шаг 1 — загружаем встраиваемый Python

Идем на python.org и скачиваем нужную версию python embedded:

Шаг 2 — устанавливаем встраиваемый Pyton

Вся установка сводится к простой распаковке архива:

На этом шаге можно было бы и остановиться, но чистый Python редко, кто использует. Нужны еще и модули. А чтобы поставить модули нужен pip (package installer for Python).

Шаг 3 — pip

Перед устанвкой pip настроим пути к библиотекам. Для этого в файле python37._pth нужно раскомментировать строку:

Скачиваем pip. Для этого рекомендуют использовать утилиту curl:

но можно просто скачать из браузера

Далее переходим в папку с embedded Python и устанавливаем инсталлятор пакетов (pip):

После установки pip появятся папки Lib и Scripts:

Сразу же проверим работает ли pip:

Шаг 4 — модули

Устанавливаем модули. Для примера установим модуль wxPython (добавляет графический интерфейс).

Шаг 5 — тестирование

Тестируем только что собранный Python. При тестировании очент важно проверить, что получился абсолютно независимый дистрибутив Python со всеми проинсталлированными модулями. Для этого устанавливаем все необходимые модули. Делаем архив папки, где установлен Python Embedded с модулями. И загружаем его куда-нибудь на файлообменник. Затем находим чистый Windows 10, где Python никогда не был установлен. Скачиваем архив и распаковываем. Запускаем любой тестовый скриптик. На следующей картинке тестовый запуск wxPython приложения:

Источник

1. Embedding Python in Another Application¶

The previous chapters discussed how to extend Python, that is, how to extend the functionality of Python by attaching a library of C functions to it. It is also possible to do it the other way around: enrich your C/C++ application by embedding Python in it. Embedding provides your application with the ability to implement some of the functionality of your application in Python rather than C or C++. This can be used for many purposes; one example would be to allow users to tailor the application to their needs by writing some scripts in Python. You can also use it yourself if some of the functionality can be written in Python more easily.

Embedding Python is similar to extending it, but not quite. The difference is that when you extend Python, the main program of the application is still the Python interpreter, while if you embed Python, the main program may have nothing to do with Python — instead, some parts of the application occasionally call the Python interpreter to run some Python code.

The details of Python’s C interface are given in this manual. A great deal of necessary information can be found here.

1.1. Very High Level Embedding¶

The simplest form of embedding Python is the use of the very high level interface. This interface is intended to execute a Python script without needing to interact with the application directly. This can for example be used to perform some operation on a file.

1.2. Beyond Very High Level Embedding: An overview¶

The high level interface gives you the ability to execute arbitrary pieces of Python code from your application, but exchanging data values is quite cumbersome to say the least. If you want that, you should use lower level calls. At the cost of having to write more C code, you can achieve almost anything.

It should be noted that extending Python and embedding Python is quite the same activity, despite the different intent. Most topics discussed in the previous chapters are still valid. To show this, consider what the extension code from Python to C really does:

Convert data values from Python to C,

Perform a function call to a C routine using the converted values, and

Convert the data values from the call from C to Python.

When embedding Python, the interface code does:

Convert data values from C to Python,

Perform a function call to a Python interface routine using the converted values, and

Convert the data values from the call from Python to C.

As you can see, the data conversion steps are simply swapped to accommodate the different direction of the cross-language transfer. The only difference is the routine that you call between both data conversions. When extending, you call a C routine, when embedding, you call a Python routine.

This chapter will not discuss how to convert data from Python to C and vice versa. Also, proper use of references and dealing with errors is assumed to be understood. Since these aspects do not differ from extending the interpreter, you can refer to earlier chapters for the required information.

1.3. Pure Embedding¶

The first program aims to execute a function in a Python script. Like in the section about the very high level interface, the Python interpreter does not directly interact with the application (but that will change in the next section).

The code to run a function defined in a Python script is:

then the result should be:

Although the program is quite large for its functionality, most of the code is for data conversion between Python and C, and for error reporting. The interesting part with respect to embedding Python starts with

Upon return of the function, pValue is either NULL or it contains a reference to the return value of the function. Be sure to release the reference after examining the value.

1.4. Extending Embedded Python¶

Until now, the embedded Python interpreter had no access to functionality from the application itself. The Python API allows this by extending the embedded interpreter. That is, the embedded interpreter gets extended with routines provided by the application. While it sounds complex, it is not so bad. Simply forget for a while that the application starts the Python interpreter. Instead, consider the application to be a set of subroutines, and write some glue code that gives Python access to those routines, just like you would write a normal Python extension. For example:

Insert the above code just above the main() function. Also, insert the following two statements before the call to Py_Initialize() :

These two lines initialize the numargs variable, and make the emb.numargs() function accessible to the embedded Python interpreter. With these extensions, the Python script can do things like

In a real application, the methods will expose an API of the application to Python.

1.5. Embedding Python in C++В¶

It is also possible to embed Python in a C++ program; precisely how this is done will depend on the details of the C++ system used; in general you will need to write the main program in C++, and use the C++ compiler to compile and link your program. There is no need to recompile Python itself using C++.

1.6. Compiling and Linking under Unix-like systems¶

Источник

Using CPython’s Embeddable Zip File

On the download page for CPython 3.5.1, you’ll see a wide range of options. Not all of these are well explained, especially for Windows users who have seven (seven!) choices.

Let me restructure the Windows items into a more feature-focused table:

As is fairly common with installers these days, you have the choice to download everything in advance (the “executable installer”), or a downloader that will let you minimize the download size (the “web installer”). The latter allows you to select options before downloading the components, which can reduce the download size to around 8MB. (For those of us with fast, reliable internet access, this sounds irrelevant – for those of us tethering through a 3G mobile phone connection in the middle of nowhere, it’s a really huge saving!)

But what is the third option – the “embeddable zip file”? It looks like a reasonable download size and it doesn’t have any installer, so it seems quite attractive. However, the embeddable zip file is not actually a regular Python installation. It has a specific purpose and a narrow audience: developers who embed Python in their own native applications.

Why embed Python?

For many users, “Python” is the interactive shell that lets you type code and see immediate results. For others, it is an executable that can run .py files. While these are both true, in reality Python is itself a library that is used to interpreter code. Let’s look at the complete source code for python.exe on Windows:

That’s it! The entire purpose of python.exe is to call a function from python35.dll. Which means it is really easy to create a different executable that will run exactly what you want:

This version will ignore any command line arguments that are passed in, replacing them with an option to always start a particular script. If you give this executable its own name and icon, nobody ever has to know that you used Python at all!

But Python has a much more complete API than this. The official docs are the canonical source of information, but let’s look at a couple of example programs that you may find useful.

Executing a simple Python string

The short program above lets you substitute a different command line, but if you have a string constant you can also execute that. This example is based on the one provided in the docs.

Executing Python directly

Running a string that is predefined or dynamically generated may be useful enough, but the real power of hosting Python comes when you directly interact with the objects. However, this is also when code becomes incredibly complicated.

In almost every situation where it is possible to use Cython or CFFI to generate code for wrapping native objects and values, you should probably use them. However, while they’re great for embedding native code in Python, they aren’t as helpful (at time of writing) for embedding Python into your native code. If you want to allow users to automate your application with a Python script, you’ll need some way of importing the user’s script, and to provide Python functions to call back into your native code.

As an example of hosting Python directly, the program below replicates the one from above but uses direct calls into the Python interpreter rather than a script. (Note that there is no error checking in this sample, and you need a lot of error checking here.)

In a larger application, you’d probably call Py_Initialize as part of your startup and Py_Finalize when exiting, and then have occasional calls into the Python engine wherever it made sense. This way, you can write parts of your application in Python and interact with them directly, or allow your users to extend it by providing their own Python scripts.

How does the embeddable zip file help?

Where does the embeddable zip file come into play? While you need a full Python install to compile these programs, when you install them onto a user’s computer, you only need the contents of the embeddable zip, as well as any (pre-built) packages you need. Header files, documentation, tests and shortcuts are not necessary,

Tools like pynsist will help produce installers for pure Python programs like this, using the embeddable zip file so that you don’t have to worry about whether your users already have Python or not.

Why wouldn’t you just run the regular Python installer as part of your application? Let’s play the “what if two programs did this?” game: program X runs the 3.5.0 installer and then program Y runs the 3.5.1 installer. What version does program X now have? If it ran the installer with a custom install directory, it probably has nothing left at all, but at best it now has 3.5.1.

The regular installer is designed for users, not applications. Programs that are not Python, but use Python, need to handle their own installation to make sure they end up with the correct version in the correct location with all the correct files. The embeddable zip file contains the minimum Python runtime for an application to install by itself.

What about other packages?

The embeddable zip file does not include pip. So how do you install packages? If you didn’t read the last sentence of the previous section, here it is again: the embeddable zip file contains the minimum Python runtime for an application to install by itself.

Using the embeddable zip file implies that you want the minimum required files to run your application, and you have your own installer. So if you need extra files at runtime – such as a Python package – you’ll need to install them with your installer. As mentioned above, for developing an application you should have a full Python installation, that does include pip and can install packages locally. But when distributing your application, you need to take responsibility.

While this seems like more work (and it is more work!), the value is worth it. Do you want your installer to fail because it can’t connect to the internet? Do you want your application to fail because a different version of a library was installed? When you provide a bundle for your users, include everything that it needs (tools like pynsist will help do this automatically).

Where else can I get help?

Though I’m writing about the embeddable distribution on a Microsoft blog, this is actually a CPython feature. The doc page is part of the official Python documentation, and bugs or issues should be filed at the CPython bug tracker.

Источник

Python embeddable zip

With the 3.5.0 release, Python.org has introduced a distribution billed as embeddable zip file.

Unfortunately the zipped file comes without a help file (not even a readme). The download page on Python.org just lists it among the downloads.

Apparently this is a portable Python distribution. It is anyway quite different in structure and size from the standard distribution using the installer.

I realised that it is possible to install pip with get-pip.py and, thanks to pip, it is a breeze to add many other application packages, though I am still unable to add Tkinter (adjust slashes according to your shell):

Add what you need, e.g django:

Given the size (6.5 Mega for the 3.5.1-x64), I think that it can be convenient as a means to create isolated environments.

In fact the general Python documentation says that

the embedded distribution is (almost) fully isolated from the user’s system, including environment variables, system registry settings, and installed package

Given this, in Windows there are now two isolated Python environments, the second being the standard Virtualenv. The same process in Virtualenv is like follows:

and for django it would be:

Which is the difference between Python Virtualenv and Python embeddable?

Specifically, which is the difference between the isolated web app created with the embeddable zip ( env1 ) and Virtualenv ( env2 )?

1 Answer 1

Comparing it to a virtualenv doesn’t make much sense, I think. They have completely different use cases.

In the ms-windows world, applications are generally distributed as monolithic independant entities. In contrast, basically every UNIX flavor has a working package management system which makes it easier to have packages that depend on others. So if you install a python-based app in UNIX, the package management system will basically install Python for you if it isn’t installed yet. On ms-windows this doesn’t work. Several Python distributions for ms-windows have sprung up because (for technical reasons) compiling and setting up stuff on ms-windows is painful [1] compared to UNIX. So having an embeddable Python could make sense for people who want to distribute Python-based programs or who want to embed Python into their application.

In general though I recommend that ms-windows users install either Canopy or Anaconda because they come with most of the external modules that you’ll be likely to need.

Источник

Маленькие Python для маленьких embedded-программистов: CircuitPython и MicroPython для MeowBit

Осознавая это, в 2017 нью-йоркский стартап Adafruit начал разработку собственного форка MicroPython, получившего название CircuitPython. Эта реализация выполняет main.py каждый раз, когда файл с таким названием копируется через USB, и затем «обнуляет» среду, так что переменные из main.py не мешают ни REPL, ни следующему запускаемому скрипту. Чтобы остановить выполнение скрипта, достаточно удалить main.py через USB. В MicroPython нужно проявлять осторожность, чтобы во флеш-память не писали одновременно скрипт и компьютер через USB, иначе файловая система могла повредиться. В CircuitPython же перезапись main.py во время его выполнения – основной сценарий использования, так что ради предосторожности нужно выбрать один из двух вариантов – доступ ко флешу из Python только на чтение и через USB на чтение и запись, либо из Python на чтение и запись и через USB только на чтение, без возможности перезаписи либо удаления main.py. И ещё одна приятная фича – что до перехода в графический режим стандартный вывод дублируется и на последовательный интерфейс, и на экран. С другой стороны, MicroPython позволяет писать на Python обработчики прерываний (с рядом ограничений – например, в них нельзя создавать/удалять объекты на куче и нельзя бросать исключения), а CircuitPython – не позволяет, и не собирается добавлять такую
возможность.

Разница в подходе проявляется и в API. MicroPython стремится к краткости, CircuitPython – к абстракции:

Во втором примере разница в подходе наиболее наглядна: MicroPython предоставляет очень простую и прозрачную модель «создал массив значений пикселей, отправил его целиком на экран», навязывающую программисту довольно неудобный формат RGB565, потому что именно с таким форматом работает экран MeowBit (ST7735). Недостаток этой модели в том, что буфер 160х128х2 занимает 40 КБ – почти всю память, остающуюся свободной после загрузки MicroPython. Держать два таких буфера и отображать их поочерёдно – нет никакой возможности.

Один из моментов, вызванный разницей в подходах, хотелось бы разобрать подробнее: сложно представить игру без музыки и/или звуковых эффектов, но если на время проигрывания звуков игра будет приостанавливаться (как в примерах выше с delay и sleep ), то играть будет очень неудобно. Как же реализовать фоновый звук в двух вариантах Python?

Но теперь фоновый звук будет проигрываться не сам собой, а только при регулярном «дёрганьи» генератора. Это склоняет к тому, чтобы и остальные игровые процессы реализовать
в виде генераторов; например, заставка игры, прокручивающаяся вверх-вниз до нажатия любой
кнопки, реализуется следующим образом:

С одной стороны, реализация на MicroPython даёт заметно более качественный звук, потому что обработчик прерывания вызывается точно в заданное время, тогда как в CircuitPython на время перерисовки экрана (порядка 0.15 с) звук «подвисает». С другой стороны, код на CircuitPython легче писать, легче отлаживать и легче расширять, а реализация игровых процессов в виде сопрограмм-генераторов естественна и в отрыве от требований ко звуку.

Источник