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

51–60 of 264 posts

Re: Python's “disappointing” superpowers

#51

Post by samstave »

nextaccountic wrote: post #23
yummypaint wrote: post #11

Earlier quoted context omitted.

I routinely use cython to compile python for heavy workloads. A big part of the ~10x speedup i usually see comes from strategically assigning true static types to certain variables that get frequently iterated or compared. Most variables are left as standard python as it isn't necessary to change them for performance. My experience has been that cython "just works" even with lots of external libraries etc, and the co…

> I routinely use cython to compile python for heavy workloads. an alternative is rust + pyo3 https://pyo3.rs here's a web framework written with it, https://robyn.tech the other poster child for pyo3 is polars, https://www.pola.rs it's simply, amazing.

which of these links should I start with with zero xp?

Re: Python's “disappointing” superpowers

#52

Post by phlakaton »

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 mistake is to assume that Python's type hints form a complete static typing system. Of course they fall short if you think that's what they're supposed to be. I think of it instead as a sometimes-useful subset of checks that you might get from a static typing system, and I use it in those places in my projects where I think it will be the most useful. The very fact that I can think of it as an option I can enable puts it in a totally different space from traditional static typing systems.

Re: Python's “disappointing” superpowers

#53

Post by [deleted] »

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…

[deleted]

Re: Python's “disappointing” superpowers

#55

Post by ImprobableTruth »

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…

Honestly, static typing encouraging data shape documentation alone makes it worth it to me. Yes, they're pretty hacky in Python and don't feel great, but I'm sure it'll continue to improve.

I'm just so over having to guess what a function might accept or return. Life is too short to spend it constantly reverse engineering code because people can't be arsed to write proper documentation.

Re: Python's “disappointing” superpowers

#56

Post by [deleted] »

KurtMueller wrote: post #30

Python the language doesn't give you super powers and I would say that its clunkier and less elegant than Ruby and obviously not as powerful as languages like F#. Python's ecosystem and contributors are its biggest benefits and they help you succeed in spite of the language itself.

[deleted]

Re: Python's “disappointing” superpowers

#57

Post by sundarurfriend »

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?

PythonCall [1] and PyCall [2] provide pretty convenient ways to interoperate with Python from the Julia language.

It has great package/environment management, excellent (potentially close-to-C) performance, automatic type inference, and a good set of interactive tools that make for a rich REPL.

But any such FFI (from any language) is an additional point-of-failure, an extra gear that could break and has to be maintained. And on the con side of Julia, there's an initial compilation time (which is improving version to version, but still a factor to consider).

Also it should be mentioned that the advantage of Python is not only its ecosystem of libraries, but also the vast array of tutorials and learning resources, and of development tools. Those are areas where most other languages have to play catch-up with Python, especially a relative newcomer like Julia.

[1] https://github.com/cjdoris/PythonCall.jl [2] https://github.com/JuliaPy/PyCall.jl/

Re: Python's “disappointing” superpowers

#60

Post by travisjungroth »

abdullahkhalids wrote: post #38
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.

Let me restate. To prevent ugliness in typing, either * Python should have a way of declaring variables without setting them to None, so we can type hint them to their actual types. Pre-declaration is very important for a prototyping language, and needs to be done in a way that the variable is visible to dir(). * Come up with a cleaner syntax than the wordy Optional[]. Thankfully, they have recently moved on from the…

    a: int

    b: str | None = None
Post reply on HN