Live data from Hacker News

Python's “disappointing” superpowers

lukeplant.me.uk

171–180 of 264 posts

Re: Python's “disappointing” superpowers

#171
post #169

Earlier quoted context omitted.

I'm talking more about really simple patterns that Python's type system just can't support. Take kwargs. They've existed forever. A really common and not-stupid pattern is to write a subclass such that you only specify some arguments you care about, and then take *kwargs to pass on to the super constructor. Can't type this. You have to exhaustively enumerate those kwargs and pass them in manually, or else you lose ty…

Yes, that exact scenario is supported with TypedDict. And while that is a simple pattern, it's not a good pattern, and quickly becomes unmaintainable in a program of any size. Using *kwargs because of Too-many-arguments and so you can violate the Liskov substitution principle isn't good programming. Just because it can be done doesn't mean we should start bastardizing typing to make it easier.

> Yes, that exact scenario is supported with TypedDict.

I don't think so. I just threw together a simple example that doesn't work:

    from typing import TypedDict

    class A(TypedDict):
        name: str
        age: int

    def myfunc(**kwargs: A):
        print(kwargs)

    myfunc()
No errors with mypy. In fact, kwargs is inferred as `dict[str, A]`, which is unbelievable given that Python explicitly supports `**kwargs` as a way to represent a grab-bag of keyword arguments.

> And while that is a simple pattern, it's not a good pattern, and quickly becomes unmaintainable in a program of any size

It's not though, if you had a proper type system. For example, you could do this trivially in Typescript and it would automatically infer the types of the rest of the kwargs. That means that your type information is preserved, making it possible to keep using your subclass without losing information about the total set of arguments it supports. The advantage is that you can add/remove arguments to your base class without having to hunt down every subclass, and you're guaranteed to be correct (and it would error otherwise!).

Re: Python's “disappointing” superpowers

#172
post #158

Earlier quoted context omitted.

This is almost always framed in a way that shows large systems need the extra rigidity of some static systems. And that dynamic systems are only about rapid prototyping. I think that is a bit of a false framing. To wit, any system of 100k LOC will be hard to get into. Even harder to make changes in. There is no getting around that. None. Even worse if you have many entities flying about these 100k LOC. Each change to…

This is a false equivalence. You need all the help you can get maintaining large codebases and static typing is a huge help.

What did I make an equivalence between? Large codebases are hard, period. That is all I am saying. Having worked on 100k LOC systems in static and in dynamic, I will not claim either has a benefit. That is just hard.

Static analysis is, of course, good. If that is static typing or otherwise. So is running the code making sure it does what you want when running.

What is not a huge help, is a byzantine type hierarchy that nobody understands. Which is all too familiar to me from any codebase I have worked on with folks that dived straight into the type system before they knew what they were doing in the system.

Many strong type proponents have moved to the categories view. If you know the category type of what you are doing, the idea is that that will prevent bugs. But... that hasn't been my experience. Often it just hides what is actually happening behind another layer of jargon. Jargon that is not native to the problem being solved.

Re: Python's “disappointing” superpowers

#173

Earlier quoted context omitted.

[flagged]

That is the most brazenly false statement I've ever heard. "Python is superior due to dynamic typing, and also all types in Python can be statically inferred!" Wow, you should let them know that type hints was a total waste of time because you could already infer them! I think it's clear you have a very weak understanding of this topic, and you have no interest in having a civil conversation. Good night!

[flagged]

Re: Python's “disappointing” superpowers

#174
post #65

Earlier quoted context omitted.

> everything is an object in Javascript Everything is an object in Python too. > There's no need to distinguish between classes and "dicts", as you have to with Python. "dict" in Python (or at least Python 3, but Python 2 is EOL now so Python 3 is the only active Python there is) is a class. You can even subclass it, which if you want a customized dict for some reason in your particular application is often the best…

> Everything is an object in Python too. Ah yes, true. JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. This makes TypeScript's data model much simpler to manage. Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? I know the latter requires custom plugins.

> JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses.

Can you explain a bit more about what you mean here?

> Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python?

Of course. With dataclasses that's what Python itself does; that's a pure Python module:

