A blog post on choosing more specific types rather than general ones like list and dict.

  • qwertyasdef@programming.dev
    link
    fedilink
    arrow-up
    8
    ·
    9 months ago

    If you don’t need to reuse the collection or access its items out of order, you can also use Iterable which accepts even more inputs like generators.

  • o11c@programming.dev
    link
    fedilink
    arrow-up
    5
    ·
    9 months ago

    The problem is that there’s a severe hole in the ABCs: there is no distinction between “container whose elements are mutable” and “container whose elements and size are mutable”.

    (related, there’s no distinction for supporting slice operations or not, e.g. deque)

    • MeadSteveOP
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

      Yeah there’s definitely a lot of room for improvement here

  • jadelord@discuss.tchncs.de
    link
    fedilink
    arrow-up
    4
    ·
    9 months ago

    Good point, and Łukasz Langa mentioned this in his talk (check it out). He names it the robustness principle, in his words (around 22:20 mark:

    “Vague in what you accept, concrete in what you return”

    But he also mentions some gotchas like how Iterable[str] can backfire, because str is also an Iterable[str] and it might be better to use list[str].

  • chemacortes@programming.dev
    link
    fedilink
    English
    arrow-up
    3
    ·
    9 months ago

    Sequence now lives at collections.abc. BTW, float is not a supertype of int (issubclass(int, float) == False). Normaly, It is acceptable to use int instead of float, but speaking of variance, it is more precise to use numbers.Real:

    issubclass(Integral, Real) == True
    issubclass(int, Real) == True
    issubclass(float, Real) == True
    issubclass(complex, Real) == False
    
  • coffeewithalex@lemmy.world
    link
    fedilink
    arrow-up
    3
    ·
    9 months ago

    The important difference is that you don’t need to import anything in order to quickly use list type. This wins in the majority of the cases, unless I’m building something that will be imported by multiple other modules and it really pays to be that explicit.

    • MeadSteveOP
      link
      fedilink
      arrow-up
      2
      ·
      9 months ago

      That was definitely a nice feature (I forget exactly when list over List was added). That said I’ve never really been bothered about having imports. Especially when I know the import is side effect free like the typing module. But I definitely use import free list for script files without many lines of code.