🌐 Mailman 3 December 2024 - Python-list - python.org

Re: Python List is Not Dead
by Chris Green Dec. 31, 2024

Dec. 31, 2024

Cameron Simpson <cs(a)cskk.id.au> wrote: > On 25Dec2024 14:52, Abdur-Rahmaan Janhangeer <arj.python(a)gmail.com> wrote: > >I have been following discussions on Discourse (discuss.python.org) > >these last times. > > > >I think that it definitely lacks some of the joys of the mailing list: > > FYI, it has a very good "mailing list" mode. I use it that was >90% of > the time, and file both posts from Discourse and posts from python-list > into my "python" mail folder. Yes, it's the one saving grace of a Discourse forum, you can use it by E-Mail and it behaves quite nicely with a text mode E-Mail client such as mutt so you can keep threads separate, follow sub-threads, etc. Not quite as good as this list gatewayed to usenet though, there's really nothing so good as usenet for proper discourse (!). -- Chris Green ·

3 2

Re: it's a shame... python error over error
by aotto1968 Dec. 30, 2024

Dec. 30, 2024

On 25.12.24 23:55, Chris Angelico wrote: > On Thu, 26 Dec 2024 at 09:27, aotto1968 via Python-list > <python-list(a)python.org> 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.

3 2

Python List is Not Dead
by Abdur-Rahmaan Janhangeer Dec. 29, 2024

Dec. 29, 2024

Hey all, I have been following discussions on Discourse (discuss.python.org) these last times. I think that it definitely lacks some of the joys of the mailing list: 1/ Categories The discussion has fixed categories. No channel for fun posts, project releases or musings. 2/ Ui Good luck getting to the bottom of big threads. Hello JS! PS. You can but it's not intuitive. 3/ Quality I find great posts here and there on the mailing list. I can't seem to find great posts over there. Just sharing my POV. I like the mailing list ^^, Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius

7 7

Re: it's a shame... python error over error
by aotto1968 Dec. 27, 2024

Dec. 27, 2024

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.

1 0

it's a shame... python error over error
by aotto1968 Dec. 26, 2024

Dec. 26, 2024

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/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]: 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 (0x00007ffd18e9a000) libpython3.12d.so.1.0 => HOME/ext/x86_64-suse-linux-gnu/debug/lib64/libpython3.12d.so.1.0 (0x00007f9c5d374000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f9c5d350000) libdl.so.2 => /lib64/libdl.so.2 (0x00007f9c5d349000) libutil.so.1 => /lib64/libutil.so.1 (0x00007f9c5d345000) libm.so.6 => /lib64/libm.so.6 (0x00007f9c5d1f9000) libc.so.6 => /lib64/libc.so.6 (0x00007f9c5d002000) /lib64/ld-linux-x86-64.so.2 (0x00007f9c5dab4000)

6 16

Re: it's a shame... python error over error
by aotto1968 Dec. 26, 2024

Dec. 26, 2024

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 >> <python-list(a)python.org> 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.

1 0

Re: it's a shame... python error over error
by aotto1968 Dec. 26, 2024

Dec. 26, 2024

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 >> <python-list(a)python.org> 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.

1 0

Re: it's a shame... python error over error
by aotto1968 Dec. 26, 2024

Dec. 26, 2024

On 26.12.24 06:46, Chris Angelico wrote: > On Thu, 26 Dec 2024 at 14:57, Michael Torrie via Python-list > <python-list(a)python.org> 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 >>> <python-list(a)python.org> 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.

1 0

How to go about describing my software with a component diagram?
by marc nicole Dec. 25, 2024

Dec. 25, 2024

Hello community, I have created a Python code where a main algorithm uses three different modules (.py) after importing them. To illustrate and describe it I have created the following component diagram? [image: checkso.PNG] Could it be improved for better description and readability? Thanks!

5 12

Re: Lengthy numbers
by Oscar Benjamin Dec. 22, 2024

Dec. 22, 2024

On Sun, 22 Dec 2024 at 19:17, Gilmeh Serda via Python-list <python-list(a)python.org> wrote: > > Was just playing with numbers and stumbled on something I've never seen > before. ... > > >>> 9**9**4 > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > ValueError: Exceeds the limit (4300 digits) for integer string conversion; > use sys.set_int_max_str_digits() to increase the limit > > Explanation: > https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bu… I think that the original security concern was mainly motivated by the string to int direction i.e. calling int(s) for a possibly large string s (possibly from an untrusted source) might be slow with CPython. To solve that problem conversions from string->int and int->string were disallowed. Now that more time has passed it becomes clearer that disabling int->string conversion is more likely to be the thing that people bump into as a result of this limitation (as you just did). I find it harder to see what the security problem is in that direction but I don't think this will be changed. CPython has an implementation of arbitrarily large integers but an important part of it is hobbled. If you do want to work with such large integers then I recommend using either gmpy2's gmpy2.mpz type or python-flint's flint.fmpz type. At the same time it is not hard to run into slowness with integers e.g. 10**10**10 but that won't come up in string parsing if not using eval. Not a likely security issue but I am suddenly reminded of this dangerous snippet: x = [0]; x.extend(iter(x)) If you want to test it then make sure to save your work etc and be prepared to hard reset the computer. On this machine Ctrl-C doesn't work for this but Ctrl-\ does if you do it quick enough. -- Oscar

1 0