Django docs are 🔥🔥

Most things Python in my experience habe legit documentacion, in terms of web I really like how easy it is to find stuff for both python and flask.

The documentation for ML related stuff is also pretty legit. Overall, I have never felt lost when dealing with Python stuff. 10/10

@frogstair oh snap, have you actually found shitty docs or environments or is this just a general dislike of the language and ecosystem? nothing wrong with that btw, some people just don't click with some tech stacks

You burnt the docs?!?! No wonder I can't find them.

@AleCx04 Let's take docs for builtin csv module. Class csv.DictReader apparently takes *args and **kwargs which are passed to underlying csv.reader. Okay, but csv.reader only takes filename, dialect, and **kwargs, and both filename and dialect are inherited from csv.DictReader. So what the hell happens with *args? Does csv.reader take some extra arguments which aren't documented? Does documentation for csv.DictReader mention *args just to fuck with users? Is there some special undocumented magic and csv.DictReader doesn't actually pass filename and dialect to reader, but relies on *args? But why does it then take filename and dialect separately?

@hitko oooooooh this is a good one. I glanced through it in the documentation and source code for Python 3.9, it just says that args is an optional keyword. my guess is you can pass everything inside of an array to the csv.reader and then the rest of the code sorts that shit it out through the unpacking of *args

And while definitely trippy without taking a look more in depth it most definitely does not constitute throwing everything out the window and calling it a shitshow of a language or something like that

@AleCx04 Well after checking source of cpython on GitHub and doing a few tests, it seems here anything you pass as *args is indeed completely ignored and even if you try to use it to unpack array of arguments they get overridden by default values.

Anyway, that's far from the only problematic case; for example, documentation for JSON module straight up fails to mention that **kwargs in load / dump methods are actually meant to pass additional arguments to the underlying encoder class. The way documentation is written doesn't help either - often you need to read several paragraphs to understand what some argument does, because, with some exceptions, arguments are only implicitly documented through (verbose) method description. This is especially a pain because you can't simply hover an argument to see its documentation from your editor. Documentation also shows significant lack of consistency within Python, like how standard library interchangeably uses **kwds, **kwargs, **kw, **k, ...

@hitko I dunno man, I have several systems at work in production using python in one way or the other and don't have that issue whatsoever. It sounds to me more like nitpicking rather than a legitimate statement concerning how valid said technology is. If we look hard enough we will ALWAYS find complaints on literally all tech stacks.

You ain't gonna catch me defending VBA tho, but those things you are describing have never stopped morons from developing full applications, you sound smart enough to not be outsmarted by such small details. So I am going to call it as nitpicking

@AleCx04 Not having documentation for each argument is a major pain in the ass every time you're not exactly sure what an argument does. Then look at package management. You install Pillow and import pil. Or even better, cv2 module can be installed from 4 different packages, each with a significantly different set of functionalities. Why is that even possible? Moving on, what about positional vs key-value arguments? Python code allows you to use them interchangeably, but underlying C code doesn't. This whole thing with arguments has been a total dumpster fire full of *args, **kwargs hacks, but instead of adding a mechanism for all function calls to behave the same way, python added extra complexity by introducing / and * "special arguments" to restrict how an argument can be passed. And then, if you need to work on more than one thing or sometimes even just use multiple python apps, you pretty much have to deal with virtual environments.

@hitko I could go on and on... Why aren't related arguments grouped together like options=dict(foo=True, bar=False)? Why does standard lib always use **kwargs to pass options, and then specifies available options somewhere in method description?

The core problem with python is that code is ultimately a technical specification, and to make it readable, python often resorts to some "magic". But whether it's the confusion around key-value arguments or people abusing various "too powerful" workarounds, these things always come to bite python's ass.

@hitko they don't really hurt me but I definitely do get your point my g

@hitko at the same time, it really annoyed me looking into the actual source code for this one, so don't get me wrong, I definitely do see your point, made the docs look shitty and convoluted as hell. And there was no real explanation for it, i had to look at the flipping c source code that defined the reader and even then i could not find a proper explanation for this, made it look like magic, and I don't like magic. Definitely something i can take into consideration and something that now makes me paranoid about the things I use python for, yeah it is on production serving as a glue language, moved into it from the perl scripts we had, not that i disliked perl, but a previous dev made a hell of a lot of line noise with it.

What do you usually work with?

@AleCx04 I do use python on backend for a few web apps, and I use it a lot for my data science related work because that's what most existing tools use. I'm not really worried about using python in production, because problems with its magic usually aren't limited to edge cases, so they can be eliminated early on. The reason I mostly use Go and TypeScript instead of python where possible is that even though they have their share of downsides, there's no huge gap between how code looks for the "front" user (high-level logic with objects, generic functionals like len) vs the "back" user (__[magic]__ methods for everything, tons of hidden descriptor classes).