Hacker News Reader

Comment by mikevm | Hacker News Reader

> Many have imagined and built valuable stuff in interpreted, dynamically typed languages before you, by being more focused on overall structure and making sure it's strict and resilient. One really doesn't have to search far for successful applications that are certainly way beyond 1000 LoC and still iterate pretty quickly for their size.

I once tried to get into a large Python project, and even the IDE (PyCharm) had trouble "guessing" the function parameter types. It's absolutely not scalable. I don't want to be reading a function and guessing "what the hell is the type of this?".

View on HN

Good news! Since ten years ago, you don't have to!

    def myfunc(foo: Dict[str, MyObject], bar: int, baz: str) -> List[MyObject]:

This would be nice if everyone used that. When I looked at the source code for mayan-edms, they weren't using that.

Apache airflow? Doesn't use it. Jupyterhub? Doesn't use it.

I was happy to see projects like Zulip using this, but if it's optional then I can't rely on people actually using it. It's the same thing with ruby/sorbet.

That’s shifting the goalposts a bit. You can use optional typing in your project as it’s scales, and there are plenty of projects that have been stable for what they do through other testing. Pick dependencies carefully and use typing as needed

I'd say typing is even more important when you are using other people's code with your code. It's also a huge productivity boost too when the relevant methods and types are available to you, the editor almost writes the code itself!

The projects that don't use it probably need to maintain compatibility with Python 2, for whatever reason. I expect that more and more codebases will be at least somewhat typed as Python 2 is deprecated everywhere.

This is the same programming community that is half stuck on Python 2, no way should anybody expect types to have reached majority mindshare.

I've only heard this "stuck on Python 2" FUD from non-Python programmers, you may want to get your arguments with the times.

Weird of you to assume that I don't work in Python. Do you just not interact with the scientific Python community? Your anecdata that is blind to large swathes of the community is no more valid than my firsthand experiences. This comes off as defensive, not informed.

It's an objective fact that Python 3 was not adopted quickly (given various EOL deadline extensions) and that plenty of libraries are stuck on 2, so your point that types have been around for 10 years is not really an argument that I can actually expect to be able to use types when working within the ecosystem.

I work in web development, Django moved to 3 exclusively versions ago, and I drop support for Python 2 pretty easily in the libraries I maintain. numpy requires at least 3.7, same for pandas, and sklearn is at least 3.6. When you say "half stuck in Python 2", do you mean you have a lot of legacy code you don't want to update? Because I don't think that's Python's fault.

Ah, so the answer to "do you interact with scientists" is no, even though scientists are responsible for a huge amount of the python code that exists. Got it, maybe consider that your experience isn't universal.

I don't know why you think dismissing legacy code is valid! More code is old than new in the world, and the idea that you're only going to run into codebases with the most up to date versions of software seems pretty naive to me.

Serverless runtimes have historically been behind on Python versions, Airflow had a hell of a time with dependency issues and Python 2, etc etc.

I also don't really care whose fault it is - the question isn't "is Python morally wrong", the question is "can I rely on the technology that you offer as the solution to a problem as being actually used by the community and therefore actually a viable solution to the problem." Python type annotations are not popular.

> I don't know why you think dismissing legacy code is valid!

Because everyone everywhere has legacy code. In that sense, Python isn't split between versions any more than any other language, making that statement moot.

If you want to use type annotations, you can, for years now. If you want to use macros to generate macros in Rust, you can, it's not Rust's fault if you're stuck on 1.20 and don't want to upgrade.

I agree that all languages have legacy code, that was sort of my point :)

> If you want to use type annotations, you can, for years now.

Yes! And it's a cool feature. Can I expect most libraries to provide types so that I know I'm calling them correctly? Is it going to be an uphill battle for my team to use them, because the community at large doesn't find them necessary? The default for a majority of Python codebases is to not use types, and that's totally fine, but that also means that rather than type annotations solving the super-grand-OP's concern, they're going to potentially add friction.

It's likely, and that's FINE, that you're going to be in dynamic-land when you're working in Python, due to the preferences of the community, and it's cool that you can use annotations if you yourself want to get some nice signature checking.

But you don't need the libraries to have type annotations for them to be useful to you. You can use the libraries' classes as types, and type signatures are already very useful even if you only use them in your code. I agree that they will be even better when morelibraries declare them too, but I find that type annotations are a huge benefit in my own code either way.

I think we can agree on that - my point primarily is that:

1. In my own code, they are super helpful

2. I still get really frustrated when I'm calling other libraries (I had this experience when the various typed JSes were fighting it out as well) - in fact for a lot of web-style work that I do MOST of my code is calling a library, which is where I'd get most of the value.

Sure, I agree with that. More libraries supporting types would be great. I don't know why they don't, it's not like they need to support any Python versions that don't support types... I guess most just haven't gotten around to it.

> It's absolutely not scalable.

And yet, somehow YouTube muddled along through and made it work.

And Instagram, and Dropbox (backend and client), and ...

People always forget that none of the things we stress about (code cleanliness, architecture, UX,...) make or break a product.

It's some weird combination of solving an actual problem decently enough (iow, it does need to work most of the time :)), good timing and some arbitrary pick up by the masses.

Like Google succeeded because they provided a no-frills search that had no ads, and geeks like us started pushing it down the throats of our non-geeky friends as The One True Search.

I ain't saying that Python leads to bad code (because you can have bad code in any language, just like you can have good untyped Python), but that there's this talk of scalability like it's some msgic thing that's impossible if all the stars are not aligned.

I agree that it's harder as the project gets bigger, but at the beginning you don't have to worry about that. By the time these problems become real limitations, you hopefully have a business and enough revenue to deal with them, which could include rewriting parts of or the entire application in a statically typed language if necessary.

Reply on news.ycombinator.com