Yeah, that makes a lot of sense to me. (I suppose we could promote both of them to complexes as well.)
On Fri, Jun 28, 2024 at 8:36 AM Joey Tran <joey.t...@schrodinger.com> wrote: > > Hey all, > > We're running into a fairly common situation where we get a TypeCheckError > when we supply an int value where a float parameter is expected. > > It's easy enough to work around this on a case-by-case basis by just casting > ints to floats, but this is an easy thing to forget to do, which means it's > likely to result in bugs. > > The function that does the type checking `is_consistent_with`[1] cites that > it's based on definitions from PEP 484. PEP 484 states: [2] > > > Rather than requiring that users write import numbers and then use > > numbers.Float etc., this PEP > > proposes a straightforward shortcut that is almost as effective: when an > > argument is annotated > > as having type float, an argument of type int is acceptable; > > Based on this, would it be reasonable to special-case type checks when > checking int against the float type? > > Best, > Joey > > > [1] > https://github.com/apache/beam/blob/3588d195335fa3dc06b002e5e468baa27e79f8fa/sdks/python/apache_beam/typehints/typehints.py#L1296 > [2] https://peps.python.org/pep-0484/#the-numeric-tower
