Hacker News Reader

>I don't know why sum types are a blessing, also I don't know why pattern matching makes anything better.

That's because you're inexperienced and haven't used them before. Try haskell or rust. This level of type safety actually reduces logical branching errors. And the key word is <exhaustive> pattern matching.

Googling isn't going to give you the insight here imo you need the experience (probably a couple months). If you don't plan on getting it I suggest you ask a haskell developer or rust developer about why exhaustive pattern matching is such a great feature.

> Python has multiple unrelated mechanisms to manage program state

This is like a slightly bad for people who have ocd towards library organization. Two ways to do the same thing exists everywhere. Do you use looping or tco recursion? Why do some languages support both? Doesn't matter that much. This doesn't make a language horrible just makes it a bit bloated. Much worse is stuff like javascripts undefined value. Also TS has tons and tons of libraries that do the same thing. Why isn't that setting off your "bad" red flag instincts? Is it because they aren't in the std? So redundant commands outside of the std are ok but within the std.. bad bad bad? Have you actually hit a real problem related with this or is it just something that feels bad because of ocd?

>It's not possible to make static typing ineffective.

Categorically false. Python does have patterns and tricks which static type checkers can't catch. You struggle with meaning here because you failed to comprehend what I wrote and you're now arguing against a misinterpretation of my statements. Reread that part again, you definitely misunderstood.

How much experience do you need and what kind? I don't have articles published in IEEE journals, but don't think you can get there in few months. But I can write simple proofs in eg. Coq or TLA+, so, I probably know a thing or two about types.

My work experience is measured in decades at this point. So, maybe you want to reflect on your ideas... it does take time to appreciate both the positive and the negative sides of any given type system. I don't think a few month will be enough, if you start from absolute blank slate. It's also silly to measure this in time, rather than effort. You probably never worked on complex problems, nor did you work on problems that require research, as opposite to copying from "best practices". This is where your conviction comes from, at least this is what it looks like.

You seem to confuse "real"state management solutions (closures, objects) with syntactic sugar like context managers. Any class implementing __enter__ and __exit__ can be used as a context manager. The protocol doesn't impose any semantics to it. As for the presence of closures additionally to objects: this is a natural consequence of having nested functions and lexical scoping. However, it is quite uncommon to use closures to manage state in Python.

Why is pathlib bad?

Edit: I'm asking because pathlib is as good as a Python lib could be for me. Path manipulations are extremely clear and always safe. What more do you need?

It's broken just as os.path is. Python doesn't work well with file names in principle: it wants everything to be Unicode. That works for many, but if you want reliable code... you just have to throw all of that away.

Also, in case of pathlib, it adds no value on top of os.path of which it is a wrapper. Instead, it made the original library it wraps worse, because now os.path also needs to know about pathlib to be able to handle path fragments represented as pathlib instances.

All in all, it offers very little utility (a handful of shortcuts) vs increasing the size and memory footprint of "standard" library, complicating dispatch and therefore debugging... it's a bad trade.

Just not to get you confused. It's not an awful trade. It's not like the sky will fall down on you if you use it. It's just mostly worthless, with negligible downsides.

> Python doesn't work well with file names in principle: it wants everything to be Unicode. That works for many, but if you want reliable code... you just have to throw all of that away.

Windows' APIs use UTF-16 and most file name encodings on Linux are UTF-8. How should Python handle this better?

> Also, in case of pathlib, it adds no value on top of os.path of which it is a wrapper.

Completely disagree. os.path is annoying to use. Treating paths as objects with methods and joining them with / makes my life much easier.

> increasing the size and memory footprint of "standard" library

By a ridiculous amount. pathlib is just another pure Python module with a bunch of simple functions and classes. [1]

> complicating dispatch and therefore debugging

You can simply declare and accept `Union[str, os.PathLike]` and convert the paths to whatever you want at the entrypoints, then use that in your own project. Where is the complexity? I've never seen this make debugging harder, it's just an additional type.

[1] https://github.com/python/cpython/blob/d9fc15222e96942e30ea8...

> most file name encodings

You just repeated what I said. Just read it again. You already know the answer, you just need to understand it.

> Completely disagree.

And make no worthwhile argument.

> You can simply declare and accept `Union[str, os.PathLike]`

What does this have to do with debugging? Do you know what "debugging" means?

I'm guessing verbosity? It also reads like they don't know why pathlib exists and assume they were created at the same time.

os.path came first, often works by poking the filesystem directly even when it doesn't seem like it needs to (vague memory, not completely certain), and I believe has os-specific quirks (so code won't necessarily work without changes).

pathlib was created later as a pure-python implementation that allows for manipulation paths without touching the filsystem except when you explicitly tell it to. Because it's also pure python I don't think it has any os-specific quirks either, but I haven't explored it in depth. Code should work across operating systems without changes.

I think I also remember at one point people talking about completely replacing os.path with pathlib, or at least gutting os.path to the essentials that wouldn't work as part of pathlib.