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

111–120 of 369 posts

Re: Writing Python like it's Rust

#111

Post by BiteCode_dev »

devjab wrote: post #110
BiteCode_dev wrote: post #96

Earlier quoted context omitted.

Not really. First, the JS ecosystem is very web oriented, so if you want to dabble out of there, you often gonna fall short. Secondly, the JS packaging has very poor support for compiled extensions, which mean everything that needs a perf boosts is unlikely to get good quality treatments. Finally, the community makes it a constant moving target. After 20 years of writing both JS and Python, I can still install old dj…

We gradually wanted to move our Java, C# and C++ into a more “generalised purpose” language because it would be easier to maintain and operate a small team with one language in what was becoming a non-tech enterprise. Python was our first go to, because well, it’s just a nice language that’s easy to learn, but we eventually ended up in Typescript and our story was basically the polar opposite to what you mention here…

I find Python works very well to keep my options open, but eventually, there is no replacement for what you exactly did: your job as an engineer.

You evaluated the needs and figured out what tools you needed for the specific job you are doing.

That's what we are supposed to do.

Re: Writing Python like it's Rust

#112

Post by mnbant »

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…

This is my experience as well. There are very few code bases with 100% coverage and strict development practices. Moreover, if the average developers get their hands on one of them, they'll degrade soon.

The problem comes from the very "top", since CPython developers are in camp (2) and celebrate their development practices.

Other languages also have this divide of course but not to the extent that Python has.

As for maintenance: This is also true. I have rewritten a Python code base in C++. Even in C++ it is easier to maintain, because the C++ compiler does not break between versions and there are no new bugs. And modern C++ can look quite like Python.

Re: Writing Python like it's Rust

#113

Post by quietbritishjim »

Kwpolska wrote: post #69
csunbird wrote: post #58

Earlier quoted context omitted.

Isn’t the whole point of named tuples to not iterate over indexes, but to iterate over field names instead, e.g employee.name, employee.salary? You can also use typing.namedtuple as a baseclass for your classes to have the same functionality .

Named tuples have both field names and numeric indexes. If you iterate over a namedtuple, you just get the values . The field names are hidden in a _fields attribute, there is no way to iterate over (name, value) pairs.

> there is no way to iterate over (name, value) pairs

zip(x._fields, x)

I get your point that it's not just a built in method though.

Re: Writing Python like it's Rust

#115

Post by tialaramex »

BiteCode_dev wrote: post #97
tialaramex wrote: post #89

Earlier quoted context omitted.

> the fields I need tools for are vast, and it's the only one that I'm pretty sure will handle a problem decently in all it's various forms Whilst I agree with this stance to some extent, we should be clear that Python is not in fact the panacea you've made it out to be here. It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clums…

> the panacea you've made it out to be here. This is misreading my comment, at best. > It is very possible that a particular problem requires performance Python can't match, so that any Python solution will be too big/ slow/ clumsy and must be rewritten in a better language. This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt…

> This is misreading my comment, at best.

If you don't like the characterization as a panacea, what would you prefer - jack of all trades maybe? All-purpose language ?

> This has been discussed again and again on HN, and the answer to it still stands to this day. So now I'm not giving you the benefit of the doubt.

I'd guess you're thinking you'll measure and just rewrite the hot code paths. The problem is in too many cases when industrialising software it's basically all hot, the heatmap just all glows red. Google people did talks about this maybe a decade ago, it's why Go ended up getting internal support, because if you write software the first time in a language with better performance you don't need to do the rewrite.

I think Python's actual strength is as a language for people whose job isn't primarily to write software. Let me give an example of a choice Python made (admittedly not for years) that is exactly what you should do for that audience, and then the opposite:

Ordered Dictionaries make dict have reasonable performance and yet also behave how naive users who have only a limited understanding of how the machine works would expect, which means they produce less buggy software in practice

Multiple Inheritance is too complicated to teach to a class of say, Geographers, and yet it's not really crucial for the underpinnings of the language, so why go to such lengths to support this feature ?

Re: Writing Python like it's Rust

#118

Post by more-coffee »

extr wrote: post #35

What is the smart money doing for type checking in Python? I've used mypy which seems to work well but is incredibly slow (3-4s to update linting after I change code). I've tried pylance type checking in VS Code, which seems to work well + fast but is less clear and comprehensive than mypy. I've also seen projects like pytype [1] and pyre [2] used by Google/Meta, but people say those tools don't really make sense to…

For your mypy performance question, make sure it's using incremental mode [1] so that it can skip checks on code that didn't change. Yes, it is probably among the slowest of type checkers, but it is also quite thorough.

[1] https://mypy.readthedocs.io/en/stable/command_line.html#incr...

Re: Writing Python like it's Rust

#119

Post by rami3l »

drekipus wrote: post #94

I love python, and I understand the importance of typing, but is there a way to have less physical keyboard typing ? Consider the two examples: `private Dictionary > road = new Dictionary >();` `road : dict[RoadPlate, List[RoadPlate] = {}` Or even just `road = {}` I prefer python simply due to needing less writing and less reading. I can think more about the program when there's less stuff to read

Indeed, that has been a real problem, so now you can probably write `private Dictionary> road = new();`.
Post reply on HN