Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python's “disappointing” superpowers

lukeplant.me.uk

Post reply on HN
Print view View original

41–50 of 264 posts

Re: Python's “disappointing” superpowers

#41

Post by KRAKRISMOTT »

lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

I think the issue with Python is that it is relatively underfunded compared to other languages of its size. The entire Python ecosystem lacks leadership. Packaging is a clusterfuck, Pypa today still doesn't contain package metadata (which massively slows down downstream resolvers like poetry and wastes terabytes of bandwidth every year). Non-security issues take forever to resolve. Nothing encourages parties to contribute, unlike Go or Rust. You end up with companies having their own subtly-imcompatible internal forks. The benevolent dictator never cared about performance until recently. Most of Python's changes have been simple syntactic sugar. Python as a compiler engineering project is an exercise in mediocrity compared to V8 or LuaJIT.

Re: Python's “disappointing” superpowers

#42

Post by Spivak »

> But typing.Callable has zero support for them, meaning they can’t be typed in a higher-order context.

https://peps.python.org/pep-0612/

    from typing import Awaitable, Callable, ParamSpec, TypeVar

    P = ParamSpec("P")
    R = TypeVar("R")

    def add_logging(f: Callable[P, R]) -> Callable[P, Awaitable[R]]:
        async def inner(*args: P.args, **kwargs: P.kwargs) -> R:
            await log_to_database()
            return f(*args, **kwargs)
         return inner

    @add_logging
    def takes_int_str(x: int, y: str) -> int:
        return x + 7

    await takes_int_str(1, "A") # Accepted
    await takes_int_str("B", 2) # Correctly rejected by the type checker
I think the author and the people working on Python's type annotations actually agree here. The goal is to have type annotations powerful enough to statically describe all behavior generically without library specific extensions. There hasn't been much push for it but I expect a lot of the author's concerns would be alleviated by a type annotation for types themselves. Being able to say, "alright I'm gonna so some dynamic metaprogramming magic bullshit, but at the end will pop out a class of this shape" probably gets you 80% of the way where.

Re: Python's “disappointing” superpowers

#43

Post by 9dev »

abdullahkhalids wrote: post #25
lordgroff wrote: post #6

I maintain Python code bases for a living, and feel that the language has simply been pushed too far. Static typing in Python doesn't give you the advantage of actually static typing and even IDE support is -- well it's not terrible, just not great. The thing is, once we go through all this static typing exercise in Python, we get no performance advantages, and the whole thing seems bolted on, with worse semantics th…

> the whole thing seems bolted on, with worse semantics than most modern typed languages One of the biggest sources of ugliness is the "None". The standard way of declaring variables ahead of time is setting them to None. But then, the type hints just become these ugly unreadable Optional[ActualTypeofVar] everywhere.

Im used to just doing

  x: list[str]

  if foo:
    x = []
And if a variable is nullable, I use a union:

  x: list[str] | None = None
That’s much more readable to me!

Re: Python's “disappointing” superpowers

#44

Post by simplicio »

paganel wrote: post #4

> I’m worried that a de-facto move away from dynamic stuff in the Python ecosystem, possibly motivated by those who use Python only because they have to, and just want to make it more like the C# or Java they are comfortable with, could leave us with the very worst of all worlds. It is certainly happening, and I'm not sure Python the language is all the better for it. I say that as a guy who explicitly mentioned this…

My theory is that Python and C++ are slowly evolving towards eachother, and in 20 years will merge into the same (very confusing) language.

Re: Python's “disappointing” superpowers

#45

Post by cb321 »

amelius wrote: post #3

Is there any language out there that improves on Python in various ways but still allows convenient access to literally the entirety of Python's ecosystem of libraries?

While I agree with the @elcritch reply (https://news.ycombinator.com/item?id=34616755) that Nim is just nicer overall, depending upon one's idea of "convenient access to literally the entirety", Cython may be more to your liking as mentioned else thread: https://news.ycombinator.com/item?id=34616052

While usually pitched as "only" a language for fast extension modules and/or bindings to existing C/C++ code, Cython is really a language in its own right. https://cython.org/ has some more details.

It works by generating C code that calls the regular CPython API, managing all the ref count and tuple jazz that's rather a hassle to write in C directly. Then you run a C compiler against this code and it literally just links against the CPython .so's/DLLs. So, it's not just calling module code the same way as CPython, but actually calling the core built-in to Python code the same way as well.

As you add more `cdef` type annotations to your cython code, the generated C code becomes closer & closer to hand-written C code (both in hazards and efficiency).

Of course, a caveat is that may be Cython also doesn't improve upon Python very much as a language, except for allowing gradual static typing.

Re: Python's “disappointing” superpowers

#46

Post by 9dev »

wheelerof4te wrote: post #22

Either embrace dynamic typing and provide good error guards...or try to use type hints and still make good error guards. We had an entire history of Python 2 without type hints. Why use them now?

How come everyone realised the benefits of typing by now, except the Python community?

Re: Python's “disappointing” superpowers

#47

Post by abdullahkhalids »

joshuamorton wrote: post #35
mjr00 wrote: post #29

Earlier quoted context omitted.

That's because your type is Optional[TypeOfVar] though; if you try using that variable in a place that expects just TypeOfVar before it's set, you should get an error.

Right, in langs with c-style scoping, this is an issue, but in python if foo: x = a else: x = b Works, so there's no need to predeclare.

A very common pattern in python is to declare all instance variables of a class in the __init__ method by setting them to None. This is done for

* code readability; all relevant variables are in one place

* Python is a prototyping language, and a very common usage pattern is doing dir(object) to determine the names of all variables that could be set to something.

Re: Python's “disappointing” superpowers

#48

Post by thereisnospork »

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.

Re: Python's “disappointing” superpowers

#49

Post by abdullahkhalids »

VygmraMGVl wrote: post #40
abdullahkhalids wrote: post #25

Earlier quoted context omitted.

> the whole thing seems bolted on, with worse semantics than most modern typed languages One of the biggest sources of ugliness is the "None". The standard way of declaring variables ahead of time is setting them to None. But then, the type hints just become these ugly unreadable Optional[ActualTypeofVar] everywhere.

You can declare a type-hint beforehand without setting the value of the variable. See: https://peps.python.org/pep-0526/#global-and-local-variable-...

Yes, but then those variables are not visible when we dir(object), which makes it harder for the user to prototype. Certainly, type hinting should not get in the way of the users.

Re: Python's “disappointing” superpowers

#50

Post by ImprobableTruth »

joshuamorton wrote: post #36
ImprobableTruth wrote: post #33

Earlier quoted context omitted.

Which of these do you think require dynamic typing?

A lot of the orm style things are not really feasible in static-er languages without clunky approaches like codegen.

What part specifically? Java is (in)famous for its orms after all. Unless you want to count that as clunky codegen? I'd argue that all metaprogramming boils down to that though.
Post reply on HN