Live data from Hacker News

I'm switching to Python and actually liking it

cesarsotovalero.net

61–70 of 718 posts

Re: I'm switching to Python and actually liking it

#61

> Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros That's kind of very optimistic evaluation - literally anything beyond "import json" will likely lead you into the abyss of virtual envs. Running something created with say Python 3.13.x on Ubuntu 22.04 or even 24.04 (LTSs) / Rocky 9 and the whole can of worms opened. things like vir…

this is solved by uv

Re: I'm switching to Python and actually liking it

#62
post #40
post #11

Earlier quoted context omitted.

Python's package management is OK. The main culprit is .so libraries Think JNI or cgo management.

Yes, I've never really understood the complaint about python packaging - building native code is not something that is ever easy to guarantee across multiple distributions and operating systems. Those native packages can be in any language and require any odd combination of tools to build. Who has truly solved that problem?

wheels, conda, docker, firecracker, unikernel, flatpak

Re: I'm switching to Python and actually liking it

#64
post #5

> Python has done a good job of hiding its legacy ugliness (such as __init__, __new__, and similar aberrations), swettening its syntax to accomodate developers with good taste. What exactly is the problem with __init__ or __new__? @dataclass is very nice syntactic sugar, but are we arguing here that having access to initializer/allocator/constructor dunder methods is "legacy ugliness"? This is the core of pythonic bu…

Bizarre is that you don’t consider it ugly. Kotlin: constructor is either part of class definition or keyword constructor. Ruby: initialize JS: constructor Python: ______new______, _______init_______ Literally this meme: https://knowyourmeme.com/memes/three-headed-dragon

I have found to believe that ugly and beautiful are irrelevant. As long as it's doing the job and not cause major headaches. Life is too short to worry about syntax.

Re: I'm switching to Python and actually liking it

#65

Python has done an impressive job over the years of making steady robust improvements. The typing and tooling has just gotten better and better. There are still plenty of problems though, imho async is still a much bigger pain than it should be (compared to other runtimes with a very nice experience like go or elixir, even dotnet has been less pain in my experience). Overall I like python, but it mainly boils down to…

I don't know what I am doing wrong but nothing written in Python has ever worked for me. I download the .py repo from from github or wherever and try to run it - errors. I try to install missing libraries pip this and that - errors. I battle fixing endless error with dependencies and when the .py finally runs - errors - wrong version of whatever library or wrong patch of this or that or the "production ready" .py does not work correctly on Windows or single file script uses excel library that has changed in incompatible ways 3 times in 2 years. I Download all the files from the flashy looking web site and follow all the instructions to the letter - errors. Python is anything but "robust". It is the most fragile environment in the universe, worse than c, c++ and javascript put togeter, at least this is my experience with it.

Re: I'm switching to Python and actually liking it

#66

> Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros That's kind of very optimistic evaluation - literally anything beyond "import json" will likely lead you into the abyss of virtual envs. Running something created with say Python 3.13.x on Ubuntu 22.04 or even 24.04 (LTSs) / Rocky 9 and the whole can of worms opened. things like vir…

this is solved by uv

> things like virtual envs

I consider my point as still valid with UV, what you wanted to express?

On UV specifically - say 'asdf' compiles python right on your system from official sources - means using your ssl libs for example. UV brings Python binary - I feel worried on this.

Re: I'm switching to Python and actually liking it

#67

Earlier quoted context omitted.

Bizarre is that you don’t consider it ugly. Kotlin: constructor is either part of class definition or keyword constructor. Ruby: initialize JS: constructor Python: ______new______, _______init_______ Literally this meme: https://knowyourmeme.com/memes/three-headed-dragon

I like that magic method names generally all follow the same form so it's obvious that they are magic methods and not intended to be part of the public API. Whether that form uses double underscores or something else doesn't really matter to me as they are not being called directly.

Would you consider a constructor magic though?

Re: I'm switching to Python and actually liking it

#68
post #40

Earlier quoted context omitted.

Yes, I've never really understood the complaint about python packaging - building native code is not something that is ever easy to guarantee across multiple distributions and operating systems. Those native packages can be in any language and require any odd combination of tools to build. Who has truly solved that problem?

wheels, conda, docker, firecracker, unikernel, flatpak

flatpak, docker ? i.e. include an almost complete distribution just to make one package work? but what if you want that package to work in the distribution you have now? What if you need 2 different packages that are in different flatpacks or different docker images?

Re: I'm switching to Python and actually liking it

#69
I've avoided Python for a long time, but I'm getting roped in myself, mainly because certain tasks seem to require a lot less code than Java or Perl.

That said, call me old-fashioned, but I really take issue with "curl $URL | bash" as an installation method. If you're going to use an install script, inspect it first.

Re: I'm switching to Python and actually liking it

#70
post #67

Earlier quoted context omitted.

I like that magic method names generally all follow the same form so it's obvious that they are magic methods and not intended to be part of the public API. Whether that form uses double underscores or something else doesn't really matter to me as they are not being called directly.

Would you consider a constructor magic though?

"Magic methods" is just the name people use for these special methods (another is dunder methods). They're "magic" because you do not call them by name, rather they are invoked by the interpreter in specific situations.
Post reply on HN