sqlalchemy/devel

SQLAlchemy weekly dev meetings: https://docs.google.com/document/d/1WuzZwV_aIV_ltDR3cJ-bXxXMZ9zCfr5pFSXZGZOSSQw/edit?usp=sharing

Bryan Forbes

@bryanforbes

also, for the record, I was looking at an older typeshed (that comes with mypy 0.812) when I made my original comment:

    @overload
    def __setitem__(self, i: int, o: _T) -> None: ...
    @overload
    def __setitem__(self, s: slice, o: Iterable[_T]) -> None: ...

Maico Timmerman

@MaicoTimmerman

Maybe we should try and see if there is a way to validate ourselves that inherited types like those stay up-to-date?

Although I'm not sure how to go about that

I'd see these updates happening in the future, without us knowing pro-actively

Bryan Forbes

@bryanforbes

there’s going to have to be a compat layer once things like List are removed from typing, too

Bryan Forbes

@bryanforbes

Maybe we should try and see if there is a way to validate ourselves that inherited types like those stay up-to-date?

We just have to be proactive when releases happen

Maico Timmerman

@MaicoTimmerman

@bryanforbes I ran into this within mypy: https://github.com/python/mypy/blob/master/mypy/stubtest.py

Bryan Forbes

@bryanforbes

yeah, I use it quite often

Maico Timmerman

@MaicoTimmerman

Ah nice

Bryan Forbes

@bryanforbes

@MaicoTimmerman one last thing

Maico Timmerman

@MaicoTimmerman

I was checking this import, but I just realised. I just added types to these functions, but wouldn't simply omitting them be better?

Then they would simply inherit from typing.List

Bryan Forbes

@bryanforbes

yeah, that may be best

Federico Caselli

@CaselIT

@bryanforbes reviewed some pr in the stubs

Bryan Forbes

@bryanforbes

:+1:

Federico Caselli

@CaselIT

@zzzeek do you have moment?

mike bayer

@zzzeek

hi

Federico Caselli

@CaselIT

hey mike

how are things?

mike bayer

@zzzeek

hey

little unhealthy this spring but working it out

Federico Caselli

@CaselIT

bummer, hopefully nothing too serious.

mike bayer

@zzzeek

might have to have my thyroid out

Bryan Forbes

@bryanforbes

@CaselIT I think I’m gonna hold off on the copied properties going into their own protocol

mike bayer

@zzzeek

i can still answer questions though!

Bryan Forbes

@bryanforbes

we can do that in the future, though

Federico Caselli

@CaselIT

@CaselIT I think I’m gonna hold off on the copied properties going into their own protocol

ok then

i can still answer questions though!

sorry, was repling to a pr

I was trying to came up with a solution for https://gerrit.sqlalchemy.org/c/sqlalchemy/sqlalchemy/+/2629
basically I would like to avoid leaving all the only_once callbacks there

mike bayer

@zzzeek

yeah i had not been able to figure out a way to do that

Federico Caselli

@CaselIT

but I'm not sure how the best way would be for it. My idea was to make it return something that identifies the fact that's a once, since is is cheap and should not cause too much overhead

that part is really hard to follow btw. I'm still not sure what half of the stuff does

mike bayer

@zzzeek

yah me neithr :)

Federico Caselli

@CaselIT

do you think the return thing would work?

mike bayer

@zzzeek

im not really sure i hitnk overall some system outside of the event.call() has to know to remove it

Federico Caselli

@CaselIT

yes. the next step was to recreate the event key from the callback

so I can call remove on it

not figured out that part yet

also is only_once public or can I move it around?

mike bayer

@zzzeek

yeah i would ahve to dig into that code again and im a little too headachy today

the...keyword arugment to event.listen() ? i think it's public but nobody uses it

Federico Caselli

@CaselIT

no the wrapper thing in utils

mike bayer

@zzzeek

oh, that's whatever

Federico Caselli

@CaselIT

ok.

I think I'll start by passing the stuff to create the event key when creating the wrapper, just to see what breaks with that change. when in review you can point to better alternative

mike bayer

@zzzeek

ok

Federico Caselli

@CaselIT

thanks

@bryanforbes are you working on sqlalchemy/sqlalchemy2-stubs#51 ? If not I think it can be merged and anything that I mentioned could be done in a later pr

Bryan Forbes

@bryanforbes

yeah, I’ll take care of it

Federico Caselli

@CaselIT

ok