Re: SQLObject 3.12.0

[Mohammadreza Saveji via Python-list]

thank a lot Oleg.
have a nice day.

On Fri, Dec 20, 2024 at 4:56 PM Oleg Broytman via Python-list <
python-list@python.org> wrote:

> 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
>   
>   >>> p.fname
>   'John'
>   >>> p.mi = 'Q'
>   >>> p2 = Person.get(1)
>   >>> p2
>   
>   >>> p is p2
>   True
>
> Queries::
>
>   >>> p3 = Person.selectBy(lname="Doe")[0]
>   >>> p3
>   
>   >>> pc = Person.select(Person.q.lname=="Doe").count()
>   >>> pc
>   1
>
> Oleg.
> --
> Oleg Broytmanhttps://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Lengthy numbers

[Oscar Benjamin via Python-list]

On Sun, 22 Dec 2024 at 19:17, Gilmeh Serda via Python-list
 wrote:
>
> Was just playing with numbers and stumbled on something I've never seen
> before.
...
>
> >>> 9**9**4
> Traceback (most recent call last):
>   File "", line 1, in 
> 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-bugfix-releases/18889

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