class Connection:
    def scalar(self, statement: ScalarSelect[_TE[_T]]) -> _T:

import typing
from typing import Protocol, cast, overload
from typing import Generic, Any, List
from typing import Tuple
from typing import TypeVar

# represents Python data values.  int, str, etc.
_T = TypeVar("_T", bound=Any)



class TypeEngine(Generic[_T]):
    """describe a SQL datatype.

    the _T here will point to a Python datatype.

    """

class String(TypeEngine[str]):
    """describe a string SQL datatype.

    Python datatype here is str.

    """


class Integer(TypeEngine[int]):
    """describe an integer SQL datatype.

    Python datatype here is int.

    """

class JSON(TypeEngine[Any]):
    """describe a JSON SQL datatype.

    Since JSON can return scalar values and there can be a JSON decoder
    in place, JSON's python datatype can't be realistically constrained.


    """

class ARRAY(TypeEngine[List[_T]]):
    """describe an ARRAY SQL datatype.

    Here we have a bigger problem which is that ARRAY has another
    TypeEngine inside of it.

    """

"""so far ao good!  here's where it goes wrong.
"""




_TE = TypeVar("_TE", bound="TypeEngine")



class ColumnExpression(Generic[_TE]):
    """describe a SQL column expression.

    a SQL column expression represents some kind of SQL and a SQL
    datatype that's returned.   So where we have the first syntactical
    challenge is that when we want to get the Python datatype from
    a ColumnExpression.  So that's like ``ColumnExpression[_TE[_T]]`` if
    we want to extract that.

    Which, I believe we cannot!  Which means the whole way I did
    sqlalchemy2-stubs with ColumnExpression[TypeEngine] is wrong, and
    what sqlalchemy-stubs did was correct in this regard.

    However!  There are also behaviors that are implied by _TE here, like
    if I say column('q') + column('y'), the "+" operator is different if
    TE is String or Integer.  there are also JSON / ARRAY index operators
    that have different behavior on ColumnExpression.

    """
    def __init__(self, name: str, type_: _TE):
        self.name = name
        self.type_ = type_

    # add operator.  in these cases, the type coming in is preserved
    # for both integer addition and string concatenation, so we don't
    # actually need to know about String / Integer.  OK
    @overload
    def __add__(self, other: "ColumnExpression[String]") -> "ColumnExpression[String]":
        ...

    @overload
    def __add__(self, other: "ColumnExpression[Integer]") -> "ColumnExpression[Integer]":
        ...

    # here, we know how to type __getitem__ because the ColumnExpression has
    # the ARRAY datatype inside of it.  can we distinguish against JSON /
    # HSTORE?
    #
    # a: yes, because List[_T].__getitem__[int] is always going to return
    # a _T, whether it's JSON or ARRAY,  Mapping[str, T].__getitem__[str]
    # will always return _T, etc.

    @overload
    def __getitem__(self: "ColumnExpression[ARRAY[List[_TE]]]", index: int) -> "ColumnExpression[_TE]":
        ...




class ScalarSelect(Generic[_TE]):
    """scalar select statement.  has one column.

    here we illustrate it typed to the column's TypeEngine.

    """

    def __init__(self, column: ColumnExpression[_TE]):
        self.column = column


"""here's where the whole thing breaks!   time to run the statement and get
Python values.

Here we illustrate a scalar column / scalar python value.  This same process
applies to pep-646 where we have Result/Row with TypeVarTuple, same problem
is there as well, this is just simpler to illustrate.

"""
class Connection:
    def scalar(self, statement: ScalarSelect[_TE[_T]]) -> _T:
        """this can't be done!  we have ScalarSelect[_TE] and we need to
        unwrap the _T from it.  not supported.   this is game over
        for how I did sqlalchemy2-stubs - you can't resolve two levels of
        TypeVar.

        same issue happens in the pep-646 case.

        """
        ...


    """pep 646 methods look like these below.  again, we can't go from

    Select[Integer, String] to Row[int, str].  it's not possible AFAICT,
    but not for any reason beyond that we can't do it with scalar values
    either

    """

    # def execute(self, statement: Select[Unpack[ColumnTypeTuple]]) -> Result[PythonTypeTuple]:
    #     ...

    # def first(self, statement: Select[Unpack[ColumnTypeTuple]]) -> Row[PythonTypeTuple]:
    #     ...

if __name__ == '__main__':
    # (variable) c1: ColumnExpression[String] - I like how this looks
    c1 = ColumnExpression("c1", String())

    # (variable) stmt: ScalarSelect[String] - I also like
    stmt = ScalarSelect(c1)

    conn = Connection()

    # (variable) value: _T@scalar - this part is impossible, so non-starter
    value = conn.scalar(stmt)

