python C-api and thread

[aotto1968 via Python-list]

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/listinfo/python-list

Re: python C-api and thread (Posting On Python-List Prohibited)

[aotto1968 via Python-list]

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 can be used without any other "lock/GIL" etc.


Seems like yes
.


→ I think that could be a solution.
--
https://mail.python.org/mailman/listinfo/python-list

Re: python C-api and thread

[aotto1968 via Python-list]

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 used without any other
"lock/GIL" etc.


No, not using any OS I've ever seen. The usual definition of "threads"
is that they share data, and the definition of "processes" is that
processes don't share data.

How exactly does what you're trying to do differ from runnig two
Python interpreters in two processes?

--
Grant





I know but I use a thread like a process because the "conversation" between the 
threads is done by my
software. a Thread is usually faster to startup (thread-pool) this mean for 
high-load this is
significant faster even than fork.
--
https://mail.python.org/mailman/listinfo/python-list

performance test on python with C API interface

[aotto1968 via Python-list]

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.nhi1.de/NHI1/main/
--
https://mail.python.org/mailman/listinfo/python-list

[ANN] (preview) “pymsgque” is the connection between Tcl and the “Programming Language Micro-Kernel” (PLMK).

[aotto1968 via Python-list]

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.


: http://thedev.nhi1.de/NHI1/main/

“pymkkernel” extends *Python* with a “code integrator” so that a 3rd party library can be connected to *Python* without 
additional programming effort.


: http://thedev.nhi1.de/theKernel/main/index.htm

“pymqmsgque” extends *Python* with a “code parallelizer” so that existing *Python* code can be parallelized and integrated into 
a multiprocessor environment.


: http://thedev.nhi1.de/theLink/main/index.htm


PERFORMANCE
---

: 
http://thedev.nhi1.de/theLink/main/md_docs_2main_2README__PERFORMANCE.htm#README_PERFORMANCE

*Python* has good performance, compared to *TclOO* and *Ruby*, *Python* is on 
the same level as *Ruby*.

|   send send send sendcreatecreatedata 
data
|  NOTHING   ENDCALLBACK   WAITPARENTCHILD BUS  
BFL
|     -   


 R: Tcl |   332380   190834   12056561112  1322358943077
42926
 R: Python  |   493313   315040   16086975802  1032198268504
65800
 R: Ruby|   436564   301587   16592177032   521633071040
63967


occasional updates to the project are available as screenshots on social media.

: Facebook -> https://www.facebook.com/profile.php?id=100069563501101
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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
sqalite3.


The *only* mechanism that would cause the system python binary to try to
load modules and libraries from your local install is your environment
(environment variables).



that is right because MY environment variable point to MY local user stuff.

The CORE problem is that OpenSUSE (Linux) python use MY env.

If I call a OS feature like "cnf" this should NOT interact with my private user 
stuff.

the OpenSUSE do it right because OpenSUSE use /usr/bin/python in "cnf" BUT the
python think to interact with MY env.

To make it short: The OS python will NEVER proper work if LOCAL user stuff is 
used.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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-library 
proper __or__ switch to a *static-build* by default.

-> example here is the "mono-build" with the following installation.

make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
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

make[2]: Für das Ziel „install-exec-am“ ist nichts zu tun.
make[2]: Für das Ziel „install-data-am“ ist nichts zu tun.
make[2]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
[debug]dev1usr@linux02:~/src/mono.git> ldd 
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
     linux-vdso.so.1 (0x7ffd18e9a000)
     libpython3.12d.so.1.0 => 
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 
(0x7f9c5d374000)
     libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9c5d35)
     libdl.so.2 => /lib64/libdl.so.2 (0x7f9c5d349000)
     libutil.so.1 => /lib64/libutil.so.1 (0x7f9c5d345000)
     libm.so.6 => /lib64/libm.so.6 (0x7f9c5d1f9000)
     libc.so.6 => /lib64/libc.so.6 (0x7f9c5d002000)
     /lib64/ld-linux-x86-64.so.2 (0x7f9c5dab4000)



If I read the answers I come to the conclusion that the "supporters" at python 
doesn't ever understand the problem.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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__ properly "understood".

-> I think after ~30 years *python* should be able to handle a shared-library 
proper __or__ switch to a *static-build* by default.

-> example here is the "mono-build" with the following installation.

make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
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


What is HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 and why is
HOME/src/mono.git/acceptance-tests trying to use it?

[...]

