Live data from Hacker News

Advanced Python Features

blog.edward-li.com

111–120 of 183 posts

Re: Advanced Python Features

#111

> @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?

I would recommend reading the article example once more. Going from the example, without the overload, the function would return a union type which means any time you use the function, you have to put a type check to the result to know if the output is a list or not. With overload, as soon as an argument to the function is a certain type, the output is determined, so you won't need to type check.

Re: Advanced Python Features

#112

> @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?

In other languages it's an alternate way to do default or optional values in function arguments. Python instead usually uses kwargs for this.

Re: Advanced Python Features

#113

Earlier quoted context omitted.

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…

Isn't this equivalent to just `for val in thing`?

If `thing` already supports iteration, then yes, but sometimes you need to build your own [0].

[0]: https://docs.python.org/3/library/functions.html#iter

Re: Advanced Python Features

#114

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…

The tricks are more advanced than what I've seen in most people's code at some jobs before! The post is refreshing because it sits in the neglected middle ground between the tons of Python-for-beginners content out there and the arcane "I'm a core developer writing about very specific things" content.

Re: Advanced Python Features

#115

> @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?

That's what you get when you add a typing system and come full circle to doing OOP like Java.

Re: Advanced Python Features

#116
post #103

Earlier quoted context omitted.

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)

Yes, the next level of complexity is that `a + b` will sometimes fall back to `b.__radd__(a)` if `a.__add__(b)` returns `NotImplemented`. But also:

- There are situations where `__radd__` takes priority over `__add__`. The rules for determining that priority are complex (and IIRC subtly different from the rules that determine whether `a - The lookup of `__add__` etc uses a special form of attribute lookup that's neither equivalent to `a.__add__` nor `type(a).__add__`. This special lookup only searches `type(a)` whereas the first would find an `__add__` function on `a`, and the second on `type(type(a))`.

I've also heard of further complications caused by implementation details leaking into the language semantics - for example, see Armin Ronacher's blog post: https://lucumr.pocoo.org/2014/8/16/the-python-i-would-like-t...

Re: Advanced Python Features

#117

The way the language is evolving, it seems likely to me that people in the applications camp (ML, simple web-dev, etc.) will soon need a "simple Python" fork or at least an agreed-upon subset of the language that doesn't have most of these complications (f-strings are a major success, though).

Nothing stops you from simply not using features, and even having CI checks that forbid them. Not sure why you’d need a fork.

Re: Advanced Python Features

#118

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…

You can get code formatting by indenting with 2 spaces: https://news.ycombinator.com/formatdoc

Re: Advanced Python Features

#119
As someone coming from Javascript/Typescript & now working full time in Python, this is a lovely - mostly fantastically useful - little resource. Some choice observations:

1. Typing overloads: TS has typed overloads I think largely as an affordance to an unfortunate feature of Javascript. In my experience overloads are an anti-pattern or at best code smell. It's nice that you can type them if you're cleaning up an existing codebase that uses them but I would consider them tech debt.

2. Keyword-only and Positional-only Arguments: This is the opposite of the 1st feature (ability to make method signatures more strict) but man is the syntax cryptically terse. I'd love to use this everywhere but I'd be concerned about readability.

3. Future Annotations: Thank you for this section - forward references have been a real pain for me recently & this is the first explanation that's scratches the service of the "why" (rather than just focusing on case-by-case solutions), which is much more helpful. Bring on PEP 649.

4. Generics: Cries in legacy 3.10 codebase

5. Protocols: As a Typescript guy, this seems very cosy & familiar. And not very Pythonic. I'm not sure how to feel.

14. Metaclasses:

> if you are that 1% which has a unique enough problem that only metaclasses can solve, they are a powerful tool that lets you tinker with the internals of the Python object system.

OR if you're one of the many devs that believes their problem is unique & special & loves to apply magical overengineered solutions to simple common problems, then the next person who inherits your code is going to really love your metaclasses. They sure make tracing codepaths fun.

Re: Advanced Python Features

#120

This is a nice list of "things you might not know" that is worth skimming to add to your toolkit. If you are really interested in "advanced Python", though, I would recommend the book Fluent Python by Ramalho. I have the first edition which is still highly relevant, including the async bits (you just have to translate the coroutines into async syntax). There is a second edition which is more up to date. I would also…

+1 to itertools especially. Absurdly powerful, and the recipes at the bottom of the doc page are terrific.

The only problem I’ve found is that for interviews, people often aren’t familiar with it, which can lead to you solving whatever puzzle they had in far less time than they intended, and without manually building whatever logic it was they assumed you would need.

Post reply on HN