• bjornsno@lemm.ee
    link
    fedilink
    arrow-up
    70
    arrow-down
    5
    ·
    2 months ago

    I code both typescript and python professionally, and python is almost as much of a mess, just a different kind of mess. The package manager ecosystem is all over the place, nobody is agreeing on a build system, and the type system is still unable to represent fairly simple concepts when it comes to function typing. Also tons of libraries just ignore types altogether. I love it, but as a competitor to JavaScript in the messiness department it’s not a good horse.

      • bjornsno@lemm.ee
        link
        fedilink
        arrow-up
        13
        ·
        2 months ago

        All documentation is optional and ignored at runtime, that doesn’t mean you shouldn’t do it. If your library doesn’t have type hints I’m just not gonna use it, I don’t have the time to figure out what you accept or return.

        • legion02@lemmy.world
          link
          fedilink
          arrow-up
          2
          arrow-down
          4
          ·
          2 months ago

          It means they have the option to do it or not do it and you have the option to not use it, which clearly your exercising. I’ve personally never had a situation where a lack of type hints slowed me down even a little.

          • FizzyOrange
            link
            fedilink
            arrow-up
            6
            ·
            2 months ago

            I dunno if you’re being deliberately obtuse, but just in case you really did miss his point: the fact that type hints are optional (and not especially popular) means many libraries don’t have them. It’s much more painful to use a library without type hints because you lose all of their many benefits.

            This obviously isn’t a problem in languages that require static types (Go, Rust, Java, etc…) and it isn’t a problem with Typescript because static types are far more popular in JavaScript/Typescript land so it’s fairly rare to run into a library that doesn’t have them.

            And yeah you can just not use the library at all but that’s just ignoring the problem.

            • namingthingsiseasy
              link
              fedilink
              arrow-up
              2
              arrow-down
              1
              ·
              2 months ago

              True, but if you’re looking at a Python library that doesn’t have type hints in 2024, then chances are that it’s not very good and/or not very well maintained.

              • FizzyOrange
                link
                fedilink
                arrow-up
                1
                ·
                2 months ago

                Well, indeed. Unfortunately there are still a fair number of them. The situation is definitely improving at least.

      • bjornsno@lemm.ee
        link
        fedilink
        arrow-up
        6
        ·
        2 months ago

        Yeah, they’re useful when developing, which is why it’s so frustrating when libraries don’t implement types. I’m developing and I’m trying to use a tool that supposedly fits a use case I have, but the tool didn’t come with instructions so it’s practically useless to me. I could open the tool up and look at its guts to figure it out but are you kidding me no, I’m not going back to the stone age for your tool.

      • dallen
        link
        fedilink
        arrow-up
        1
        ·
        2 months ago

        Pydantic offers awesome runtime validation (using Rust).

    • jjjalljs@ttrpg.network
      link
      fedilink
      arrow-up
      2
      ·
      2 months ago

      the type system is still unable to represent fairly simple concepts when it comes to function typing

      what do you mean by this?

      • bjornsno@lemm.ee
        link
        fedilink
        arrow-up
        2
        arrow-down
        1
        ·
        2 months ago

        My biggest pet peeve is the complete inability to annotate a set of known exceptions that a function raises in a machine readable way. The discussion about it is quite heated.

        • FizzyOrange
          link
          fedilink
          arrow-up
          4
          ·
          2 months ago

          In fairness that approach hasn’t really worked in other languages. It was so unpopular in C++ that they actually removed the feature, which is almost unheard of. Java supports it too but it’s pretty rarely used in my experience. The only place I’ve seen it used is in Android. It’s unpopular enough there that Kotlin doesn’t support it.

        • jjjalljs@ttrpg.network
          link
          fedilink
          arrow-up
          3
          ·
          2 months ago

          Interesting. I’ve never felt a need for this, and as the other reply here said it was really unpopular in other languages.

          I would have guessed you would have said something about how it’s annoying to type callable arguments, and how Protocol exists but doesn’t seem that widely known.

          • bjornsno@lemm.ee
            link
            fedilink
            arrow-up
            1
            ·
            edit-2
            2 months ago

            Definitely those used to be pain points, but they do exist now so type erasure after decorator application isn’t a problem anymore, which used to be another huge one for me.

            The discussion around how unpopular it was in other languages seems like such an obvious side track to me. Typing in general went out of fashion and then made a comeback when it was opt-in, why wouldn’t the same apply to exceptions? Of course I’m not wanting warnings in every func call because of a potential MemoryCorruptionError, but if a library has some set of known exceptions as a de facto part of its interface then that’s currently completely unknown to me and my static type checker.

            One kinda bad example is playwright. Almost all playwright functions have the chance to raise a TimeoutError, but even if you know this you’ll probably shoot yourself in the foot at least once because it’s not the built-in TimeoutError, oh no, it’s a custom implementation from the library. If you try to simply try...except TimeoutError:, the exception will blow right by you and crash your script, you’ve got to import the correct TimeoutError. If it was properly typed then pyright would be able to warn you that you still need to catch the other kind of TimeoutError. It’s a bad example because like I said almost all playwright functions can raise this error so you’d get a lot of warnings, but it also demonstrates well the hidden interface problem we have right now, and it’s the most recent one that screwed me, so it’s the one I remember off the top of my head.

    • hector@sh.itjust.works
      link
      fedilink
      arrow-up
      1
      ·
      edit-2
      2 months ago

      I’m going to code in Python for my job soon, do you have links on how TF I should manage dependencies? I can’t stand the bloat of virtual environments or Anaconda sorry.

      I need to make myself a stack python but I don’t want to look at this madness. At least Typescript benefits from a high quality ecosystem of frontend tooling with Vite/React/ESLint/ESBuild and it’s getting even better with the new runtimes features :)

      I need to learn about:

      • built-in tools provided by the language (practice on the job and the power of Google & LLMs will help)
      • ecosystem
      • good practices

      Why is their a build system for an interpreted language ? Do you have bundling concerns like in JS or you somehow compile Python code now?

      • bjornsno@lemm.ee
        link
        fedilink
        arrow-up
        3
        ·
        2 months ago

        You need to get over the bloat of virtual environments. It’s the same as node_modules and it’s completely necessary if you want more than a single python project to live on your machine.

        I personally use poetry as my dependency manager and build tool. It’s not perfect but it’s a lot better than pipenv or just rawdogging pip like a maniac. uv is the new hotness, but I haven’t tried it so can’t vouch. People seem to like it though.

        JavaScript is also an interpreted language with tons of build tools. The reason to have one for python is mainly about packaging and code distribution, so same as JavaScript. If you want to distribute a program you probably don’t want to just point people to a GitHub repo, and if you want to publish a package on pypi it needs to be bundled correctly.

        For ecosystem there isn’t much I can do for you, it completely depends on what you’ll be working on. Baseline you want pydantic for parsing objects, assuming some APIs will be involved. You want black for code formatting, flake8 for linting, pytest for testing. If you’re gonna write your own APIs you can’t go wrong with fastapi, which works great with pydantic. For nice console stuff there’s click for building cli apps and rich and textual for console output and live console apps respectively.

        People are actively trying to replace flake8 and black with feature compatible stuff written in rust but again I haven’t tried those so can’t vouch.

        Coming from react you’re gonna need to pretty quickly switch gears to thinking more object oriented. You’re gonna be annoyed at how you can’t just quickly declare a deeply nested interface, that’s just how it is. The biggest change other than object oriented thinking will probably be decorators. Typescript had them experimentally and only for classes, python has them for classes and functions natively. They’re a bit tricky to wrap your mind around when you want to write your own, but not too bad. A lot of Google hits will be outdated on this front. Google specifically “decorators ParamSpec” to see how to make them properly.

        Good luck in your new job, you’ll be grand!

      • NostraDavid
        link
        fedilink
        arrow-up
        2
        ·
        edit-2
        2 months ago

        I can’t stand the bloat of virtual environments

        Sucks to be you, but virtual envs are THE way to keep everything running on your own machine. You can try to keep everything in a single venv, but then you’ll start wondering why it doesn’t work on other’s machines.

        built-in tools provided by the language

        sqlite3 module comes with Python. As does the json module. Use pathlib’s Path object over os.whatever because the API is nicer to work with. abc (short for Abstract Base Class - abc, get it?) is useful for inheritance stuff. I like click, but there’s argparse if you need to write a CLI. Stay away from asyncio if you can - it’s usually not faster and a bigger PITA than it needs to be. Need to transport a binary, but you can only send text? base64. import datetime as dt if your new friend when it comes to datetime objects - to be aware to keep things timezone-native. You’ll need pytz for that - Python doesn’t update fast enough to keep up to date with all the new timezone shenanigants. always check for missing timezones; they’ll cap your kneecaps and kick you in the balls if you’re not careful. http can be used to make calls to APIs though requests is a favorite; slap urllib3 and you got yourself a sauce going on! Skip logging and jump to a lib that supports structured logging, python-json-logger is a nice beginner’s log lib, jump to structlog if you need the raw power (say you want control over other people’s logging output). math is a sleeper hit - powers, roots, floors, ceitings, and statistics is a nice addition on top of that together with random for probabilistic stuff. multiprocessing if you need to run something concurrently: ProcessPoolExecutor for IO, ThreadPoolExecutor for CPU bound stuff (IIRC). re for regex related stuff. uuid if you need a unique identifier (this can be slow in DBs, so take care!)

        ecosystem

        PyPI (Python Packaging Index) if your new friend - pai-pee-ai; not paipai - that’s the JIT implementation of Python: pypy.

        Use pytest to run your tests, ruff for formatting (though I imagine it intimidating for beginners, better to bite the bullet (even if you nibble on it slowly), uv to track your dependencies and Python version.

        Yes, figuring out a nice configuration for these tools is a pain, but that’s what ChatGPT is for. Just don’t go too wild on the settings, as there are MANY, and if something doesn’t work because ChatGPT got a little outdated, it’ll hurt.

        Anyway, that’s about 4 years of experience concentrated in a single page. If you ever feel like an imposter: that’s a common feeling: https://en.wikipedia.org/wiki/Impostor_syndrome If it’s hitting you on the head, see if you can talk with your seniors about it (presuming they’re sane adults) - otherwise there’s always Lemmy to vent :P .

        edit: if you need to handle tabular data: Polars. If anyone recommends Pandas over Polars, hit them with a newspaper until they crawl back under the rock they came from. Unless it’s for GeoPandas, then it’s OK.

        • hector@sh.itjust.works
          link
          fedilink
          arrow-up
          1
          ·
          2 months ago

          Amazing advice thanks!! That’s exactly what I needed: clear overview of the ecosystem & the standard library. Don’t worry about me, I’m not new to complex & ecosystem! I have plenty of experience with C++ and the pain of configuring it !

          It will come with practice fast enough. I need to check out awesome-python!