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

Advanced Python Features

blog.edward-li.com

Post reply on HN
Print view View original

101–110 of 183 posts

Re: Advanced Python Features

#101

Post by smjburton »

maleldil wrote: post #83
smjburton wrote: post #78

Some of these newer features don't seem like improvements to the language (e.g. the Walrus operator): ''' # ===== Don't write this ===== response = get_user_input() if response: print('You pressed:', response) else: print('You pressed nothing') # ===== Write this instead ===== if response := get_user_input(): print('You pressed:', response) else: print('You pressed nothing') ''' The first implementation is immediatel…

I disagree. First of all, it takes a minute to search "python :=", and the construct itself is pretty simple. It's been part of the language since 2018[0]. I don't think "not knowing the language" is a good reason to avoid it. Second, the walrus operator limits the variable's scope to the conditional, which can reduce certain bugs. It also makes some scenarios (like if/elif chains) clearer. I recommend checking out t…

That's exactly my point. Having to search for the meaning of the operator at all makes the code less readable. I recommend reading the Zen of Python, which covers the design principles of the language.

Re: Advanced Python Features

#102

Post by jay-barronville »

edwardjxli wrote: post #77

Hey yall! Original author of the blog here! I did not expect to wake up at 4am seeing my post on front page HN, but here we are nevertheless :D As the intro mentioned, these started off as 14 small tweets I wrote a month prior to starting my blog. When I finally got that set up, I just thought, "hey, I just spent the better part of two weeks writing these nifty Python tricks, might as well reuse them as a fun first p…

I appreciate you writing the post and I enjoyed reading it.

Congratulations for ending up on the front page! (I hope the server hosting your blog is okay!)

Re: Advanced Python Features

#103

Post by marvy »

cl3misch wrote: post #71
pansa2 wrote: post #60

Earlier quoted context omitted.

> still a relatively simple language If only. I suspect very few Python programmers can even fully explain what `a + b` does. If `a` and `b` are instances of classes, many would say it's equivalent to `a.__add__(b)` or `type(a).__add__(a, b)`, but in fact it's much more complex.

Care to elaborate? Where is the complexity hidden?