import typing
from typing import Protocol, cast, overload
from typing import Generic, Any, List
from typing import Tuple
from typing import TypeVar

# represents Python data values.  int, str, etc.
_T = TypeVar("_T", bound=Any)



class TypeEngine(Generic[_T]):
    """describe a SQL datatype.

    the _T here will point to a Python datatype.

    """

class String(TypeEngine[str]):
    """describe a string SQL datatype.

    Python datatype here is str.

    """


class Integer(TypeEngine[int]):
    """describe an integer SQL datatype.

    Python datatype here is int.

    """

class JSON(TypeEngine[Any]):
    """describe a JSON SQL datatype.

    Since JSON can return scalar values and there can be a JSON decoder
    in place, JSON's python datatype can't be realistically constrained.


    """

class ARRAY(TypeEngine[List[_T]]):
    """describe an ARRAY SQL datatype.

    Here we have a bigger problem which is that ARRAY has another
    TypeEngine inside of it.

    """

"""so far ao good!  here's where it goes wrong.
"""




class ColumnExpression(Generic[_T]):
    """describe a SQL column expression.

    a SQL column expression represents some kind of SQL and a SQL
    datatype that's returned.

    Here, we do what sqlalchemy-stubs does, and BTW also our own
    Mapping[_T] in the ORM anyway, and just put the Python type there.

    We always can get that Python type because we are handed TypeEngine
    objects that give it to us.  It feels "weird" to have
    ``Column[int]`` to me, because we are losing the "Integer"- ness of it,
    and particularly I think ``Column[JSON]``, ``Column[ARRAY[Integer]]```
    is way more descriptive than ``Column[Any]``, ``Column[List[int]]``.

    The Column object etc. is descriptive of a SQL / schema construct on the
    database.  There is no Python type intrinsic to that, so it feels wrong
    to have things like ``Column[int]``, you might just be running CREATE
    TABLE and your program has nothing to do with ints or anything.  But
    as I've said myself in my own docs, pep-484 typing is about python
    types, not database types, hence when i have "nullable=False" I still
    have Mapping[] assuming Optional because in Python-land the attribute can
    still be None (we probably should change that too
    because it just annoys people).

    from the spec: https://www.python.org/dev/peps/pep-0484/#generics
    "Since type information about objects kept in containers cannot be
    statically inferred in a generic way, abstract base classes have been
    extended to support subscription to denote expected types for
    container elements. "  - the ColumnElement contains a TypeEngine, not
    a str or int.  It *indirectly* refers to those things.   This is where
    I can't get my head around this feeling correct.

    then again the whole way SQLAlchemy works is based on a fairly meta
    concept.



    """
    def __init__(self, name: str, type_: TypeEngine[_T]):
        self.name = name
        self.type_ = type_

    # add operator.  in these cases, the type coming in is preserved
    # for both integer addition and string concatenation, so we don't
    # actually need to know about String / Integer.  OK
    @overload
    def __add__(self, other: "ColumnExpression[str]") -> "ColumnExpression[str]":
        ...

    @overload
    def __add__(self, other: "ColumnExpression[int]") -> "ColumnExpression[int]":
        ...

    # this is OK
    @overload
    def __getitem__(self: "ColumnExpression[List[_T]]", index: int) -> "ColumnExpression[_T]":
        ...




class ScalarSelect(Generic[_T]):
    """scalar select statement.  has one column.

    here we illustrate it typed to the column's TypeEngine.

    """

    def __init__(self, column: ColumnExpression[_T]):
        self.column = column


"""
this all works now

"""
class Connection:
    def scalar(self, statement: ScalarSelect[_T]) -> _T:
        """no problem

        """
        ...


    """pep 646 methods look like these below, these are fine because we just
    have TypeTuple that's a tuple of Python types, and that's it.

    """

    # def execute(self, statement: Select[Unpack[TypeTuple]]) -> Result[TypeTuple]:
    #     ...

    # def first(self, statement: Select[Unpack[TypeTuple]]) -> Row[TypeTuple]:
    #     ...

if __name__ == '__main__':
    # (variable) c1: ColumnExpression[str]  - ugly
    c1 = ColumnExpression("c1", String())


    # (variable) stmt: ScalarSelect[str]  - ugly
    stmt = ScalarSelect(c1)

    conn = Connection()

    # value is a str, what we want
    value = conn.scalar(stmt)

class ColumnExpression(Generic[_TE, _T]):
    """describe a SQL column expression.

    Here's another way.  Put *both* types in the generic.


    """

    def __init__(self, name: str, type_: _TE[_T]):
        """doesn't work.  I can't get _T out of _TE here, same reasons
        as before."""
        self.name = name
        self.type_ = type_