make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird verlassen
[debug]dev1usr@linux02:~/src/mono.git> ldd 
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
 linux-vdso.so.1 (0x7ffd18e9a000)
 libpython3.12d.so.1.0 => 
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 
(0x7f9c5d374000)
 libpthread.so.0 => /lib64/libpthread.so.0 (0x7f9c5d35)
 libdl.so.2 => /lib64/libdl.so.2 (0x7f9c5d349000)
 libutil.so.1 => /lib64/libutil.so.1 (0x7f9c5d345000)
 libm.so.6 => /lib64/libm.so.6 (0x7f9c5d1f9000)
 libc.so.6 => /lib64/libc.so.6 (0x7f9c5d002000)
 /lib64/ld-linux-x86-64.so.2 (0x7f9c5dab4000)


So HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 does find
HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 if you
invoke it from the shell (to confirm that, try actually invoking it
instead of running ldd on it), but not when it's called from whatever
make is doing in the acceptance-tests directory.

So it might be because it's in a different directory ("HOME/ext/..." is
a relative path. That will not work in a different directory. Also
"HOME" is a strange choice for a directory name. Did you mean $HOME?) or
because the acceptance tests set up their own environment.

I'd test the first idea first. Cd into
HOME/src/mono.git/acceptance-tests and try to invoke
HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3 there.

 hp



The CORE problem is that python3 works well in *my* environment but the
installation is done as root and root does not use *my* environment.

the mono build search for a working python3 and find *my*
> HOME/ext/x86_64-suse-linux-gnu/debug/bin/python3
The build is fine but after switch to root for installation
> sudo make install
the root user call *my* python3 and fail.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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?

Try setting LD_LIBRARY_PATH to point at the folder that contains the .so.
Test with `ldd python3` which will show which .so libs python3 needs and if 
they are found.

This is what I see on Fedora 41 as an example of the output.

$ ldd /usr/bin/python3
 linux-vdso.so.1 (0xb8515000)
 libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 
(0xb7ea)
 libc.so.6 => /lib64/libc.so.6 (0xb7cd)
 libm.so.6 => /lib64/libm.so.6 (0xb7c2)
 /lib/ld-linux-aarch64.so.1 (0xb84d)

Barry




the problem is *not* to setup an environment variable, the problem is that 
python is *not*
able to setup the *python* environment by it self.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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 *python* should be able to handle a shared-library proper __or__ switch to a *static-build* by 
default.


-> example here is the "mono-build" with the following installation.



1. The build is done with my user and the installation is done as root.
2. The setup proper find *my* python3 because my PATH etc is setup well.
3. root is an other environment and root does *not* have my environment.
4. root uses *my* python3 without *my* environment and is *not* able to find
    *my* libpython3.12d.so.1.0
5. obviously the *python3* is *not* able to create the right environment from
   the installation directory of the *python3* executable.


even the `sudo -E make install` with "-E, --preserve-env" does help.
--
https://mail.python.org/mailman/listinfo/python-list

it's a shame... python error over error

[aotto1968 via Python-list]

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 *static-build* by default.

-> example here is the "mono-build" with the following installation.

make[1]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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

make[2]: Verzeichnis „HOME/src/mono.git/acceptance-tests“ wird betreten
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
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
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
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
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
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
HOME/ext/x86_64-suse-linux-gnu/debug/bi

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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-library 
proper __or__ switch to a *static-build* by default.

-> example here is the "mono-build" with the following installation.



1. The build is done with my user and the installation is done as root.
2. The setup proper find *my* python3 because my PATH etc is setup well.
3. root is an other environment and root does *not* have my environment.
4. root uses *my* python3 without *my* environment and is *not* able to find
   *my* libpython3.12d.so.1.0
5. obviously the *python3* is *not* able to create the right environment from
  the installation directory of the *python3* executable.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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 installation.
3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s 
own "Python" and "Sqlite3" software.

4) Now the "cnf" fails with "Python" which apparently tries to use **my** 
SQLite3.

> what a shame.


> cnf jmc
Traceback (most recent call last):
  File "/usr/bin/cnf", line 9, in 
import scout
  File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in 

import sqlite3
  File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in 
from sqlite3.dbapi2 import *
  File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in 
from _sqlite3 import *
ImportError: 
/usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: 
undefined symbol: sqlite3_trace

--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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 never changed the OpenSUSE installation.
3) "cnf" seems to use "Python" internally, but is **not** able to configure the *Python* environment to use only "OpenSUSE"'s 
own "Python" and "Sqlite3" software.

4) Now the "cnf" fails with "Python" which apparently tries to use **my** 
SQLite3.

 > what a shame.


 > cnf jmc
Traceback (most recent call last):
   File "/usr/bin/cnf", line 9, in 
     import scout
   File "/usr/lib/python3.6/site-packages/scout/__init__.py", line 10, in 

     import sqlite3
   File "/usr/lib64/python3.6/sqlite3/__init__.py", line 23, in 
     from sqlite3.dbapi2 import *
   File "/usr/lib64/python3.6/sqlite3/dbapi2.py", line 27, in 
     from _sqlite3 import *
