Hacker News new | past | comments | ask | show | jobs | submit login

> Type-annotated, asyncio-enabled Python hardly resembles the easy-to-understand language I fell in love with back in 2006.

true.

i am all for types in general and for types annotations in python. but i have seen some heavily type-annotated python code lately and i don't think that's where we want to be.

we are starting to look like a heavily templatized cpp code.




Type annotations help catch common errors, and they help humans. Maybe it's not as pretty but as someone who often have to read Python, it really helps me understand what the contract is of a function I'm looking at.


As a big fan of statically typed languages, I agree with you on the utility. Especially after having worked on a large Python projects a few years ago and having to spend a lot of time figuring out what, exactly I could do with a argument named “session”. But when you start turning your dynamically types languages into an ugly statically typed one, maybe we should just admit that we’re using the wrong tool for the job.


That's a thought.

Is the point where your Python codebase needs type hinting to be readable a signal that you've hit the dynamic language/complexity impedance mismatch?

Or is it a sign that your code's readability could be better?

Your "session" remark reminds me of trying to understand the Ruby IMAP library when the only documentation was autogenerated API docs, I had to follow one variable through the entire stack to figure out what it's original type and thus capability, was.

I taught myself to code in Python, and find that well-written Python makes sense without types (tooling support aside), but then being honest, most of the Python code I meet professionally, is barely okay written.

I guess it's like Java, industrial programming code needs a type system to make code written averagely understandable, but not so much of a type system that you spend your time fighting obscure compiler errors.


Also helps IDEs to do code completion


Don't mix things, guy! - asyncio it's one thing: From my point of view it's amazing... makes python be able to compete with nodejs or go.. (not so hard, if you work also on the browser)

- mypy: that's another story, but it's also optional, use it if you want... (my opinion, like in typescript, if I want types I will do it with go or rust)


Honestly, after trying MyPy for a bit, I'm probably going to gradually type. There's some metaprogramming constructs (notably certain class decorators) that are not expressible in the type system, for one. This makes packages like environ-config unusable.

But most importantly, `def foo(lst: list, idx: int):` is fine in 95% of cases. Most of the time, you don't need to go full Java, full verbosity. Document the most important elements - you're taking in a list and an int - and move on.


Good luck finding a pandas or scipy implementation for go or rust :-/


"BlackJack strives to be a full featured crate for general data processing.

Long term goal is to create a lightweight Pandas equivalent by and for the Rust community, but with slight differences in focus..."

https://docs.rs/black-jack/0.1.0/blackjack/

EDIT: That one looks like it's not being worked on actively. Here's a reddit thread with more ideas. Weld looks interesting.

https://www.reddit.com/r/rust/comments/apo66e/dataframes_wha...

https://www.weld.rs/

And Arrow looks like a new project Wes McKinney is contributing to.

http://arrow.apache.org/


Gonum and Gorgonia


Right. Projects can always choose not to enable asyncio. I don't see what the problem is. Right tool for the job, &c.


Type hints are machine-checkable documentation, similar to doctests in my view.

Since I started using them, the number of runtime errors coming out from my own code has been drastically reduced.

Of course one can always go overboard with those `Generic[T]` hints. Though this is a problem of the tool user, not the tool.


> we are starting to look like a heavily templatized cpp code

Which was my main concern when type-hints were added

Give a hand to the strong-typed people and they will take the whole arm.

They will take Python as "now it's like Java" and will push it all the way through.


strong types != ugly syntax (viz. Haskell)


Agreed but that's not necessarily the issue here

(Though yeah templates in C++ turn the ugliness to 11)

Not to mention Python is "strongly-typed". But it doesn't require variables to have a pre-determined type and doesn't do compile time type checks by itself.


Heavily templates C++ code is something very few things can match; I would be quite surprised if anything from Python came close.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: