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

SQLObject 3.12.0
by Oleg Broytman Dec. 22, 2024

Dec. 22, 2024

Hello! I'm pleased to announce version 3.12.0, the release of branch 3.12 of SQLObject. What's new in SQLObject ======================= Drivers ------- * Add support for CyMySQL; there're some problems with unicode yet. * Separate ``psycopg`` and ``psycopg2``; ``psycopg`` is actually ``psycopg3`` now; not all tests pass. * Minor fix in getting error code from PyGreSQL. * Dropped ``oursql``. It wasn't updated in years. * Dropped ``PySQLite2``. Only builtin ``sqlite3`` is supported. Tests ----- * Run tests with Python 3.13. * Run tests with ``psycopg-c``; not all tests pass. * Fix ``test_exceptions.py`` under MariaDB, PostgreSQL and SQLite. * ``py-postgres``: Set ``sslmode`` to ``allow``; upstream changed default to ``prefer``. CI -- * Run tests with ``PyGreSQL`` on w32, do not ignore errors. * Skip tests with ``pg8000`` on w32. * GHActions: Switch to ``setup-miniconda``. * GHActions: Python 3.13. For a more complete list, please see the news: http://sqlobject.org/News.html What is SQLObject ================= SQLObject is a free and open-source (LGPL) Python object-relational mapper. Your database tables are described as classes, and rows are instances of those classes. SQLObject is meant to be easy to use and quick to get started with. SQLObject supports a number of backends: MySQL/MariaDB (with a number of DB API drivers: ``MySQLdb``, ``mysqlclient``, ``mysql-connector``, ``PyMySQL``, ``mariadb``), PostgreSQL (``psycopg2``, ``PyGreSQL``, partially ``pg8000`` and ``py-postgresql``), SQLite (builtin ``sqlite3``); connections to other backends - Firebird, Sybase, MSSQL and MaxDB (also known as SAPDB) - are less debugged). Python 2.7 or 3.4+ is required. Where is SQLObject ================== Site: http://sqlobject.org Download: https://pypi.org/project/SQLObject/3.12.0 News and changes: http://sqlobject.org/News.html StackOverflow: https://stackoverflow.com/questions/tagged/sqlobject Mailing lists: https://sourceforge.net/p/sqlobject/mailman/ Development: http://sqlobject.org/devel/ Developer Guide: http://sqlobject.org/DeveloperGuide.html Example ======= Install:: $ pip install sqlobject Create a simple class that wraps a table:: >>> from sqlobject import * >>> >>> sqlhub.processConnection = connectionForURI('sqlite:/:memory:') >>> >>> class Person(SQLObject): ... fname = StringCol() ... mi = StringCol(length=1, default=None) ... lname = StringCol() ... >>> Person.createTable() Use the object:: >>> p = Person(fname="John", lname="Doe") >>> p <Person 1 fname='John' mi=None lname='Doe'> >>> p.fname 'John' >>> p.mi = 'Q' >>> p2 = Person.get(1) >>> p2 <Person 1 fname='John' mi='Q' lname='Doe'> >>> p is p2 True Queries:: >>> p3 = Person.selectBy(lname="Doe")[0] >>> p3 <Person 1 fname='John' mi='Q' lname='Doe'> >>> pc = Person.select(Person.q.lname=="Doe").count() >>> pc 1 Oleg. -- Oleg Broytman https://phdru.name/ phd(a)phdru.name Programmers don't die, they just GOSUB without RETURN.

2 1

Join us for the 2025 DIPY Workshop! - March 17-21 Online! - Early Bird Ends Jan 3rd!
by Eleftherios Garyfallidis Dec. 17, 2024

Dec. 17, 2024

