Live data from Hacker News

I'm switching to Python and actually liking it

cesarsotovalero.net

661–670 of 718 posts

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

#661
post #660
post #458

Earlier quoted context omitted.

I won't touch Python either, but because I've been burned debugging large Python programs. Something that would have taken a minute in a statically typed language took hours of tracing data through the program to understand what was supposed to be in a dict. There are alternative languages that are pithy, statically typed, can write programs quickly, and can grow into large code bases that are maintainable; so there…

I've seen the same thing in .NET and Java where there's 800 layers of interface and impl and it's an adventure trying to find the actual business logic in all the layers of indirection >so there is never a reason to start a new project with Python today Nothing else has an ML/data ecosystem that compares. Perl/Go are maybe a distant 2nd

I deal with that all the time cause an adjacent team uses Java with tons of boilerplate and frameworks. At that point, your static typing isn't so static. Takes them forever to make changes, to the point where I started taking over responsibilities using Python code.

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

#662

Earlier quoted context omitted.

Technically, C or assembly also fulfill this "requirement". There seems to very few smart people who agree with this in practice, however.

Am I missing an obvious joke? C and assembly have no batteries included.

"Here's a chunk of lithium, build your own battery"

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

#663

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.

If your going to execute the code anyway, you either have to inspect everything or trust whoever is providing it. There is nothing special about bash that makes it more dangerous to execute than python.

My issue is with $URL potentially getting hijacked, or even something like the kerfluffle over the PuTTY SSH client not residing at putty.org.

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

#664

> I prefer to use a monorepo structure Worked at a company where that approach lead to huge unwieldy structure that no one dared to touch to not break anything other teams are working on. The problem was not so much the repo, but dependencies structure (like single requirements.txt for the whole repo) and build scripts. In theory it should've worked great -- you only need to update a dependency once and be sure all t…

Sounds more like a monolith. You can do microservices with separate requirements in a monorepo. We have one setup at work using pantsbuild (eh the tool is a bit quirky) but it's much nicer than constantly spinning up new git repos and CI pipelines for small services/utilities

That said, I think service-per-team is a good pattern

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

#665

If you're working on machine learning the most economic choice is Python. But weiting a processing pipeline with Python is frustrating if you have worked with C# concurrency. I figured the best option is Celery and you cannot do it without an external broker. Celery is a mess. I really hate it.

Agree. I think it's improved a bit but Celery is frustrating as the defacto job/queue solution. A lot of the defaults make it unreliable (it can lose jobs if workers crash or don't shutdown cleanly)

I'm hoping the existence of free-threading will push for more first-class concurrency primitives. Concurrent Futures is nice until you need a concurrent-safe data structure besides a queue

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

#666

"And guess what's the de facto programming language for AI? Yep, that sneaky one." Is this referring at all to to PyTorch. If not, any guesses what the author has in mind "Not only because the syntax is more human-friendly, but also because the Python interpreter is natively integrated in all Unix distros." Is this referring to GNU/Linux. UNIX (UNIX-like) includes more than Linux; some UNIX distributions do not inclu…

>I do not use Python for this; I use a 19-line shell script (ash not bash), its startup time is faster

Ash doesn't do web requests unless you've implemented HTTP in ash. You're back to using 3rd party dependencies that aren't installed on all systems

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

#667
post #419

Earlier quoted context omitted.

Maybe you'll find this series of articles interesting: https://www.loopwerk.io/articles/tag/uv/

Thanks! I'm not entirely sure I see a reason to change on there, oddly. I'm very fortunate that my python projects are all relatively small, so maybe that colors things a bit. Certainly looks like something that would have swayed me to uv at the start, but as things are, I think I mainly just wish there was a more standard/accepted work flow for build and release.

Makes sense. I've stopped using python for development but I run into python utilities I want to use all the time. uv/uvx are perfect for someone like me.

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

#668
post #25

Said with a note of surprise? Made me think this is probably normally a Ruby developer indoctrinated against Python. The article doesn’t seem to say what they have come from.

> Ruby developer indoctrinated against Python Ruby devs think about code differently. Like Perl, they embrace TIMTOWTDI. https://perl.fandom.com/wiki/TIMTOWTDI Also, there's a pride in writing elegant code as opposed to following "Pythonic" conventions. Excellence is not conformity. I use Python a lot more often now because it's seen as simpler and more approachable and easier to force compliance. I miss Ruby.

I only Ruby shop I've ever worked at liberally used Rubocop to undo TIMTOWTDI. I suppose you could _write_ whatever you wanted but Rubocop would pretty aggressively rewrite it.

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

#669

If you're working on machine learning the most economic choice is Python. But weiting a processing pipeline with Python is frustrating if you have worked with C# concurrency. I figured the best option is Celery and you cannot do it without an external broker. Celery is a mess. I really hate it.

Agree that celery is a mess and it doesn't work well with async (Asyncio) python. I think version 6 maybe will support it sometime.

I also had a lot of problem due to async primitives with sqlalchemy - there's some tricky stuff with asyncio.gather vs TaskGroup and how sqlalchemy session works with it to be able to compose code easily.

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

#670
post #509
post #46

I'm glad someone else discovered they can like python. I got forced to learn it for a project where I was proposing Ruby and the customer insisted on Python. This was years ago when Ruby was much slower. I was annoyed but I got used to it and here I am enjoying it many years later. I take issue with the description and use of make though! :-D What is the point of it if you're not going to use dependencies? One might…

Ruby's syntax is much nicer. I just can't stand the idea of using whitespace for scope delimiting.

I love it, so much more concise and clean without the brace noise.
Post reply on HN