hi,
Is it possible to run two completely independent Python interpreters in one
process, each using a thread?
By independent, I mean that no data is shared between the interpreters and thus the C API can be used without any other
"lock/GIL" etc.
mfg
--
https://mail.python.org/mailman/listinf
On 06.08.24 02:32, Lawrence D'Oliveiro wrote:
On Mon, 5 Aug 2024 23:19:14 +0200, aotto1968 wrote:
Is it possible to run two completely independent Python interpreters in
one process, each using a thread?
By independent, I mean that no data is shared between the interpreters
and thus the C API
On 06.08.24 04:34, Grant Edwards wrote:
On 2024-08-05, aotto1968 via Python-list wrote:
Is it possible to run two completely independent Python interpreters
in one process, each using a thread?
By independent, I mean that no data is shared between the
interpreters and thus the C API can be
I would like to present you with a performance test where Python performs very well in relation to the NHI1 project regarding
the integration of Python into C.
-> results:
http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE
-> project: http://thedev
ANNOUNCEMENT
"pymsgque" is the project to integrate the Programming-Language-Micro-Kernel
(*PLMK*) into *Python*.
Together with C, C++, Java, Ruby and Tcl, a growing language community is emerging that will combine *all* existing programming
languages with *PLMK* technology in the future.
: h
On 30.12.24 18:29, Michael Torrie wrote:
On 12/26/24 12:34 AM, aotto1968 via Python-list wrote:
sorry you don't understand the problem…
> You managed to make a build of Python that attempts to link to a DLL
I never touch the OpenSUSE python. the OpenSUSE python try to use my
sqalite
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-
On 14.12.24 10:56, Peter J. Holzer wrote:
On 2024-12-13 11:36:01 +0100, aotto1968 via Python-list wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some
configuration error because apparently a __private__ python installation
__isn't__
On 13.12.24 19:24, Barry wrote:
On 13 Dec 2024, at 15:54, aotto1968 via Python-list
wrote:
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3: error while loading shared
libraries: libpython3.12d.so.1.0: cannot open shared object file: No such file
or directory
This is a debug build
On 13.12.24 11:44, aotto1968 wrote:
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *pytho
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-library
proper __or__ switch to a *s
On 13.12.24 11:36, aotto1968 wrote:
it's a shame...
almost every tool I touch that uses "python" in some way has some configuration error because apparently a __private__ python
installation __isn't__ properly "understood".
-> I think after ~30 years *python* should be able to handle a shared-
I get angry…
next python error…
1) The OpenSUSE command "cnf" checks if a special package feature is installed.
2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3
project directory and never changed the OpenSUSE installat
On 25.12.24 12:05, aotto1968 wrote:
I get angry…
next python error…
1) The OpenSUSE command "cnf" checks if a special package feature is installed.
2) I recently compiled **my** SQLite3 library specifically tailored to **my** requirement and installed it in **my** SQLite3
project directory and
On 25.12.24 23:55, Chris Angelico wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root" python
3) using **my** local non-root library
Yes.
On 26.12.24 06:46, Chris Angelico wrote:
On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list
wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security
On 26.12.24 04:55, Michael Torrie wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root&q
On 26.12.24 04:55, Michael Torrie wrote:
On 12/25/24 3:55 PM, Chris Angelico via Python-list wrote:
On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list
wrote:
It is not only an *usage* error it is also an *security* error because:
1) "cnf" is using OS python
2) os "root&q
On 26.12.24 19:33, Michael Torrie wrote:
On 12/25/24 10:46 PM, Chris Angelico wrote:
Right. That's exactly what would happen if he'd built Python using
absolute paths to libraries, which is the normal way to do it. And so
the solution is to rebuild Python using absolute paths to libraries.
You
19 matches
Mail list logo
