Hi Mike.
Thanks, it makes sense. On another topic, the docs say:
However, version 2.0 hopes to start embracing *PEP 484*
<https://www.python.org/dev/peps/pep-0484> and other new features to a
great degree
Would you please explain why SQLAlchemy wants to move to embracing type
hints to a large degree? I'm a bit ambivalent towards type hints and would
love to hear your perspective.
Thanks and best regards,
Matthew
On Thursday, May 13, 2021 at 5:54:21 AM UTC-7 Mike Bayer wrote:
> SQLAlchemy has a general philosophy of fn(*args) vs fn(list):
>
> 1. if the sequence of items represents **database data**, we use a
> **list** or other inline sequence. E.g. in_():
>
> column.in_([1, 2, 3])
>
> 2. if the sequence of items represents **SQL structure**, we use a
> variable length *Args. E.g. Table:
>
> Table(name, metadata, *cols_and_other_constraints)
>
> and_(), or(), etc:
>
> and_(*sequence_of_expressions(
>
> ORM query:
>
> session.query(*sequence_of_entities_expressions_etc)
>
> select() should work the same as all these other APIs and in particular
> it's now largely cross-compatible with ORM query as well.
>
> The reason select() has always accepted a a list is because the very
> ancient and long de-emphasized API for select() looked like this:
>
> stmt= select({table.c.col1, table.c.ol2], table.c.col1 ==
> "some_expression", order_by=table.c.col1)
>
> that is, the "generative" API for select() that is very normal now did not
> exist. There was no select().where().order_by(), that was all added years
> after SQLAlchemy's first releases. All of those kwargs are also
> deprecated as they are very ancient legacy code and we'd like SQLAlchemy's
> API to be clean and consistent and not allowing of many variations of the
> same thing, as this makes the whole system easier to use and understand.
>
> So the use of a list in select() is based on long ago deemphasized API
> that SQLAlchemy 2.0 seeks to finally remove. As this API is one of the
> most complicated to provide a backwards-compatibility path for, it's taken
> a very long time for us to get there. But here we are.
>
>
>
>
> On Thu, May 13, 2021, at 2:10 AM, mkmo...@gmail.com wrote:
>
> Hello,
>
> I am on Sqlalchemy 1.2 and looking to upgrade to 1.4.
>
> I have a lot of Core code that looks like this:
>
> # returns an array of columns
> select_fields = make_select_fields(...)
> sel = select(select_fields)
>
> Passing an array to select is now deprecated, so I'm planning on changing
> all my code to:
>
> sel = select(*select_fields)
>
> I was curious to know what the rationale for the change in this API is.
>
> Thanks and best regards,
>
> Matthew
>
>
> --
> SQLAlchemy -
> The Python SQL Toolkit and Object Relational Mapper
>
> http://www.sqlalchemy.org/
>
> To post example code, please provide an MCVE: Minimal, Complete, and
> Verifiable Example. See http://stackoverflow.com/help/mcve for a full
> description.
> ---
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sqlalchemy+...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/sqlalchemy/c0de313c-a113-4e8f-9ae4-f30be96a8c9dn%40googlegroups.com
>
> <https://groups.google.com/d/msgid/sqlalchemy/c0de313c-a113-4e8f-9ae4-f30be96a8c9dn%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
>
>
>
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sqlalchemy/d6216602-9827-432d-bac1-94f7290d3992n%40googlegroups.com.
