Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 05:09
    CaselIT milestoned #6841
  • 05:09
    CaselIT unlabeled #6841
  • 05:09
    CaselIT labeled #6841
  • 05:09
    CaselIT labeled #6841
  • 04:30
    imoyao labeled #6841
  • 04:30
    imoyao opened #6841
  • Jul 31 22:35
    zzzeek review_requested #881
  • Jul 31 20:34
    whiskeyriver edited #6839
  • Jul 31 20:34
    whiskeyriver edited #6839
  • Jul 31 20:33
    whiskeyriver edited #6839
  • Jul 31 20:33
    whiskeyriver edited #6839
  • Jul 31 20:32
    whiskeyriver opened #6839
  • Jul 31 20:32
    whiskeyriver labeled #6839
  • Jul 31 13:24
    cansjt opened #881
  • Jul 31 12:57
    zzzeek assigned #207
  • Jul 31 06:51
    Milittle edited #207
  • Jul 31 06:51
    Milittle edited #207
  • Jul 31 02:42
    Milittle opened #207
  • Jul 30 18:00
    Morikko synchronize #6709
  • Jul 30 15:02
    nakutnyi opened #880
Bryan Forbes
@bryanforbes
you can do this in 3.9:
from __future__ import annotations

def foo(bar: str | int) -> None:
because annotations aren’t evaluated
Federico Caselli
@CaselIT
do the typing need to be compatible with the py version you target?
Bryan Forbes
@bryanforbes
I forget
let me check
Federico Caselli
@CaselIT
iirc annotation will be always evaluated until 4
Alex Grönholm
@agronholm
no, in 3.10 they're not evaluated
Federico Caselli
@CaselIT
that is also a stupid thing to do by default... they should have made then lazy by default
Bryan Forbes
@bryanforbes
I thought they were going to default to not evaluating in 3.10
Federico Caselli
@CaselIT

no, in 3.10 they're not evaluated

thanks! so there is no longer need to use str for forward refs?

Alex Grönholm
@agronholm
correct
Federico Caselli
@CaselIT
just 5 releases too late I guess
Bryan Forbes
@bryanforbes
X | Y is supported in stubs
we can do a mass change at a later time
there’s another change I’d like to see: removing = … from module-level and class-level variables
@CaselIT I think the docs are wrong for DDLElement.dialect
execute_if(dialect=) says this:
        :param dialect: May be a string, tuple or a callable
          predicate.  If a string, it will be compared to the name of the
          executing database dialect::

            DDL('something').execute_if(dialect='postgresql')

          If a tuple, specifies multiple dialect names::

            DDL('something').execute_if(dialect=('postgresql', 'mysql'))
Bryan Forbes
@bryanforbes
however, _should_execute does this:
    def _should_execute(self, target, bind, **kw):
        if isinstance(self.dialect, util.string_types):
            if self.dialect != bind.engine.name:
                return False
        elif isinstance(self.dialect, (tuple, list, set)):
            if bind.engine.name not in self.dialect:
                return False
        if self.callable_ is not None and not self.callable_(
            self, target, bind, state=self.state, **kw
        ):
            return False

        return True
so dialect is never used as a callable
Federico Caselli
@CaselIT
indeed.
lest's fix it
Bryan Forbes
@bryanforbes
(which is why I didn’t annotate it that way)
Federico Caselli
@CaselIT
i read the docs. see what's happens
Bryan Forbes
@bryanforbes
:D
Federico Caselli
@CaselIT
fixed
Bryan Forbes
@bryanforbes
@CaselIT I pushed a commit to address your feedback
Federico Caselli
@CaselIT
@zzzeek I've taken another look at the event stuff and ... it's really quite hard to change
I've an idea, but I'll probably need some feedback if that's something useful
Federico Caselli
@CaselIT

@bryanforbes there seems to be a wheel "name" for arm macos. universal2. See https://pypi.org/project/orjson/#files that publishes them

no clue how to create them though. that project uses rust that I think can cross-compile on different architectures

Bryan Forbes
@bryanforbes
@zzzeek as soon as that public API branch in gerrit gets merged, I’m going to start submitting strict mode fixes for the plugin
then I’ll start on a refactor
Maico Timmerman
@MaicoTimmerman
@bryanforbes Did you see my other question as well? https://github.com/sqlalchemy/sqlalchemy2-stubs/pull/59/files#r611092432 Then I can update the PR in a single go
Bryan Forbes
@bryanforbes
oh, I did, and I meant to check that
@MaicoTimmerman what do you think about adding our own _SupportsIndex into util/compat.pyi?
it’s a simple protocol
Maico Timmerman
@MaicoTimmerman
That should work
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