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

601–610 of 718 posts

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

#601

Post by t43562 »

shmerl wrote: post #509
t43562 wrote: 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 thought that too....but I did get over it.

I ended up feeling that it removes a lot of (internal) debate about what's the best style for braces that you get in C-like languages.

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

#602

Post by IshKebab »

stana wrote: post #541
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…

Or API_KEY = os.environ.get("YOUTUBE_API_KEY") CHANNEL_ID = os.environ.get("YOUTUBE_CHANNEL_ID") assert(API_KEY, "Missing YOUTUBE_API_KEY") assert(CHANNEL_ID, "Missing CHANNEL_ID")

Assertions are disabled via `python -O` so they probably shouldn't be used like this.

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

#603

Post by shmerl »

t43562 wrote: post #601
shmerl wrote: post #509

Earlier quoted context omitted.

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

I thought that too....but I did get over it. I ended up feeling that it removes a lot of (internal) debate about what's the best style for braces that you get in C-like languages.

It's just weird. May be if you are used to it, it doesn't bother you, but I find it too easy to do something wrong with scope.

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

#604

Post by IshKebab »

geysersam wrote: post #428
CoolCold wrote: post #55

> 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…

Just use uv

I agree - Python without uv is masochistic. But that really negates the "Python is already available" advantage. If you have to install uv you can just as easily install Rust or Go or Deno.

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

#605

Post by shmerl »

pzo wrote: post #595
shmerl wrote: post #509

Earlier quoted context omitted.

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

I wish python had support for optional braces. Maybe time I copy some snippet or integrate some other project into mine and have to worry if someone using 2 spaces, 4 spaces or tabs.

Yeah, but they seem to think it's a feature, not a hindrance. I don't really understand the idea.

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

#606

Post by IshKebab »

nikolayasdf123 wrote: post #599

YAML, Python, Make... — only I see issues and a pattern with this choice of toolset?

They occupy a space where things work most of the time but jank and footguns are a way of life. That seems to be where most people live unfortunately.

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

#607

Post by librasteve »

MyOutfitIsVague wrote: post #430
nomel wrote: post #319

Earlier quoted context omitted.

Oddly enough, "except" variables don't remain bound! try: x = int('cat') except Exception as e: pass print(e) # So, it appears Python actually has three variable scopes (global, local, exception block)?

Nope, it's more complicated than that: e = 'before' try: x = int('cat') except Exception as e: e2 = e print(e) print(e2) # It's not a scoping thing, the bound exception variable is actually deleted after the exception block, even if it was already bound before!

lol - raku maybe weird, but at least it has sane variable scoping

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

#609

Post by globular-toast »

gvalkov wrote: post #136
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…

This is nitpicking, but this is a good usecase for the := operator: if not (API_KEY := os.getenv("API_KEY")): ... For internal tools I just let os.environ["API_KEY"] raise a KeyError. It's descriptive enough.

Why are people writing Python like it's Go?

Letting the KeyError go is usually fine, but if you want to log it or can recover somehow then:

    try:
      API_KEY = os.environ["API_KEY"]
    except KeyError:
      logger.exception("...")
      ...

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

#610

Post by suspended_state »

nomel wrote: post #590
suspended_state wrote: post #404

Earlier quoted context omitted.

> Oddly enough It's not that odd, since it's the only situation where you cannot keep it bounded, unless you enjoy having variables that may or may not be defined (Heisenberg variable?), depending on whether the exception has been raised or not? Compare with the if statement, where the variable in the expression being tested will necessarily be defined.

Are you saying that this should result in a name error? if : x = 5 print(x) #

I stand corrected, the exception case is definitely an oddity, both as being an outlier and as a strange behaviour wrt Python's semantics. Or is it a strange behaviour?

In the case of an if like in your example, no provision is made about the existence of x. It could have been defined earlier, and this line would simply update its value.

Your example:

   if True:
       x = 5
   print(x)  # 5
Same with x defined prior:

   x = 1
   if False:
       x = 5
   print(x)  # 1
What about this one?

   if False:
       x = 5
   print(x)  # ???
On the other hand, the notation " as " looks like it introduces a new name; what if that name already existed before? Should it just replace the content of the variable? Why the "as" keyword then? Why not something like "except = " or the walrus operator?

While investigating this question, I tried the following:

    x = 3
    try:
        raise Exception()
    except Exception as x:
        pass
    print(x)  #
Post reply on HN