Rationale for why 1.4 Core `select` argument as list is deprecated?

[mkmo...@gmail.com]

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

[Mike Bayer]

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.

--

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.

[mkmo...@gmail.com]

Hi Mike.

Thanks, it makes sense. On another topic, the docs say:

    However, version 2.0 hopes to start embracing PEP 484 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

[Mike Bayer]

Python is going towards using typing, period.   Any widely used library has to support this fully to remain relevant, so even if we didn't like typing, we still have to support it :) .     It has no impact on you as a user of the library, you can ignore typing completely and there's no issue with that.

To view this discussion on the web visit https://groups.google.com/d/msgid/sqlalchemy/d6216602-9827-432d-bac1-94f7290d3992n%40googlegroups.com.

[mkmo...@gmail.com]

Hi Mike, would you mind elaborating on why a library needs to support typing to remain relevant? For example, does it have some potential impact on downstream users of a library who want to take advantage of typing?

I have a (very small) library, and is completely untyped. I don't really like typing but want to keep an open mind.

Thanks and best regards,

Matthew