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 On Thursday, May 13, 2021 at 8:03:43 AM UTC-7 Mike Bayer wrote: > > 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. > > > On Thu, May 13, 2021, at 9:55 AM, mkmo...@gmail.com wrote: > > 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+...@googlegroups.com. > > To view this discussion on the web visit > https://groups.google.com/d/msgid/sqlalchemy/d6216602-9827-432d-bac1-94f7290d3992n%40googlegroups.com > > <https://groups.google.com/d/msgid/sqlalchemy/d6216602-9827-432d-bac1-94f7290d3992n%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/ac73000f-a9d4-4caa-a827-7a7f4c015805n%40googlegroups.com.
