6. all the ORM declarative elements should be able to pull their info from __annotations__, if arguments are not present. this shouldn't be that hard to accomplish. Yes it means I'd like a lookup of Mapped[int] -> Column(Integer), stuff like that. Big deal.

not sure if I like this idea, I would need to think a bit abut it.
Maybe we can require a lockup dict to be passed in the registry? something like {int: Integer} or {int: lambda: Integer(some_option=True)? We may also opt to provide a default one?

for relationships, we usually will need the left-annotation to be the explicit part:

user: Mapped["User"] = relationship()

This is because we can't annotate relationship to produce the correct type in the other direction, when the class argument is a string:

# can't type this as Mapped[User] without explicit type
user = relationship("User")

So i was thinking of being consistent, or at least allowing consistency, to have the mapping start up from the "x: Mapped[y]" side.

for the type lookup, we already have this mapping right here: https://github.com/sqlalchemy/sqlalchemy/blob/main/lib/sqlalchemy/sql/sqltypes.py#L2998 we already do this, nobody needs to override it or anything. if you have a specific type you want to use with mapped[int] then you specify it in the mapped_column(), no differently than people do now anyway with "cast()" or whatever.

there's the general problem of str->Unicode for databases with explicit unicode datatypes and data conversion issues like pyodbc. so we might need to improve that part.

i'd propose a subclass of str: class plain_str(str): or something like that

I think it would be useful to provide an override at the registry level. Like for pg I would like to map str to Text, not varchar and float to double_precision. Also maybe folks like to map int to biging

The mapping we have is also not really complete since it's not dialect specific, like uuid is missing.

Also I'm not sure if we can support also list->array and extract the type from a list annotation to do list[str] -> Array(Text)

UUID is just going to be missing, this would be a very basic typing-saver only.

re: override registry it can be something local to the registry() object, not a global.

well then if there's a registry override there's where you put your UUID :)

things like Array are also very unusual edge cases

override registry it can be something local to the registry() object, not a global.

sure, that was my suggestion, since that's for declarative one we do have a registry always available, so it should not be that much of an issue to support. we can have a constructor argument called type_map and a property that returns a immutable dict with the current map

well then if there's a registry override there's where you put your UUID :)

indeed, it would be there

Mike Bayer referenced this issue:

WIP for ORM typing https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3495

I think this pep would be very useful to specify a particular sqlalchemy type for a column https://www.python.org/dev/peps/pep-0593/

We could have something like

class Foo:
  foo: int
  bar: Annotated[str, String(42)]

This would also solve the type map issue we talked above ( or could be used as an alternative / in conjunction with it )

possibly. it looks like "yet another syntax" so far, as opposed to "bar: mapped_column(String(42))" but something to consider

Maybe it could be in place of other syntaxes? This seems the official python way of doing what this kind of things.

the Column construct accepts a dozen different kinds of parameters and arguments. Where do things like ForeignKey(), "key", "name" etc. get specified if Annotated[str, String] takes the place of Column /mapped_column? also it feels redundant to have to type things like Annotated[str, TEXT] - mapped_column(TEXT) is more succinct. there is more variability in a single Python type to multiple database types, than the other way around (the use case for the "type map", which would be much less prominent since it is usually not needed).

that is, I think the canonical way to map declaratively is going to stay mostly like it is:

class User(Base):
    __tablename__ = 'user'

   id = mapped_column(Integer, primary_key=True)
   name = mapped_column(String, nullable=False)
   some_date = mapped_column(DateTime)
   addresses = relationship(lambda: Address, back_populates="user", uselist=True)

the above is what people are used to, it's extremely close to what's documented everywhere and we can derive all the typings above without any annotations. obviously relationship() will usually not be able to use lambda like that so still some exception there.

Ok so I remembered that we wanted to allow mapping without specifying mapped_column / relationship.

Where do things like ForeignKey(), "key", "name" etc. get specified if Annotated[str, String]

I think annotated allows any type after the first one (and also allows multiple arguments) so I guess Annotated[str, Column(...)] would be an option.

Probably just something to take into consideration if we want to experiment

obviously relationship() will usually not be able to use lambda like that so still some exception there.

I just though of this, and most likely the type checker do not like it but we could make relationship a generic class and use __new__ to return instances of RelationshipProperty.
Is something like this allowed?

_T = TypeVar('_T')
class relationship(Generic[_T]):
  @overload
  def __new__(self, thing, uselist=False, ....) -> _T

  @overload
  def __new__(self, thing, uselist=True, ....) -> List[_T]

  def __new__(self, thing, ...) -> _T
    ...
    return RelationshipProperty(...)

so that we could use it as

if TYPE_CHECKING:
  from .other import Address

class User(Base):
    __tablename__ = 'user'

   id = mapped_column(Integer, primary_key=True)
   name = mapped_column(String, nullable=False)
   some_date = mapped_column(DateTime)
   addresses = relationship['Address']('Address', back_populates="user", uselist=True)

Mike Bayer referenced this issue:

establish mypy / typing approach for v2.0 https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3562

Mike Bayer has proposed a fix for this issue in the main branch:

establish mypy / typing approach for v2.0 https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/3562

docs for all this stuff are going to be a separate commit. typing affects a lot of things so this commit is just grouping all of it together towards the goal of expediency.