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

181–190 of 369 posts

Re: Writing Python like it's Rust

#181

Post by okasaki »

Shish2k wrote: post #168
okasaki wrote: post #164

> I have no idea what is going on from the signature itself. Is records a list, a dict or a database connection? Is check a boolean, or a function? What does this function return? What happens if it fails, does it raise an exception, or return None? [...] This type of objection is only raised by people who have never seriously used Python before. It sounds convincing that this is a serious flaw in Python, but in prac…

> This type of objection is only raised by people who have never seriously used Python before How serious is “serious”? Because I’ve worked on millions-of-lines python projects powering billion-dollar companies, and I 100% agree that maintaining untyped python code that somebody else wrote (or that I wrote myself, 6 months ago) is a nightmare for exactly these reasons...

I mean I can't even imagine what would lead anyone to write millions of lines of Python for a single project, so maybe there's a level of serious above what I do. Maybe you're doing it wrong?

Re: Writing Python like it's Rust

#182

Post by okasaki »

dgan wrote: post #170
okasaki wrote: post #164

> I have no idea what is going on from the signature itself. Is records a list, a dict or a database connection? Is check a boolean, or a function? What does this function return? What happens if it fails, does it raise an exception, or return None? [...] This type of objection is only raised by people who have never seriously used Python before. It sounds convincing that this is a serious flaw in Python, but in prac…

> it never comes up because when you know what domain you're working in it's always immediately obvious what types the arguments are. Oh this one is hilariously wrong. Is it InvoiceLine that we are getting here? Or Maybe LineInvoice? Nope those aren't the same. But the only argument is called «line». How shameful. Much sadness. Better add a print statement, push a new build and comeback in twenty minutes

It sounds like the codebase sucks or you haven't taken enough time to understand it.

Re: Writing Python like it's Rust

#183

Post by adsharma »

If you write python sufficiently like rust, you should be able to transpile it into actual rust.

I spent a few months last year writing py2many. But was surprised by how ChatGPT outperformed it.

I do however believe that there is room for a good transpiler and a language ecosystem for a dialect of python you're proposing here. It needs a community and a lot more work.

Re: Writing Python like it's Rust

#184

Post by CoastalCoder »

I'm curious how much our early programming experiences fix (as in, make permanent) our mindset about types.

As a little kid, I dabbled a bit in BASIC.

But my more formative years, in high school and college, really centered on statically typed languages: Pascal, then C++.

In the 20+ years since then, statically typed languages have always seemed far saner to me than, e.g. Python.

I can think of various explanations for this:

(a) Because I got my start in statically typed languages, that became ingrained as my "natural" way to reason about programs. Which was self-reinforcing, as practice reinforced my ability to express program constraints using types.

(b) I'm naturally biased toward writing correct programs, rather than rapid prototyping. So I would have gravitated towards statically typed (or even proven) programs regardless of my early education.

Re: Writing Python like it's Rust

#185

Post by ReflectedImage »

8589934591 wrote: post #31
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.

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). Code, like the one provided by the OP, should be valued and encouraged to prevent future bugs. Incorporating tools like Mypy during pre-commit and pyright during code e…

Using static typing in Python will generally speaking significantly increase the number of bugs in the codebase.

Re: Writing Python like it's Rust

#186

Post by mumblemumble »

BiteCode_dev wrote: post #107
Yoric wrote: post #100

Earlier quoted context omitted.

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

To be fair, a division between hell and heaven will happen with any language. The question is: is this particular hell worth the result? There is no generic answer to that of course, it just happens is has been the case for me during those 20 years. First, you have to get to the industrialization phase. And of course, you have to get there, with the constraint of time, budgets, and talent. Second, Python does have le…

This is roughly my experience, too.

Static type safety has interesting YAGNI characteristics. For the bits of the code that must work, and where defects and regressions due to type errors may be subtle and difficult to detect, it's indispensable.

But it can also be an impediment to iteration. Sometimes the code you're working on is still so experimental that you don't really know what the best structure and flow of data will be yet, and it's easier to just bodge it together with maps and heterogeneous lists for the first few iterations so you can let the code tell you how it wants to be structured. Having to start with static types subtly anchors you to your first idea. And the first is typically the worst.

Something I really like about Python for this sort of thing is that I have a lot more ability to delay this industrialization stuff to the last responsible moment, and be selective in where I spend my industrialization tokens. Here's a list of the languages where I've found selectively rewriting the important bits in Rust to work well: C, C++, Python. I know which of those I'd rather use for prototyping, scripting, and high level control.

Relevant Fred Brooks quote: "Plan to throw one away. You will, anyway."

Re: Writing Python like it's Rust

#187

Post by dgan »

okasaki wrote: post #182
dgan wrote: post #170

Earlier quoted context omitted.

> it never comes up because when you know what domain you're working in it's always immediately obvious what types the arguments are. Oh this one is hilariously wrong. Is it InvoiceLine that we are getting here? Or Maybe LineInvoice? Nope those aren't the same. But the only argument is called «line». How shameful. Much sadness. Better add a print statement, push a new build and comeback in twenty minutes

It sounds like the codebase sucks or you haven't taken enough time to understand it.

That's beside the point. Those types ("types" you see? hehe) go against your argument "it's obvious from the context", because now it becomes "it's obvious from the context if you are lucky enough that your codebase doesn't suck or you spent 'enough' time figuring it out"

Re: Writing Python like it's Rust

#188

Post by FireInsight »

movedx wrote: post #126
miiiiiike wrote: post #125

I can’t get over how clunky Python 3 is getting. Does anyone like working with type hinting in Python? All of my code is typed but compared to basically every other type system the process was far more painful than it should have been. Even years later I still keep printouts of the typing documentation next to me so I can save time when I invariably need to look up the multiple ways you can define ‘T’ when it would j…

Personally, I switched to Go.

Personally, I switched to Go and soon after to Nim. https://nim-lang.org/ It's great!

Re: Writing Python like it's Rust

#189

Post by orthoxerox »

zelphirkalt wrote: post #162
orthoxerox wrote: post #104

Earlier quoted context omitted.

> At some point you gotta ask yourself: Why am I still writing Python then, if I want to write Rust? If I want Rust's safety, why not write Rust then, with battle proven tools and better type system from the start? Garbage collection

To what end? I think avoiding manual memory management is great, but I never had issues in Rust either, since I don't manage memory manually there either. I think that is kind of a point of Rust, as it avoids that whole class of bugs common in C programs. But to what end do you want garbage collection (GC)? Just for having GC? Or a more specific purpose, that is difficult to attain with Rust's model? For example: I u…

Just for having GC. When I'm writing Python, I am fine with not saving every CPU cycle and every byte of RAM, but having types saves my productivity.

Re: Writing Python like it's Rust

#190

Post by dagmx »

Yoric wrote: post #100
BiteCode_dev wrote: post #76

Lots of comments here are stating that typing is half baked in Python, and that if you gotta use types, you should use another language. But that's missing the point that Python is still not meant to be the best at anything, but good at most things. And in this case, it's exactly what you get: optional typing, with decent safety if you need it. You can quick script or design seriously, you can explore in a shell or c…

On the one side, yes Python is incredibly versatile. On the other side, I have worked on many Python projects, some of them fairly high profile, and I have seen exactly two kinds of Python codebases: 1. a few were written by extreme professionals, plugging at every single hole, with ~100% coverage, plus considerable maintenance because every dependency upgrade tends to break something; 2. many that feel cobbled toget…

How are any of these points exclusive to Python among the commonly used languages?

Everything you said applies equally to many C++ projects I work with as well

Post reply on HN