I feel like the elephant in the room is that for most cases in this blog post, you either use NumPy arrays or something else like it. You can make ndarray subclasses and that helps but type hinting and NumPy feels so… poorly done.
Writing Python like it's Rust
191–200 of 369 posts
Re: Writing Python like it's Rust
#192Earlier quoted context omitted.
Python has really poor support for compiled extensions. I know this sounds weird to say, given that they are used everywhere, but this is the number one pain point in Python. It’s really awkward to say, develop on Mac and deploy on Linux.
Might I ask what scripting-like language does have good support for compiled extensions? Such that you can easily develop on Mac and deploy on Linux? Because it seems to me that once you compile something you are in the awkward world of ABI and CPU differences. And binary portability has been a paint point of programmers since before I was born (and I'm not that young). So if there is a programming language that neat…
C# does. It's not exactly a scripting language and authoring a native dependency NuGet package isn't exactly an obvious task, but when you learn how, it's a straighforward solution:
- a NuGet package with native deps (win, linux, osx) cross join (x86, arm) - a P/Invoke package that depends on the native one - actual software that uses the dependency
When you publish the actual software, it pulls the deps and includes the correct native build.
Re: Writing Python like it's Rust
#193Earlier quoted context omitted.
Personally, I switched to Go.
Personally, I switched to Go and soon after to Nim. https://nim-lang.org/ It's great!
Same, I love it! Having done ruby, javascript, python, I'm allowed one niche language (although I really hope it grows in popularity!)
Re: Writing Python like it's Rust
#194The author should really look at Nim.
[deleted]
Re: Writing Python like it's Rust
#195Earlier 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). 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.
Could you elaborate your statement? How? My experience says otherwise. I am interested to know your viewpoint and experience.
Re: Writing Python like it's Rust
#196At 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? Often the answer to this question unfortunately is not a technological merit, but knowledge of a team and willingness to learn. You might want to write actual Rust code and there can be any number of benefit…
Because Python enables faster iterations. By the time you manage to produce a Rust program that even compiles, you can do several edits with tests in Python.
That's only until you've grokked Rust. I find iterating in Rust to be faster than Python.
Re: Writing Python like it's Rust
#197Lots 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…
It could have a better type system and be just as versatile.
Re: Writing Python like it's Rust
#198I like this. I’m a huge fan of types. Even in my silly small programs I find them self documenting of the code I write and it helps me when I come back days later and wonder wtf was I thinking or what am I doing etc.
Re: Writing Python like it's Rust
#199Earlier quoted context omitted.
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 d…
> 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
This is one of my favorite aspects of Python. I can start with every module in prototype form and industrialize each module as its design firms up. I can spend my early development getting an idea fleshed out with minimal overhead.
Re: Writing Python like it's Rust
#200Earlier quoted context omitted.
Some pros: * Go is "simple" (the language has a "small surface area", if you will) * Go has a broad and deep standard library that is generally well-documented * Go comes with a reasonably good general-purpose build tool (it builds, formats code for you, runs tests, etc.) Some cons: * Go's structural subtyping is a pretty terrible approach to handling the problem it's meant to solve. It's not quite as bad as a runtim…
> Go's handling of dependencies...leaves something to be desired Can you give specifics? I think publishing module versions as entire subtrees is very verbose and can be cumbersome but otherwise enjoy everything about Go modules. I find most peoples complaints are that its not like
I don't have a ton of go experience but it seems like there isn't a way to declare tool/binary dependencies that aren't imported anywhere. We ran into this problem for codegen libraries.