Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 09:41
    gboor labeled #6652
  • 09:41
    gboor opened #6652
  • Jun 17 18:53
    CaselIT review_requested #6624
  • Jun 17 18:51

    CaselIT on master

    Fix typos in "Working with Rela… (compare)

  • Jun 17 18:51
    CaselIT closed #6651
  • Jun 17 15:41
    CaselIT assigned #5557
  • Jun 17 12:28
    zzzeek milestoned #6649
  • Jun 17 12:26
    zzzeek edited #6649
  • Jun 17 12:26
    zzzeek labeled #6649
  • Jun 17 12:26
    zzzeek labeled #6649
  • Jun 17 12:26
    zzzeek labeled #6649
  • Jun 17 12:26
    zzzeek labeled #6649
  • Jun 17 12:26
    zzzeek unlabeled #6649
  • Jun 17 08:04
    Syriiin edited #6651
  • Jun 17 08:02
    Syriiin edited #6651
  • Jun 17 08:01
    Syriiin synchronize #6651
  • Jun 17 07:57
    Syriiin opened #6651
  • Jun 17 02:28
    MajorDallas edited #6649
  • Jun 17 02:26
    MajorDallas edited #6649
  • Jun 17 02:24
    MajorDallas opened #6650
Bryan Forbes
@bryanforbes
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'))
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
Bryan Forbes
@bryanforbes
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
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!