Dear All, DIPY is a software that analyzes structural and diffusion MRI images using Python. We are excited to invite you to our upcoming DIPY workshop, which will take place from March 17 to March 21, 2025. This year, we promise an enriching experience as we dive into the world of AI in advanced imaging and data analytics. Our distinguished keynote speakers include Prof. Simon Warfield (Harvard Medical School), Prof. Alexandra Badea (Duke University), Prof. Franco Pestilli (University of Texas at Austin), Prof. Marco Palombo (Cardiff University), and Prof. Julien Cohen-Adad (Polytechnique Montreal). Additionally, Koudoro, Descoteaux, Tang, Rokem, Chandio, Fadnavis, Henriques, Legarreta, and others will present various techniques in medical imaging, including (but not limited to) pre-processing, reconstruction, denoising, microstructure modeling, tractography, and visualization. This year’s highlights include the overview of our *new ultra-fast tracking* API by Girard (CPU) and Kruper (GPU) and much more! The DIPY workshop aims to train the next generation of scientists, doctors, and engineers who will shape the future of medical imaging. Your participation will contribute greatly to the success of this event. As is customary for the DIPY workshop, the following will be available: - Daily hands-on sessions for guided practice - Opportunities for attendees to present their work or problems of interest - Certificates of Attendance Please visit our website *here* <https://workshop.dipy.org/workshops/dipy-workshop-2025> to register for the workshop. We look forward to your participation and to exploring the exciting work of imaging science together. DIPY is also offering Early Bird discounts until January 3rd, 2025. Register soon to take advantage of these offers! For any concerns, please email *workshop(a)dipy.org <workshop(a)dipy.org>*. On behalf of the DIPY team, Eleftherios Garyfallidis, PhD DIPY Founder & Lead Associate Professor Intelligent Systems Engineering Indiana University Luddy Hall 700 N Woodlawn Bloomington, IN 47408 GRG <https://grg.luddy.indiana.edu/> | DIPY <http://dipy.org/> | FURY <https://fury.gl/>

1 0

[RELEASE] Python 3.14.0 alpha 3 is out
by Hugo van Kemenade Dec. 17, 2024

Dec. 17, 2024

O Alpha 3, O Alpha 3, how lovely are your branches! https://www.python.org/downloads/release/python-3140a3/ This is an early developer preview of Python 3.14. Python 3.14 is still in development. This release, 3.14.0a3, is the third of seven planned alpha releases. Alpha releases are intended to make it easier to test the current state of new features and bug fixes and to test the release process. During the alpha phase, features may be added up until the start of the beta phase (2025-05-06) and, if necessary, may be modified or deleted up until the release candidate phase (2025-07-22). Please keep in mind that this is a preview release and its use is not recommended for production environments. Many new features for Python 3.14 are still being planned and written. Among the new major new features and changes so far: * PEP 649: deferred evaluation of annotations * PEP 741: Python configuration C API * PEP 761: Python 3.14 and onwards no longer provides PGP signatures for release artifacts. Instead, Sigstore is recommended for verifiers. * Improved error messages * (Hey, fellow core developer, if a feature you find important is missing from this list, let Hugo know.) The next pre-release of Python 3.14 will be 3.14.0a4, currently scheduled for 2025-01-14. More resources: * Online documentation: https://docs.python.org/3.14/ * PEP 745, 3.14 Release Schedule: https://peps.python.org/pep-0745/ * Report bugs at https://github.com/python/cpython/issues * Help fund Python and its community: https://www.python.org/psf/donations/ And now for something completely different A mince pie is a small, round covered tart filled with “mincemeat”, usually eaten during the Christmas season – the UK consumes some 800 million each Christmas. Mincemeat is a mixture of things like apple, dried fruits, candied peel and spices, and originally would have contained meat chopped small, but rarely nowadays. They are often served warm with brandy butter. According to the Oxford English Dictionary, the earliest mention of Christmas mince pies is by Thomas Dekker, writing in the aftermath of the 1603 London plague, in Newes from Graues-end: Sent to Nobody (1604): Ten thousand in London swore to feast their neighbors with nothing but plum-porredge, and mince-pyes all Christmas. Here’s a meaty recipe from Rare and Excellent Receipts, Experienc’d and Taught by Mrs Mary Tillinghast and now Printed for the Use of her Scholars Only (1678): XV. How to make Mince-pies. To every pound of Meat, take two pound of beef Suet, a pound of Corrants, and a quarter of an Ounce of Cinnamon, one Nutmeg, a little beaten Mace, some beaten Colves, a little Sack & Rose-water, two large Pippins, some Orange and Lemon peel cut very thin, and shred very small, a few beaten Carraway-seeds, if you love them the Juyce of half a Lemon squez’d into this quantity of meat; for Sugar, sweeten it to your relish; then mix all these together and fill your Pie. The best meat for Pies is Neats-Tongues, or a leg of Veal; you may make them of a leg of Mutton if you please; the meat must be parboyl’d if you do not spend it presently; but if it be for present use, you may do it raw, and the Pies will be the better. Enjoy the new release Thanks to all of the many volunteers who help make Python Development and these releases possible! Please consider supporting our efforts by volunteering yourself or through organisation contributions to the Python Software Foundation. Regards from a snowy and slippery Helsinki, Your release team, Hugo van Kemenade Ned Deily Steve Dower Łukasz Langa

