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

91–100 of 183 posts

Re: Advanced Python Features

#91

Post by hsbauauvhabzb »

pansa2 wrote: post #60
sakesun wrote: post #54

Earlier quoted context omitted.

It's more complex that decade ago, but still a relatively simple language. I can understand the article without much effort, while I scratch my head really hard when read about advance feature of Typescript or Scala.

> 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 doubt many 4gl language developers could explain what a + b does in their respective language. That rabbit hole goes all the way down to the physical instruction execution on silicon.

Re: Advanced Python Features

#92

Post by maleldil »

TACD wrote: post #68
hiichbindermax wrote: post #37

Nitpick about 9.3 Short Circuit Evaluation: both things evaluate differently if you have empty strings. The if-else clause treats empty strings as valid while the or operator will treat them equivalent with None.

Similarly with 9.2, assignment using a walrus operator will also fail if the value is 0 (or anything falsy: https://docs.python.org/3/library/stdtypes.html#truth-value-... )

You can use `if (response := get_user_input()) is not None` if that's important. IME, empty strings and None would be treated the same way.

Re: Advanced Python Features

#93

Post by tzury »

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 familiar to me, but from other languages.

    response := get_user_input()
I am aware of the factI am in minority, and not trying to change anyone's mind, simply what this voice to be heard from time to time.

All in all, a very comprehensive list of some of the recent introduced features.

There is an older list on SO which readers might also find useful:

https://stackoverflow.com/questions/101268/hidden-features-o...

Re: Advanced Python Features

#94

Post by smjburton »

frde_me wrote: post #84
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…

Couldn't you extend this line of thinking to any language-specific syntax on any programming language? Don't use `match`, macros, lifetimes, ... in rust, someone coming from another language without them might not get what it means. Instead write the equivalent C-looking code and don't take advantage of any rust specific things. Don't use lisp, someone coming from another language might not be able to read it. Etc..…

One of the main objectives of Python is readability. IMO, features that take away from this objective become a detriment to the language.

Re: Advanced Python Features

#95

Post by pansa2 »

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…

> the walrus operator limits the variable's scope to the conditional

Nope! It's still function-scoped.

In Python, walrus or no walrus, the body of a conditional is never a separate scope.

Re: Advanced Python Features

#96

Post by maleldil »

hrtk wrote: post #35

Trying so hard to make it a typed language

Yes, please. Given I'm forced to use Python, I'd welcome any "compile time" tools I can get. These days, it's using pyright with strict mode, which is pretty good, but there's still a long way to go.

Re: Advanced Python Features

#97

Post by nostoc »

zahlman wrote: post #45
TekMol wrote: post #2

TFA's use-case for for/else does not convince me: for server in servers: if server.check_availability(): primary_server = server break else: primary_server = backup_server deploy_application(primary_server) As it is shorter to do this: primary_server = backup_server for server in servers: if server.check_availability(): primary_server = server break deploy_application(primary_server)

This kind of search can be done a variety of different ways, and is worth abstracting, e.g.: def first(candidates, predicate, default): try: return next(c for c in candidates if predicate(c)) except StopIteration: return default deploy_application(first(servers, Server.check_availability, backup_server))

Instead of catching the `StopIteration` exception, you can simply provide a default case to `next` :

    next((c for c in candidates if predicate(c)), default)

Re: Advanced Python Features

#98

Post by pansa2 »

edwardjxli wrote: post #81
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…

In that example I gave, I totally agree with you. One area where I find walrus operators kinda useful is with dealing with iterators. For example, ''' iterable = iter(thing) while val := next(iterable, None): print(val) ''' is a lot cleaner in my opinion compared to ''' iterable = iter(thing) val = next(iterable, None) while val is not None: print(val) val = next(iterable, None) ''' Reason why I did not use this exam…

Yeah, I think the walrus operator is occasionally useful in `while` statements, but that's about it. IMO it wasn't worth the additional language complexity for an operator that's so rarely useful.

Re: Advanced Python Features

#99

Post by d0mine »

William_BB wrote: post #66

I enjoyed reading the article. I'm far from a Python expert, but as an observation, most of these features are actually just typing module features. In particular, I wasn't sold on Generics or Protocols as I would have just used duck typing in both cases... Does modern, production-level python code use types everywhere? Is duck typing frowned upon?

Structural typing is a static equivalent of dynamic duck typing. It is compatible with type checkers. Protocols mentioned in the article work without inheritance. A duck doesn't need to know that there is SupportsQuack protocol. If it quacks, it passes the type checks.

Re: Advanced Python Features

#100

Post by jsjohnst »

toolslive wrote: post #87
jsjohnst wrote: post #62

Earlier quoted context omitted.

So you want strong typing, but then are to lazy to properly type your function definitions?

no need to explicitly write the type if you have type inference: > # fun x -> x + 1;; > - : int -> int = >

1) the code you wrote isn’t Python.

2) inferring the type is int isn’t guaranteed to be correct in this case

Post reply on HN