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

I'm switching to Python and actually liking it

cesarsotovalero.net

Post reply on HN
Print view View original

461–470 of 718 posts

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

#461

Post by callc »

rsyring wrote: post #416
callc wrote: post #391

Earlier quoted context omitted.

Hi rsyring, I made this comment out of experience. As python projects grow and grow, you need to do lots of support work for testing and even syntactic correctness. This is automatic in compiled languages where a class of issues is caught early as compile errors, not runtime errors. Personally I prefer to move more errors to compile time as much as possible. Dynamic languages are really powerful in what you can do at…

All perfectly valid perspectives and I agree with most of what you wrote. But the comment above is pretty different from the tone/effort behind the comment I took issue with. :) In hindsight, I should have just left it alone and not replied which is what I usually do. But Python's popularity isn't an aberration. It's tradeoffs make sense for a lot of people and projects. The low effort bad faith swipes at it from sub…

Thanks for your comment. I definitely could have worded mine better too with a bit more effort and context.

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

#462

Post by bobsmooth »

0xbadcafebee wrote: post #358

Maybe I'm the only one that finds Python simultaneously verbose and lacking? Either you need 500 dependencies to do something in a simple way, or you need dozens (if not hundreds) of lines to do trivial things. I avoid writing Python because there's so much bullshit to add. Much prefer Perl, I can actually get things done quickly. Python feels like programming for the sake of programming.

The best part about python is that there's a library for everything.

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

#463

Post by delusional »

cristoperb wrote: post #454
Mawr wrote: post #80

Just a small note on the code in the linked script: API_KEY = os.environ.get("YOUTUBE_API_KEY") CHANNEL_ID = os.environ.get("YOUTUBE_CHANNEL_ID") if not API_KEY or not CHANNEL_ID: print("Missing YOUTUBE_API_KEY or YOUTUBE_CHANNEL_ID.") exit(1) Presenting the user with "Missing X OR Y" when there's no reason that OR has to be there massively frustrates the user for the near zero benefit of having one fewer if statemen…

Even slightly better is to first check both if not API_KEY and not CHANNEL_ID: print("Missing both YOUTUBE_API_KEY and YOUTUBE_CHANNEL_ID.") exit(1) if not API_KEY: print("Missing YOUTUBE_API_KEY.") exit(1) if not CHANNEL_ID: print("Missing YOUTUBE_CHANNEL_ID.") exit(1) That way you don't end up fixing one just come back and be told you're also missing another requirement

Even better would be to only check each once and buffer the decision:

    valid = True
    if not API_KEY:
        print("Missing YOUTUBE_API_KEY.")
        valid = False
    if not CHANNEL_ID:
        print("Missing YOUTUBE_CHANNEL_ID.")
        valid = False
    if not valid:
        exit(1)
