Python

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.

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.

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.

uv

Everything else feels 4 to 15 years behind.

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!

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.

Pydantic offers awesome runtime validation (using Rust).

A sane language, you say.

Yes:

Operator '+' cannot be applied to types 'number[]' and 'number[]'.

We're talking about Typescript here. Also I did say that it has some big warts, but you can mostly avoid them with ESLint (and Typescript of course).

Let's not pretend Python doesn't have similar warts:

>>> x = -5
>>> y = -5
>>> x is y
True
>>> x = -6
>>> y = -6
>>> x is y
False
>>> x = -6; y = -6; x is y
True

>>> isinstance(False, int)
True

>>> [f() for f in [lambda: i for i in range(10)]]
[9, 9, 9, 9, 9, 9, 9, 9, 9, 9]

There's a whole very long list here. Don't get be wrong, Python does a decent job of not being crazy. But so does Typescript+ESLint.

I’ve worked professionally in python for several years and I don’t think it’s ever caused a serious problem. Everything’s in docker so you don’t even use venv.

"It's so bad I have resorted to using Docker whenever I use Python."

What is so bad about virtual environments?

They're a solution to a self-inflicted problem. They're only "really nice and useful" if you accept that having your projects stomp all over each others' libraries and environments is normal.

If projects were self-contained from the outset then you wouldn't need an additional tool to make them so.

If I need to keep my Python environment separate I’d rather spin up a docker container. They make virtual environments pointless

You can enable the foot-shooting complexity by writing modules for Python in C++, since it's very easy to do. Why do I know this? Well...