ImportError: 
/usr/lib64/python3.6/lib-dynload/_sqlite3.cpython-36m-x86_64-linux-gnu.so: 
undefined symbol: sqlite3_trace



It is not only an *usage* error it is also an *security* error because:

1) "cnf" is using OS python

> head /usr/bin/cnf
#!/usr/bin/python3

import gettext
import os
...

2) os "root" python
> ls -al /usr/bin/python3
lrwxrwxrwx 1 root root 9  2. Dez 13:16 /usr/bin/python3 -> python3.6
> ls -al /usr/bin/python3.6
-rwxr-xr-x 2 root root 10560  2. Dez 13:16 /usr/bin/python3.6

3) using **my** local non-root library
> ls -al NHI1_EXT/lib64/libsqlite3.so.0
lrwxrwxrwx 1 dev1usr users 19 23. Dez 22:09 NHI1_EXT/lib64/libsqlite3.so.0 -> 
libsqlite3.so.0.8.6
> ls -al NHI1_EXT/lib64/libsqlite3.so.0.8.6
-rwxr-xr-x 1 dev1usr users 3851872 23. Dez 22:09 
NHI1_EXT/lib64/libsqlite3.so.0.8.6
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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. And YOU were the one who installed a new root Python. This is a
feature. You have the power to update Python on your system.

You managed to make a build of Python that attempts to link to a DLL
using a relative path. That's a fault of the build that means it won't
work as root. I don't understand the confusion here; isn't the
solution here to build a new version with an absolute path, and update
your installation?

ChrisA


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
sqalite3.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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* error because:

1) "cnf" is using OS python
2) os "root" python
3) using **my** local non-root library


I think he means the cnf is using the "root" OS python in /usr/bin, but
/usr/bin/python3 is trying to import his local build of sqlite3, which
cause it to fail. I assume he would like cnf to not try to import his
local sqlite3, and instead use the normal system one. If this is the
case, then somehow his local, non-root sqlite3 library is being picked
up by the system version of python.


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.

ChrisA


next I don't change the OpenSUSE python and the OpenSUSE python is using *my*
sqlite3.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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" python
3) using **my** local non-root library


I think he means the cnf is using the "root" OS python in /usr/bin, but
/usr/bin/python3 is trying to import his local build of sqlite3, which
cause it to fail. I assume he would like cnf to not try to import his
local sqlite3, and instead use the normal system one. If this is the
case, then somehow his local, non-root sqlite3 library is being picked
up by the system version of python.

Aotto might want to run the "env" command and see if there are any
search paths that have to do with Python.  I can see how this could be a
security issue. If you can figure out what's happening you might want to
open a ticket with the OpenSUSE developers.  This is Python related, but
it's not necessarily python's fault per se.


Yes I using with *my* user *my* environment but never touch the *root*
environment at all.

the *root* python try to use *my* sqlite3 because *my* environment
fit to *my* needs.

/* just a reminder */

sqlite3 have a "special" (worse) setup that a change to the configuration
also change the "api" ( a sqlite_function disappear or arrive ).
If a tool like python using an extension that is linked to sqlite3 that 
extension
will likely FAIL is I get an OTHER sqlite3 which is NOT the one the extension
was build with.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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" python
3) using **my** local non-root library


I think he means the cnf is using the "root" OS python in /usr/bin, but
/usr/bin/python3 is trying to import his local build of sqlite3, which
cause it to fail. I assume he would like cnf to not try to import his
local sqlite3, and instead use the normal system one. If this is the
case, then somehow his local, non-root sqlite3 library is being picked
up by the system version of python.

Aotto might want to run the "env" command and see if there are any
search paths that have to do with Python.  I can see how this could be a
security issue. If you can figure out what's happening you might want to
open a ticket with the OpenSUSE developers.  This is Python related, but
it's not necessarily python's fault per se.


You don't understand the problem if you think "/usr/bin/env"  will solve the
problem → this will make it more worse.

A "personal" python will use a "personal" configuration and probably is *not*
build with sqlite3 support at all.

a *root* tool should never ever use/call a non *root* (personal) setup.
--
https://mail.python.org/mailman/listinfo/python-list

Re: it's a shame... python error over error

[aotto1968 via Python-list]

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're right. Definitely appears to be a pretty major mis-configuration
of his system. Not much we can do about that.



no, your are wrong.

The problem is NOT that my user-account has a miss-configuration because my
user-account works pretty well…

The problem is that the *default* /usr/bin/python3 OpenSUSE installation using
parts of *my* local *user* setup.
--
https://mail.python.org/mailman/listinfo/python-list