https://github.com/python/cpython/blob/3.11/Lib/dataclasses....

For MutableMapping, Python currently implements it as a C class for speed, but you could implement the same functionality in pure Python. That's what earlier versions of the collections.abc module did.

> I know the latter requires custom plugins.

I don't know what you mean here. See the pure Python module that Python itself provides above.

Re: Python's “disappointing” superpowers

#175
post #75

All these features are nice and stuff... But they are often runtime features... At compile time Python doesnt tell you wether a program is correct. Which is fine for small programs or small services. But any big system is written in python is really hard to maintain without LOTS of unit tests... Static typing, compile time checks just win in the long run. And with languages like kotlin you still have all the advantag…

No programming language tells you if a program is correct at compile time. Type errors aren't a very common type of bug either.

“No programming language tells you if a program is correct at compile time” is technically true, but my experience is that about 99% of the refactors I do in rust, no matter how large, go back to working correctly as soon as the code compiles again. I don't think anything like this is possible in a language like python.

Re: Python's “disappointing” superpowers

#176

Let's stop calling "dynamic" and "static" versus "runtime" and "comptime" instead ? Also, "dynamic code generation" for "meta programming" ?

static and dynamic refers to where you find an object, not when it lives.

Some people like to know which type of meta programming is being used at a given point. This is something akin to "all dynamic code generation is meta programming, but not all meta programming is dynamic code generation".

One should be careful to not merge or eliminate words with subtle differences. They usually exist for a reason.

Re: Python's “disappointing” superpowers

#177

Earlier quoted context omitted.

https://games.greggman.com/game/dynamic-typing-static-typing...

> has on average 2.5x the number of bugs This claim is not supported by the linked article. In fact, the main claim (only 2% of bugs are type errors) of the linked article also does not make any sense. It is based on the assumption, that typing errors only ever cause TypeError, AttributeError, or NameError in Python, which is, ironically, false, because Python is a dynamic language. To give a concrete example, I went…

That not even an error, it's an usability improvement.

Re: Python's “disappointing” superpowers

#178
post #174

Earlier quoted context omitted.

> Everything is an object in Python too. Ah yes, true. JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. This makes TypeScript's data model much simpler to manage. Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? I know the latter requires custom plugins.

> JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. Can you explain a bit more about what you mean here? > Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? Of course. With dataclasses that's what Python itself does; that's a pure Python module: https://github.com/python/cpython/blob/3.11/Lib/dataclass…

There is no difference between `object["hello"]` and `object.hello`. So in Typescript, all you need is `interface`, that's it. Everything (except primitives) is just an `interface` with keys or index signatures.

> Of course. With dataclasses that's what Python itself does; that's a pure Python module:

Sorry, I meant that you can't create an equivalent class that typechecks the same way. For example, when you define a dataclass with fields, mypy and pyright are capable of inferring what args and kwargs the constructor supports. But that's because it was implemented as a special case. For example, see the mypy docs [1]. If you just alias `dataclasses`, you lose type support!

Pydantic is a library with similar semantics, and the only way to get typechecking support is to install the pydantic plugin for the typechecker you use. The language simply can't express it.

[1] https://mypy.readthedocs.io/en/stable/additional_features.ht...

Re: Python's “disappointing” superpowers

#179
post #174

Earlier quoted context omitted.

> Everything is an object in Python too. Ah yes, true. JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. This makes TypeScript's data model much simpler to manage. Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? I know the latter requires custom plugins.

> JavaScript goes one step further though, and has no distinction between get-item accesses and attribute accesses. Can you explain a bit more about what you mean here? > Is it even possible to implement your own `MutableMapping` or `dataclasses` equivalent type in Python? Of course. With dataclasses that's what Python itself does; that's a pure Python module: https://github.com/python/cpython/blob/3.11/Lib/dataclass…

[deleted]

Re: Python's “disappointing” superpowers

#180

While this might be about my most unpopular opinion, it feels like it is time to start putting together a Python 4.0. I don't particularly have skin in the game but there is(?) enough meat on the bone around things like improving the GIL status quo, JIT compiling, static typing, and presumably etc. to be worth a breaking change.

Maybe string can be ebcdic this time around?
Post reply on HN