the full story is in the language reference, but the short answer is: __radd__ (unless it's more complicated than I realize)

Re: Advanced Python Features

#104

Post by pansa2 »

skobes wrote: post #82
pansa2 wrote: post #60

Earlier quoted context omitted.

> still a relatively simple language If only. I suspect very few Python programmers can even fully explain what `a + b` does. If `a` and `b` are instances of classes, many would say it's equivalent to `a.__add__(b)` or `type(a).__add__(a, b)`, but in fact it's much more complex.

I once broke some Python by changing a = a + b to a += b. If a and b are lists, the latter modifies the existing list (which may be referenced elsewhere) instead of creating a new one. I think Python is the only language I've encountered that uses the + operator with mutable reference semantics like this. It seems like a poor design choice.

This is one of the absolute worst design mistakes in Python. The example you give (that `a = a + b` and `a += b` aren't equivalent) is bad enough:

    >>> a = b = [1, 2, 3]                >>> a = b = [1, 2, 3]
    >>> a = a + [4]                      >>> a += [4]
    >>> a, b                             >>> a, b
    ([1, 2, 3, 4], [1, 2, 3])            ([1, 2, 3, 4], [1, 2, 3, 4])
What's worse is that sometimes, they are equivalent:

    >>> a = b = (1, 2, 3)                >>> a = b = (1, 2, 3)
    >>> a = a + (4,)                     >>> a += (4,)
    >>> a, b                             >>> a, b
    ((1, 2, 3, 4), (1, 2, 3))            ((1, 2, 3, 4), (1, 2, 3))
And even worse, in order to support a version of `a += b` that sometimes modifies `a` (e.g. with lists), and sometimes doesn't (with tuples), the implementation of the `+=` operator is convoluted, which can lead to:

    >>> t = ([1, 2, 3], ['a'])
    >>> t[0] += [4]
    TypeError: 'tuple' object does not support item assignment
    >>> t
    ([1, 2, 3, 4], ['a'])
The operation raises a TypeError, despite having succeeded!

Re: Advanced Python Features

#106

Post by sgarland »

smjburton wrote: post #101
maleldil wrote: post #83

Earlier quoted context omitted.

I disagree. First of all, it takes a minute to search "python :=", and the construct itself is pretty simple. It's been part of the language since 2018[0]. I don't think "not knowing the language" is a good reason to avoid it. Second, the walrus operator limits the variable's scope to the conditional, which can reduce certain bugs. It also makes some scenarios (like if/elif chains) clearer. I recommend checking out t…

That's exactly my point. Having to search for the meaning of the operator at all makes the code less readable. I recommend reading the Zen of Python, which covers the design principles of the language.

I don’t write code to the level of someone who has just finished Hello, World. This isn’t something esoteric, it’s an extremely basic and useful part of the language. I’ve seen this argument used against multiple languages, and it has never made sense to me.

“I don’t want to use windowing functions in SQL, because most people don’t know what they are.” So you’d rather give up an incredibly powerful part of your RDBMS, and dramatically increase the amount of bandwidth consumed by your DB?

It’s as if the industry is embracing people who don’t want to read docs.

Re: Advanced Python Features

#107

Post by mckirk »

lordgrenville wrote: post #72
djoldman wrote: post #69

This is wild and something I didn't know about: https://blog.edward-li.com/tech/advanced-python-features/#2-... def bar(a, /, b): ... # == ALLOWED == bar(1, 2) # All positional bar(1, b=2) # Half positional, half keyword # == NOT ALLOWED == bar(a=1, b=2) # Cannot use keyword for positional-only parameter

And you can use * for the reverse (every parameter from here on needs to be keyword-only). https://docs.python.org/3.12/reference/compound_stmts.html#f...

That feature I'm using regularly and can recommend doing so, e.g. when passing boolean flags to functions, to clarify their meaning at the call-site by ensuring they have to be passed by name.

Re: Advanced Python Features

#108

Post by edwardjxli »

tzury wrote: post #93

My own opinion is that Python shall remain Python, and golang, Rust and Typescript each should be whichever they are with their unique philosophy and design. I am coding in all 4, with some roughly 28 years now, and I don't like what is becoming of Python There is a reason why python become that popular and widely adapted and used, and it is not the extra layers of type checking, annotations and the likes. this looks…

Extra stuff like type checking and annotations are definitely not the reason why python became that popular and widely adapted and used, but it certainly doesn't hurt to add and use them.

To be clear, I'm not expecting people to start adding generics to their quick hacked together Python scripts (in fact please don't do that). Instead, if you're building a library or maintaining a larger Python codebase, a lot of these start becoming very useful. A lot of the typing features I mentioned are already used by Python under the hood, and that a lot of Python developers just take for granted.

Case in point, the python-opencv (https://github.com/opencv/opencv-python) library has basically no types and it's an absolute pain to work with.

BTW thats a really good SO thread, thanks for linking it!

Re: Advanced Python Features

#109

Post by stitched2gethr »

> @overload is a decorator from Python’s typing module that lets you define multiple signatures for the same function.

I'll be honest, I've never understood this language feature (it exists in several languages). Can someone honestly help me understand? When is a function with many potential signatures more clear than just having separate function names?

Re: Advanced Python Features

#110

Post by d0mine »

cl3misch wrote: post #71
pansa2 wrote: post #60

Earlier quoted context omitted.

> still a relatively simple language If only. I suspect very few Python programmers can even fully explain what `a + b` does. If `a` and `b` are instances of classes, many would say it's equivalent to `a.__add__(b)` or `type(a).__add__(a, b)`, but in fact it's much more complex.

Care to elaborate? Where is the complexity hidden?

1. operators use special lookup for dunder methods--on class, not on instance:

    >>> a+1 # lookup on class 
    1+1
    2 
    >>> a.__add__(1) # instance method 
    0
2. There is __radd__ that is called if __add__ doesn't support given types (for different types).
Post reply on HN