Смысла упаковывать функции в dll, а затем использовать сторонние библиотеки для доступа к этой dll нет. Это глупо и непрактично

что может быть практичного в задаче с названием HelloWorld? Все кто пытаются в первый раз вывести на экран такую фразу - поступают глупо и не практично? давайте не будем так.

С твоими знаниями и нежеланием читать документацию, а так-же искать что-то, ты врятли добьешься того, чего хочешь.

Из чего вы сделали вывод о моих знаниях и нежелании читать документацию? Вы сюда запостили ссылки, на которые из лени я не стал даже и смотреть?

Если тебе просто дали задание написать dll'ку, то пиши на си или, например, ассемблере.

мне не интересно писать dll-ку на C. надо было бы - давно бы написал. по C - материала в инете полно.
если вам есть что сказать по делу - пишите. а хамить от скуки - не надо.

что плохого в том, что мне интересно, - можно ли создать dll из Python (или Python-подобного языка)?
И если я захочу использовать сторонние dll, то мне помешают “лишние знания” о том, как я вызывал свою же тестовую dll?

Ps. Прошу прощения за несдержанность. Но ведь действительно, нельзя же так: “тебе поставили задачу”, “это глупо и непрактично” и т.д.
Настроение испорчено в ноль…

Трудолюбивый и упорный axe.
Учите матчасть и делайте dll на предложенном С. Когда начнет все хорошо получаться - можно подумать о том, чтобы заводить внутри dll интерпретатор и дергать питоновский код. Это гораздно сложнее и требует на порядок больших усилий чем вариант на С.
Я бы сделал если бы потребовалось - но только если по другому никак не обойтись.

Судя по тому, что не прозвучали вопросы:
- кто запускает/останавливает интерпретатор
- dll работает в своей копии питона или нет
- какой формат на вызовы dll
у вас нет необходимого понимания проблемы. Научитесь создавать динамические библиотеки традиционным способом. А потом вернитесь к питону.
Простого решения “из коробки” не существует.

А что должна делать эта библиотека и что ее будет использовать? Если она простая, как ты говоришь, то напиши прототип на питоне, чтобы понятно было всем.

мне всегда казалось, что dll - это просто такой файл, в котором описана некоторая функциональность.
описываем в нём функцию или класс, а далее обращаемся к dll из различных языков через соответствующий враппер и получаем функии, создаём объекты. т.е. по сути, для меня dll - пассивная сущность.

то, что написал выше Андрей Светлов, приводит меня к мысли, что dll-библиотека - это нечто большее.
пока я этот вопрос более подробно не изучил, дейстивтельно, нет смысла со мной его обсуждать.

Андрей Светлов предлагает дёргать python из dll. тогда конечно возникают вопросы, о том, кто должен вызывать интерпретатор и т.д.
у меня была обратная задача - как создать dll и дёрнуть её из python

Упрощенно говоря, dll - это бинарный файл с приложенным списком пар имя->адрес. Это то, что dll экспортирует. Есть еще несколько списков импорта - практически каждая dll зависит от ряда других.
Что делать с именами/адресами - вопрос доброй воли и пользовательских соглашений. Как правило они указывают на функции или переменные. Обратите внимание, что использование классов в dll напрямую не оговаривается. exe, сделаный в Microsoft Visual Studio не поймет dll с классом, скомпилированную MinGW.
Обычно дело обстоит так: видим имя memcpy. С прототип void *memcpy(void *dest, const void *src, size_t count); Соглашение вызова cdecl.

Это значит: укладываем на стек в обратном порядке count, src, dest. Вызываем. Поднимаем из стека результат. Чистим стек от трех параметров.
Если соглашение stdcall - все совсем иначе. fastcall - опять другой. И т.д. Как записываются на этом стеке разные типы аргументов - отдельная песня.

Короче говоря, все довольно непросто. И я описал только С, не С++. У других языков - другие правила. Кроссплатформенного варианта не существует.

Есть еще одна разновидность dll. С первой имеет общее название и частично - заголовок. Это .Net assembly. Гораздо более высокоуровневая организация, куда более сложная и гибкая. Assembly примерно соответствует тому, что вы представляли. И в .net возможны межязыковые вызовы - пока мы находимся в рамках .net. Т.е. из C# можно безо всяких усилий вызвать код из dll на IronPython. Ограничения тоже есть - за пределы .NET платформы ни ногой. По сути это уже не dll, а аналог Java jar или Python egg.

Я не говорил о пользовательских вызовах. Если вы хотите “писать dll на Питоне” - вам нужен интерпретатор, чтобы этот Питон исполнять. Общение с этим интерпретатором тоже прийдется прописывать - python.exe уже не поможет. Именно о взаимодействии с интерпретатором (который написан на С) и были мои вопросы.