Python types have an expectations problem

Post by sco1 » Mon, Jan 29, 2024, 5:21 PM UTC

tyingq wrote: post #39

sco1 wrote: post #10

Earlier quoted context omitted.

For context, if others aren't familiar: type hinting generics were added to Python 3.9 by PEP 585 (also available in Python 3.7+ with the annotations future import). PEP 484 previously added type hints to Python 3.5 as explicit imports from the stdlib's typing module. https://peps.python.org/pep-0585/ https://peps.python.org/pep-0484/

Note that the annotations import from future doesn't help with this one. https://bugs.python.org/issue45117

Post by zokier » Mon, Jan 29, 2024, 5:26 PM UTC

Malcolmlisk wrote: post #22

mg wrote: post #16

I don't really like types on the function declaration line. Instead of this: def check_permission(user: User, perm: str, obj: BaseModel | None) -> bool: I find it much nicer to read something this: """ Check if user is allowed to drive a car :user: User # The application's User model :perm: str # Our magic permission string. Tab seperated. :obj : Basemodel | None # Base model of all our objects since 2017 :returns bo…

You can do that as a docstring inside the function. There are even some basic rules like... def extract_coordiates( unreseted_idx_from_df, json_data: dict, notna_idxs: list, na_idxs: list ) -> list: """ Extracting coordinates from the json_data['data'] and returning the 4 positions of those as an array Parameters ---------- json_data: json Data extracted from tabula.read_pdf and using output_format='json' notna_idxs:…

Post by olejorgenb » Mon, Jan 29, 2024, 5:27 PM UTC

hermitdev wrote: post #17

posix_monad wrote: post #11

In Python it's common to have functions whose return types depend on the run-time arguments. For example: def fooify(x): if isinstance(x, list): map(fooify, x) else: x * 2 I guess this is to make scripting more forgiving. In typical typed languages, you would have two functions instead: fooify : number -> number fooifyMany : [number] -> [number] But in the Python community, it's common to have a big function with man…

In practice, this would be solved with `typing.overload`[0]. Using you example: from typing import overload @overload def fooify(x: int) -> int: ... @overload def fooify(x: list[int]) -> list[int]: ... def fooify(x: list[int] | int) -> list[int] | int: if isinstance(x, list): return [fooify(_x) for _x in x] return x * 2 [0] https://docs.python.org/3/library/typing.html#overload

    T = TypeVar("T", bound=int | list[int])

    def(x: T) -> T:

Post by pphysch » Mon, Jan 29, 2024, 5:34 PM UTC

miohtama wrote: post #5

teddyh wrote: post #3

Summarizing quote: “ Python type hints are a core part of the language, they even have standard library modules (typing), and yet they don’t do anything when used in that language without some external tooling. That, to me, is a bit of an expectations mismatch. ” I.e. they’re complaining that a type checker like mypy isn’t run by default.

It's also good to note that all popular editors and IDEs like Visual Studio Code and PyCharm support type hints quite well by default. Some external tooling needed, but it's your editor and you are going to have any case.

Post by sevensor » Mon, Jan 29, 2024, 5:43 PM UTC

ehutch79 wrote: post #6

A note; typescript does nothing to ensure types are correct at runtime. Especially in the browser. You need to do runtime checking even if you're using typescript. In Python, yeah, they're called Type _Hints_ for a reason. Don't count on them at runtime here either. Both are dynamic languages, it's hard doing anything meta/schema driven with rigid types. If you really want a hard type system, just move to GO or Rust…