1 0

Division-Bug in decimal and mpmath
by Martin Ruppert Dec. 15, 2024

Dec. 15, 2024

Hi, the division 0.4/7 provides a wrong result. It should give a periodic decimal fraction with at most six digits, but it doesn't. Below is the comparison of the result of decimal, mpmath, dc and calc. 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 0.05714285714285715 builtin: 0.4/7 Both decimal and mpmath give an identical result, which is not a periodic decimal fraction with at most six digits. calc and dc provide as well an identical result, which *is* a periodic decimal fraction with six digits, so I think that's right. Below ist the python-script, with which the computation was done. Best regards Martin Ruppert #!/usr/bin/env python3 from decimal import Decimal as dec from mpmath import * from os import popen import decimal z=.4 nen=7 decimal.getcontext().prec=60 print(dec(z)/dec(nen),end=' ');print(f"decimal: {z}/{nen}") mp.dps=60 a=fdiv(z,nen);print(a,end=' ');print(f"mpmath: {z}/{nen}") f=popen(f"dc -e'61k{z} {nen}/f'") for i in f:i=i.rstrip() f.close() print(f"0{i}",end=' ');print(f"dc: {z}/{nen}") f=popen(f"calc 'config(\"display\",61);{z}/{nen}'") j=0 for i in f: if j>0:i=i.rstrip();print(i,end=' ');print(f"calc: {z}/{nen}") j+=1 f.close() print(f"{z/nen}",end=' ');print(f"builtin: {z}/{nen}") -- ruppert(a)hs-worms.de

4 3

Re: Division-Bug in decimal and mpmath
by Mark Bourne Dec. 15, 2024

Dec. 15, 2024

2QdxY4RzWzUUiLuE(a)potatochowder.com wrote: > On 2024-12-14 at 12:08:29 +0000, > Mark Bourne via Python-list <python-list(a)python.org> wrote: > >> Martin Ruppert wrote: >>> Hi, >>> >>> the division 0.4/7 provides a wrong result. It should give a periodic >>> decimal fraction with at most six digits, but it doesn't. >>> >>> Below is the comparison of the result of decimal, mpmath, dc and calc. >>> >>> 0.0571428571428571460292086417861615440675190516880580357142857 decimal: 0.4/7 >>> 0.0571428571428571460292086417861615440675190516880580357142857 mpmath: 0.4/7 >>> 0.0571428571428571428571428571428571428571428571428571428571428 dc: 0.4/7 >>> 0.0571428571428571428571428571428571428571428571428571428571429 calc: 0.4/7 >>> 0.05714285714285715 builtin: 0.4/7 >>> >>> Both decimal and mpmath give an identical result, which is not a >>> periodic decimal fraction with at most six digits. >>> >>> calc and dc provide as well an identical result, which *is* a periodic >>> decimal fraction with six digits, so I think that's right. >> >> I looks like you might be running into limitations in floating-point >> numbers. At least with decimal, calculating 4/70 instead of 0.4/7 appears >> to give the correct result. As does: >> ``` >> from decimal import Decimal as dec >> z2 = dec(4) / dec(10) >> print(z2 / dec(nen)) >> ``` >> You can also pass a string, and `dec("0.4")/dec(10)` gives the correct >> result as well. >> >> Your `z` is a float, and therefore limited by the precision of a float. It >> doesn't represent exactly 0.4, since that can't be exactly represented by a >> float. Anything you do from then on is limited to that precision. >> >> I can't easily find documentation for dc and calc (links from PyPI are >> either broken or don't exist), but I'm guessing they use some heuristics to >> determine that the float passed in very close to 0.4 so that was probably >> intended, rather than using the exact value represented by that float. > > I'm going to guess that since dc is a shell utility and calc is either > another shell utility or the calculator in emacs, and that they both do > their own conversion from a string to an internal representation without > going through an IEEE float. Oh yes. Thinking the question was about 4 different Python packages, I'd just looked up the packages with those names on PyPI and hadn't noticed they were separate commands being called via popen! In that case, the string formatting of a float in the commands defaults to 6 decimal places, and `z` is rounded back to 0.4 rather than the exact value represented by the float. From there, as you say, `dc` and `calc` probably handle that string similarly to `decimal.Decimal` being passed the string "0.4". > Why couldn't we have evolved with eight fingers on each hand? ;-) Yeah, it would have made conversions to and from binary somewhat more intuitive... -- Mark.

