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

Breaking up with Python

cedwards.xyz

Post reply on HN
Print view View original

101–110 of 179 posts

Re: Breaking up with Python

#101

Post by ianandrich »

the_af wrote: post #37

Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go . So that's still my line of…

Too complex for casuals and not powerful enough for power users is a phenomenal way of putting it.

Re: Breaking up with Python

#103

Post by kcartlidge »

beardog wrote: post #8

Don't forget how much of a pain packaging apps for end users is. There are helpful tools out there for it, but nothing that comes close to the ease of Go's default static builds that I have found.

> the ease of Go's default static builds that I have found

Seconded.

These are examples [1] of the scripts that I use on Linux, MacOS, and Windows for producing cross-platform builds. Run the one for the platform you're on, and it will produce stand-alone builds for all the targets (Linux, Windows, MacOS Intel, and MacOS ARM). And the builds are small enough that in many cases for simple tools I commit them straight into the repo for easier usage.

[1] https://github.com/kcartlidge/ng/tree/main/src/scripts

Re: Breaking up with Python

#104

Post by agolio »

nhchris wrote: post #96
agolio wrote: post #18

> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…

> OK sure, it is slower than compiled languages like C++, that is a concession we make when opting for the ease of readability, writability, usability, etc. Does not being compiled really help with readability? How? After all, one can compile python to machine code, and there are C++ interpreters [1] (I have not heard any claims that using it makes C++ more readable). Then there are very readable/usable languages suc…

You are quite right it is not just compilation that sets Python apart from C++, that was a bit of a simplification on my part.

There is also tools such as Cython and numba (JIT) which use various techniques to compile Python code btw. But I am generally in favour of switching to a high performance language or writing in C++ and then importing in Python at that point, personal preference again...

Interesting to read about cling, will have to play around with that.

Re: Breaking up with Python

#105

Post by taylodl »

Sure. If you've done nothing significant with the language then a breakup is easy. Easy come, easy go.

If you've spent years, or even decades, building a portfolio with Python then the breakup is going to be much harder, just like in human relationships. Some things will make sense to leave in Python until end-of-life. Other things will be worthwhile to migrate to Go. Of course your new greenfield projects can start off using Go.

Just know this - you're going to go through this again in another 10-15 years, if not sooner. I've been writing software now for 40 years, that's just the way it goes.

Re: Breaking up with Python

#106

Post by kcartlidge »

Atlas22 wrote: post #98
the_af wrote: post #37

Last time I argued, like the TFA does, that Python's typing system is both too complex for casual users and useless for power users ("it doesn't do anything" is about right), and that this makes it hard to evangelize its use to other devs who aren't sold on type systems ("but this doesn't do anything!"), I got into a 30-level nesting flame war with some HN regular who just wouldn't let go . So that's still my line of…

Yeah, I think I agree with you. I still find it curious that the python language server is quite capable of inferring types from unannotated code yet most of the type checking tools for python seem to explode as soon as they encounter an very popular yet untyped library. I guess typing is more of an afterthought than a priority for most dynamic language developers so it doesn't get much love.

Sounds like an opportunity for a type checker that uses the language server.

Re: Breaking up with Python

#107

Post by samuell »

samuell wrote: post #9
rihegher wrote: post #4

I have just started getting into python as I'm experimenting with pytorch and after a lot of googling I'm still trying to figure out how to use conda properly. Could anyone point me to the best way to manage python environments and packages?

Tried tons of ways, and finally found peace of mind with poetry: https://python-poetry.org/ It encourages to set up project specific definitions which are saved in the local pyproject.toml file. Keeping everything local and project specific, including the env definition, turns out to be a fantastic boon to reproducibility and sanity of mind.

Being able to just cd into a project folder, doing 'poetry shell' (I have it alised to 'psh'), and start developing, is so convenient.

Re: Breaking up with Python

#108

Post by dagw »

devmunchies wrote: post #67
agolio wrote: post #18

> Python’s documentation sucks I can't agree with this. I have always had a very good experience with python documentation. One can use the built-in "help" function which works seamlessly with the docstring feature of the language. The complaint in the blog post seems to refer to the UI of the website missing a table of contents for functions. Yeah sure they could add that but I don't see it as a big point. > Python’…

>> Python’s standard library sucks > I have to disagree again, I think it is pretty well designed and minimal on purpose Oh come on. That’s like saying “this buffet has no food selection but that’s good cause I’m on a diet”. Meaning that you like that it sucks (that’s fine). Numpy is not the kind of thing you would include in the std lib anyway. > OK sure, it is slower than compiled languages like C++, that is a conc…

Numpy is not the kind of thing you would include in the std lib anyway.

If I could add one thing to the python standard library it would be unify the python std lib array and the numpy array and make many of the most common and useful numpy array methods available in the std lib.

Re: Breaking up with Python

#109

Post by ant6n »

agumonkey wrote: post #94
ant6n wrote: post #91

Earlier quoted context omitted.

Yeah. And I don’t want confusing initialisers or constructors or whatchamacallit, and weird calls to super, and underscore methods. Maybe the language should just be minimally aware of classes and how they work, and build that into the semantics of the language using keywords, rather than giving me building blocks that make it feel like I’m rebuilding class semantics from scratch. It’s like when it comes to classes,…

When I first started using python (somewhere before the 2to3 migration) I was extremely pissed at the object layer. I hate redundancy and the dunder and explicit self parameters completely stupid. With time I just got used to them .. (thanks partly to editor templates). The private field shenaningans weren't sexy either.. Other than that I agree.. it would be worth a python4 class Foo(Bar): new(*a, **kw): "keyword: n…

I'd wish there to be simply keywords that define public/private class/instance methods and variables.

Re: Breaking up with Python

#110

Post by emptysongglass »

rihegher wrote: post #4

I have just started getting into python as I'm experimenting with pytorch and after a lot of googling I'm still trying to figure out how to use conda properly. Could anyone point me to the best way to manage python environments and packages?

I was a Poetry user then I discovered the joy of virtual environment-less PDM [1]. It's really easy to import your existing Poetry project in.

[1] https://pdm.fming.dev/latest/usage/pep582/

Post reply on HN