[lolinder]

> It feels like a bunch of rigmarole for no benefit. I don’t use an IDE, so code completion or whatever you get for it doesn’t apply to me.

Maybe try using an IDE? Without one any language's type system will feel more frustrating than it's worth, since you won't get inline error messages either.

> Even strongly typed languages like rust have ergonomics to help you avoid explicitly specifying types like let x = 1.

This is called type inference, and as far as I can tell this level of basic type inference is supported by the major python type checkers. If you're seeing people explicitly annotate types on local variables that's a cultural problem with people who are unaccustomed to using types.

As for that function signature, it would be bonkers with or without types. The types themselves look pretty straightforward, the problem is just that they formatted it all on one line and have a ridiculous number of keyword arguments.

[eloisius]

Of course I’ve used an IDE before. I still prefer Vim to an IDE. And I enjoy writing typed languages in Vim because the compiler catches mistakes.

I agree part of the problem is cultural. Maybe a bunch of Python coders are eager to use types, or maybe linters are pushing them to type every last variable because that is “right.” I don’t know.

I don’t hate typed languages at all. In fact I love writing Rust. Even C++ is tolerable from a type perspective. I don’t agree that _RelationshipJoinConditionArgument is a meaningful type. It feels like bolting a type system onto the language after the fact is weird and necessitates crazy types like that to make some linter happy, maybe to make VS Code users happy, at the expense of readability.

[btreecat]

Vim is an IDE, with more steps. Nothing stopping you from having code completion setup in vim and benefiting from the additional meta info.

[int_19h]

https://github.com/puremourning/vimspector will also give you a Python debugger with breakpoints etc (same one as in VSCode, in fact).

[gopher_space]

Neovim is pretty slick.

[robertlagrant]

You can run mypy as the Python equivalent of the typey bit of a compiler.

As for SQLAlchemy, I wouldn't assume that the object model would be particularly different in any other OO language for the problem it's solving.

[joshuamorton]

> _RelationshipJoinConditionArgument

Is it particularly different from Rust's unusual types like `Map<Chain<FromRef<Box dyn Vec<Foo>>>>>` that you can get when doing chained operations on iterators?

Protocol/Trait based typing necessitates weird names for in-practice traits/protocols that are used.

Edit: IDK why that function signature is that ridiculous, reformatting it as:

    sqlalchemy.orm.relationship(
        argument: _RelationshipArgumentType[Any] | None = None, 
        secondary: _RelationshipSecondaryArgument | None = None, 
        *, 
        uselist: bool | None = None, 
        collection_class: Type[Collection[Any]] | Callable[[], Collection[Any]] | None = None, 
        primaryjoin: _RelationshipJoinConditionArgument | None = None, 
        secondaryjoin: _RelationshipJoinConditionArgument | None = None, 
        back_populates: str | None = None, 
        order_by: _ORMOrderByArgument = False, 
        backref: ORMBackrefArgument | None = None, 
        overlaps: str | None = None, 
        post_update: bool = False, 
        cascade: str = 'save-update, merge', 
        viewonly: bool = False, 
        init: _NoArg | bool = _NoArg.NO_ARG, 
        repr: _NoArg | bool = _NoArg.NO_ARG, 
        default: _NoArg | _T = _NoArg.NO_ARG, 
        default_factory: _NoArg | Callable[[], _T] = _NoArg.NO_ARG, 
        compare: _NoArg | bool = _NoArg.NO_ARG, 
        kw_only: _NoArg | bool = _NoArg.NO_ARG, 
        lazy: _LazyLoadArgumentType = 'select', 
        passive_deletes: Literal['all'] | bool = False, 
        passive_updates: bool = True, 
        active_history: bool = False, 
        enable_typechecks: bool = True,
        foreign_keys: _ORMColCollectionArgument | None = None, 
        remote_side: _ORMColCollectionArgument | None = None, 
        join_depth: int | None = None, 
        comparator_factory: Type[RelationshipProperty.Comparator[Any]] | None = None, 
        single_parent: bool = False,
        innerjoin: bool = False, 
        distinct_target_key: bool | None = None, 
        load_on_pending: bool = False,
        query_class: Type[Query[Any]] | None = None, 
        info: _InfoType | None = None,
        omit_join: Literal[None, False] = None, 
        sync_backref: bool | None = None, 
        **kw: Any
    ) → Relationship[Any]

It's 2-3 expected arguments and then ~30 options (that are all like Optional[bool] or Optional[str] to customize the relationship factory. Types like `_ORMColCollectionArgument` do stick out, but they're mainly there because these functions accept `Union[str, ResolvedORMType]` and will convert some sql string to a resolved type for you, and like, this is an ORM, there are going to be some weird ORM types.

[eternityforest]

It definitely seems to be a target audience issue. I use VS code and MyPy regularly catches mistakes, some of which would have been fairly subtle.

I have MyPy and Ruff going all the time and generally aim for zero linter errors.

[bas]

Thank you, for putting many of my frustrations to words.

[codethief]

How does Vim prevent you from using a language server?

[whyever]

> Without one any language's type system will feel more frustrating than it's worth, since you won't get inline error messages either.

I disagree, for me the integration with the editor mostly shortens feedback cycles, and enables some more advanced features. The utility of identifying problems without running the code is still there.