1 0

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

Dec. 14, 2024

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 (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) > > 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.

3 2

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

Dec. 14, 2024

On 13.12.24 19:24, Barry wrote: > > >> On 13 Dec 2024, at 15:54, aotto1968 via Python-list <python-list(a)python.org> 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 (0x0000ffffb8515000) > libpython3.13.so.1.0 => /lib64/libpython3.13.so.1.0 (0x0000ffffb7ea0000) > libc.so.6 => /lib64/libc.so.6 (0x0000ffffb7cd0000) > libm.so.6 => /lib64/libm.so.6 (0x0000ffffb7c20000) > /lib/ld-linux-aarch64.so.1 (0x0000ffffb84d0000) > > 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.

2 1

Re: ModuleNotFoundError for youtube_dl
by jkn Dec. 10, 2024

Dec. 10, 2024

On 10/12/2024 01:41, Tim Johnson wrote: > > On 12/9/24 14:59, Tim Johnson wrote: >> >> Recently did a refresh of ubuntu 24.04 >> >> With no code changes am now getting a *ModuleNotFoundError *for >> youtube_dl >> >> Relevant code is >> >> import sys >> sys.path.append("/home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl") >> >> import youtube_dl ' >> >> Navigating to >> /home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl, >> >> I see the following >> >> tim@beelink:~/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl$ ls >> aes.py compat.py extractor jsinterp.py options.py >> __pycache__ swfinterp.py utils.py YoutubeDL.py >> cache.py downloader __init__.py __main__.py postprocessor >> socks.py update.py version. >> > I should not have appended 'youtube_dl' to the path. I used the content > from > /home/tim/.local/share/pipx/shared/lib/python3.12/site-packages/pipx_shared.pth > > ("/home/tim/.local/share/pipx/shared/lib/python3.12/site-packages") and > added that to /usr/lib/python3.12/sitecustomize.py as appended to sys.path > > and it appears to be solved. FWIW I think youtube_dl has largely been supplanted by the (maintained) 'yt-dlp' these days J^n

1 0

ModuleNotFoundError for youtube_dl
by Tim Johnson Dec. 9, 2024

Dec. 9, 2024

Recently did a refresh of ubuntu 24.04 With no code changes am now getting a *ModuleNotFoundError *for youtube_dl Relevant code is import sys sys.path.append("/home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl") import youtube_dl ' Navigating to /home/tim/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl, I see the following tim@beelink:~/.local/share/pipx/venvs/youtube-dl/lib/python3.12/site-packages/youtube_dl$ ls aes.py compat.py extractor jsinterp.py options.py __pycache__ swfinterp.py utils.py YoutubeDL.py cache.py downloader __init__.py __main__.py postprocessor socks.py update.py version.py I've been retired from python programming for 10 years now, and just tinker or write stuff for myself to use on my own workstation, so I have obviously forgotten a lot (if you don't use it you lose it, right) I hope that someone can help me correct this. thanks tim

1 1

How to catch a fatal error in Python 2.7?
by marc nicole Dec. 9, 2024

Dec. 9, 2024

Hello, The fatal error exits the program with a code -1 while referencing the memory address involved and nothing else. How to catch it in Python 2.7? PS: please not I am not talking about exceptions but an error resulting from the disconnection of my bluetooth microphone abruptly and leading to the halting of the whole program, I need to be able to do something when it occurs. Thanks for the help!

2 1