This way you only check each value once (because your logic might be more complicated than just checking it's not set, maybe it can be wrongly formatted) and you still get to do whatever logic you want. It also removed the combinatorial problems.

This is a pretty general principle of separating decision from action.

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

#464

Post by antod »

wasabi991011 wrote: post #278
kemayo wrote: post #132

Earlier quoted context omitted.

Funnily enough, just starting your class method/variable name with __ does do magic things as a pseudo-keyword. Specifically, it mangles the name for callers outside of that class -- `self.__foo` would need to be accessed as `obj._ClassName__foo`. It's python's approach to having private methods, while remaining somewhat ideologically opposed to them existing. This doesn't apply to the dunder methods, though. They're…

What's the use case for __foo -> _ClassName__foo? I've used python a bunch but never this feature, so I'm curious.

It's as close as they'll get to private methods while still having the "we're all consenting adults" philosophy that doesn't prevent you doing something dumb. Or if you use this and it breaks, you can't say you weren't warned.

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

#466

Post by sevensor »

MintPaw wrote: post #363
ActorNightly wrote: post #308

Earlier quoted context omitted.

No and no. I don't know how you even get to this level of "making it harder for yourself". Say you want to use a specific version of python that is not available on Ubuntu. 1. Install build dependencies https://devguide.python.org/getting-started/setup-building/#... 2. Download whichever Python source version you want, https://www.python.org/downloads/source/ . Extract it with tar 3. run ./configure --enable-optimiza…

> making it harder for yourself Looking at just the first link, looks way more complicated than venv. And I'm a C++ developer, imagine someone who less experienced, or even who just isn't familiar with C toolchains.

It’s really not hard; the person you’re replying to put a lot of details in. I’ve lost track of how many times I’ve built a Python interpreter. Virtual envs used to work badly with some tools and dependencies, so I had to do it a lot. It’s gotten better and now I only compile Python to get a version that’s not provided by my Linux distribution.

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

#467

Post by kstrauser »

underdeserver wrote: post #445
bognition wrote: post #438

I’m on board with most of this. The one suggestion I’d add is to replace “make” with “just”

I hear about it every now and again and I can't seem to grok the benefit. What's the killer feature over make?

First, I grok make. I'm saying this from a position of familiarity, not of ignorance and fear.

Make is great at compiling code in languages that don't have bespoke build systems. If you want to compile a bunch of C, awesome. For building a Rust or JavaScript project, no way. Those have better tooling of their own.

So for the last 15 years or so, I've used make as a task runner (like "make test" shelling out to "cargo test", or "make build" calling "cargo build", etc.). As a task runner... it kinda sucks. Of course it's perfectly capable of running anything a shell script can run, but it was designed for compiling large software projects and has a lot of implicit structure around doing that.

Just doesn't try to be a build system. It's optimized for running tasks. Here, that means it provides a whole lot of convenient functions for path manipulation and other common scripty things. It also adds dozens of quality-of-life features that devs might not even realize they wanted.

For example, consider this trivial justfile:

  # Delete old docs
  clean:
      rm -rf public

  # This takes arguments
  hello name:
      @echo Hello, {{name}}
If you're in a directory with it and run `just --list`, it'll show you the list of targets in that file:

  $ just --list
  Available recipes:
      clean      # Delete old docs
      hello name # This takes arguments
That second recipe takes a required command line argument:

  $ just hello
  error: Recipe `hello` got 0 arguments but takes 1
  usage:
      just hello name

  $ just hello underdeserver
  Hello, underdeserver
You can do these things in make! I've seen it! Just doesn't add things that were impossible before. But I guarantee you it's a lot harder to implement them in make than it is in just, where they're happy native features.

There are a zillion little niceties like this. Just doesn't try to do everything make does. It just concentrates on the smaller subset of things you'd put in .PHONY targets, and makes them really, really ergonomic to use.

You wouldn't use just to replace make in a large, complicated build. I would unhesitatingly recommend it for wrapping common targets in repos of newer languages, so that `just clean build test` does the same things whether you're in Python or TS or Rust or whatever, and you don't want to hack around all of make's quirks just to build a few simple entry points.

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

#468

Post by bjourne »

RadiozRadioz wrote: post #432
bjourne wrote: post #405

Earlier quoted context omitted.

Neophytes take notice. Attention to details like this is what separates truly great programmers from merely good ones. That said, for scripts reusable by others you should use command line arguments . Environment variables in lieu of command line arguments is a huge code smell.

For this example, don't just command line arguments. There's an API key there, you don't want an API key visible in your cmdline.

Then how would you SET the API key in the first place? :) The argument doesn't make any sense at all.

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

#469

Post by antod »

stevesimmons wrote: post #92
tgv wrote: post #73

Earlier quoted context omitted.

Python's success is entirely due to entry-level programming courses. They all switched to Python, because you have to explain less. I don't think I heard about web servers in Python before 2012. I suppose a 2005 computer wouldn't be able to serve a Python backend smoothly. PHP's popularity isn't really from 2005-2006. It was popular at the end of the 90s, and it looks like JS as much as it looks like a potato.

> I suppose a 2005 computer wouldn't be able to serve a Python backend smoothly. Python had web servers from 2000, including Jim Fulton's Zope (really a full framework for a content management system) and in 2002 Remi Delon's CherryPy. Both were useful for their day, well supported by web hosting companies, and certainly very lightweight compared to commercial Java systems that typically needed beefy Sun Solaris serv…

I'd forgotten about CherryPy until Turbogears was mentioned the other day in the Django birthday thread.

But yeah Python was on an upswing for webdev and sysadmin (early DevOps?) tooling, but took quite a hit with Ruby eg Rails, Puppet, Vagrant and Chef etc.

But Python hung on and had a comeback due to data science tooling, and Ruby losing it's hype to node for webdev and golang for the devops stuff.

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

#470

Post by taeric »

maleldil wrote: post #450
taeric wrote: post #285

Earlier quoted context omitted.

I have been sticking with poetry for a while, now. What would make me want/need to move to uv?

- Performance: uv is so much faster that some operations become transparent. poetry's dependency resolver is notoriously slow. uv being a native binary also means it has a faster startup time. - Interpreter version management: uv can handle separate python versions per project automatically. No need for pyenv/asdf/mise. - Bootstrapping: you only need the uv binary, and it can handle any python installation, so you do…

I'll pay attention to poetry soon. As is, I don't recall my builds ever going slow because of poetry. I don't think I've noticed it have any impact on speed, at all.

I did just update the dependencies of some of my projects. I could see how that could be faster. I don't do that often enough for me to care about it, though. `poetry run pytest` is the slowest thing I have, and I'm confident most of that slowness is in my direct control already.

I'm intrigued on the lock file point. I thought that was literally one of the main reasons to use something like poetry, in the first place? Does uv have a better lock file mechanism?

Post reply on HN