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

Writing Python like it's Rust

kobzol.github.io

Post reply on HN
Print view View original

301–310 of 369 posts

Re: Writing Python like it's Rust

#301

Post by ReflectedImage »

digdugdirk wrote: post #298
__MatrixMan__ wrote: post #290

Earlier quoted context omitted.

You're absolutely right that: > Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. And for the software engineer, this is also true: > [it is] important ... to learn multiple programming languages But I don't think the majority of python users are software engineers. They're data analysts, they're scientists, they're students. They'll never…

100% this. As one of those people graduating from "Maker of Excel-abominations", I absolutely love that python can shape itself to my learning curve, while being useful the whole way through. Articles like this expose people like me to concepts of typing that I never would get otherwise, and by practicing the concepts in python I might eventually be able to make the leap.

Please don't.

This is about people trying to use the wrong typing system "static typing" in a language that already has a better typing system "dynamic typing".

This is about bad programmers who have come from Java and want all other programming languages to look like Java.

Re: Writing Python like it's Rust

#302

Post by ReflectedImage »

RhysU wrote: post #123
mgaunard wrote: post #9

I've seen a bunch of code like this, usually written by juniors once they get a bit of experience and discover the concept of types. A surefire way to make your Python code terrible. The whole point of Python is the duck typing. If you're not going to use that then you might as well use a real programming language.

> The whole point of Python is the duck typing. Duck typing implies that "Should this work?" has one true answer: "Did it work?" I am at work to work, not to play guess-and-check with upstream libraries.

When you couple that with an interpreted language with no compile time, finding the answer to did it work is often faster than should it work.

Using Duck typing in a scripting language is the correct choice.

Re: Writing Python like it's Rust

#303

Post by k1next »

I really like type hints in Python. It allowed me to catch several errors before running code. But it isn't always the most straight forward process.

However, my most frequently occurring thought is: I'm doing all the typing, I wish I could get some performance benefits out of it.

Re: Writing Python like it's Rust

#304

Post by ReflectedImage »

tcfhgj wrote: post #279
ReflectedImage wrote: post #225

Earlier quoted context omitted.

Iterating in Python is always faster than iterating in Rust. If you do indeed find what you are saying then you simply speaking aren't able to write Python code.

I thought this too before my current python project. It doesn't even use type hints and has no tests. When I look at something I don't know what it is, what it does, and have to debug there (mentally or actually) to even know what's happening. If I change something, a few runtime errors pop up right at the start. Others take 30 minutes.

This may shock you but there is effort involved in learning how to use Python effectively.

Re: Writing Python like it's Rust

#305

Post by ReflectedImage »

wtetzner wrote: post #258
ReflectedImage wrote: post #225

Earlier quoted context omitted.

Iterating in Python is always faster than iterating in Rust. If you do indeed find what you are saying then you simply speaking aren't able to write Python code.

No, because to iterate in Python, you have run the program and get it into the right state. For many things in Rust, I can just use `cargo check`.

From that statement, I'm not convinced you know Python nor Rust.

I'm going to suggest you read the following: https://docs.pytest.org/en/7.3.x/ https://doc.rust-lang.org/rust-by-example/testing/unit_testi...

Re: Writing Python like it's Rust

#306

Post by kobzol »

mgaunard wrote: post #56
v21 wrote: post #52

Earlier quoted context omitted.

> Typically, the selection of a programming language is predetermined in brownfield projects, leaving little room for choosing the "ideal" programming language for migration unless it is absolutely necessary (go can be a suitable option for migrations). Yep - or it's the standard for some tasks & the important thing is being able to use the ecosystem of external packages that everyone else uses. In this case, the aut…

In computer vision, you use Python for prototyping and research. It of course gets rewritten if it's to be actually used, think for example of the guidance system in a car, plane, or weapon. It's pretty much the same for AI, except that there is an increasing trend in AI of it being used by people that do not have the skills to do the productionization.

I agree that in most cases it should be rewritten for production, but in my experience that quite often doesn't happen, and AI stays in Python even for production usages.

Re: Writing Python like it's Rust

#307

Post by tcfhgj »

ReflectedImage wrote: post #304
tcfhgj wrote: post #279

Earlier quoted context omitted.

I thought this too before my current python project. It doesn't even use type hints and has no tests. When I look at something I don't know what it is, what it does, and have to debug there (mentally or actually) to even know what's happening. If I change something, a few runtime errors pop up right at the start. Others take 30 minutes.

This may shock you but there is effort involved in learning how to use Python effectively.

What has this to do with my comment?

Re: Writing Python like it's Rust

#309

Post by steve_gh »

ReflectedImage wrote: post #301
digdugdirk wrote: post #298

Earlier quoted context omitted.

100% this. As one of those people graduating from "Maker of Excel-abominations", I absolutely love that python can shape itself to my learning curve, while being useful the whole way through. Articles like this expose people like me to concepts of typing that I never would get otherwise, and by practicing the concepts in python I might eventually be able to make the leap.

Please don't. This is about people trying to use the wrong typing system "static typing" in a language that already has a better typing system "dynamic typing". This is about bad programmers who have come from Java and want all other programming languages to look like Java.

Not better. Different.

Languages make different choices to suit different domains, and with perfectly good reasons.

Don't complain, embrace the richness and diversity of programming languages. And choose the right one for each task.

Re: Writing Python like it's Rust

#310

Post by __MatrixMan__ »

digdugdirk wrote: post #298
__MatrixMan__ wrote: post #290

Earlier quoted context omitted.

You're absolutely right that: > Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. And for the software engineer, this is also true: > [it is] important ... to learn multiple programming languages But I don't think the majority of python users are software engineers. They're data analysts, they're scientists, they're students. They'll never…

100% this. As one of those people graduating from "Maker of Excel-abominations", I absolutely love that python can shape itself to my learning curve, while being useful the whole way through. Articles like this expose people like me to concepts of typing that I never would get otherwise, and by practicing the concepts in python I might eventually be able to make the leap.

It's worth using a type checker for long enough to get a feel for how it can find bugs that would take you much longer to find at runtime. From there it's pretty easy to imagine how languages designed from the get-go to do this might do it even better.

It's also worth asking if the people who read your code are going to disengage when they see a big pile of type hints. It can be "better" in some abstract sense and still worse for the task at hand.

Post reply on HN