Live data from Hacker News

Advanced Python Features

blog.edward-li.com

141–150 of 183 posts

Re: Advanced Python Features

#141

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

> 5. Protocols: As a Typescript guy, this seems very cosy & familiar. And not very Pythonic. I'm not sure how to feel. Isn't it super pythonic? One of the first things you learn about Python is that "everything is duck typed", but then the type system is primarily nominally typed. It seems like Protocols should have been there from the start, like Typescript interfaces.

Maybe you're right.

I'm new to Python & what is or isn't "pythonic" doesn't seem very intuitive to me (beyond just reading PEPs all day) - I guess I'm speaking from using the current type system & the idea of nominal types coexisting with structural seems a little disjointed.

Re: Advanced Python Features

#142
post #138

Earlier quoted context omitted.

Truthiness and falsiness is one of my more used features. ``if not collection`` comes up in nearly every project multiple times.

Yeah, everybody uses it. That's partly how it ends up causing so many bugs - e.g. some user puts 0 in a text box and instead of the program reacting as if you put 0 in it reacts the same way as if no value was supplied. Then everybody loses their minds because the system suddenly started doing something it was never supposed to.

I've never had this behavior cause a bug.

Re: Advanced Python Features

#143

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…

Very good job. I bet most python developers will learn something here. Python has changed a lot; for the better, judging by your examples.

Re: Advanced Python Features

#144
post #57
post #55

Earlier quoted context omitted.

I disagree. Adding "fancy stuff" by definition does not remove what made it attractive to you in the first place. You even acknowledge this in your second sentence. Something you don't know of is not capable to influence your opinion in any way. And when you know of it -- and dislike it -- just keep doing it the way you did before knowing it.

> And when you know of it -- and dislike it -- just keep doing it the way you did before knowing it. That breaks down as soon as you need to work with anyone else's code that uses the "fancy stuff".

[deleted]

Re: Advanced Python Features

#145
post #17

Working in the ML field, I can't hate Python. But the type system (pre-3.12, of course) cost me a lot of nerves. Hoping for a better post-3.12 experience once all libraries are usable in 3.12+. After that experience, I’ve come to truly appreciate TypeScript’s type system. Never thought I’d say that.

[deleted]

Re: Advanced Python Features

#146
My favorite hack is to use a single threaded ThreadPoolExecutor as my main thread. When another thread wants to communicate with it, it just queues the callback function into main using submit. This cleans up the architecture and avoids the use of Queue which is a bit slower.

Re: Advanced Python Features

#147

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.

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

My favourite example of a similar thing happening to me was when I was asked to reverse the digits in a number. I somewhat jokingly asked if I was assuming base 10, which got some awkward looks so I knew something was up. They weren't impressed at all with my answer of `"".join(reversed(str(123456789)))`. I didn't get the job.

Re: Advanced Python Features

#148

Earlier quoted context omitted.

You really should check out pyright/pylance/basedpyright. Just an all around better type checker. Even has the "unknown" from typescript (kinda).

It still has a special case for dataclass-like things. I don't see how Python type checking (I haven't tried Red Knot) could let you do semi-magical things like Zod schema validation from TypeScript.

100%. Python typing is nowhere near as powerful as TS, and the example you gave demonstrates that.

I mentioned pyright because (some of) the specific concerns by OP are addressed by it.

Re: Advanced Python Features

#149
post #138

Earlier quoted context omitted.

Yeah, everybody uses it. That's partly how it ends up causing so many bugs - e.g. some user puts 0 in a text box and instead of the program reacting as if you put 0 in it reacts the same way as if no value was supplied. Then everybody loses their minds because the system suddenly started doing something it was never supposed to.

I've never had this behavior cause a bug.

Keep programming in python long enough and you'll see it eventually. It might be hard to recognize at first.

On the python bug tracker somewhere a while back there was a guy who wrote "if time_variable:" which resolved to false but only when it was called at midnight. It was initally resolved as wontfix.

(midnight being the datetime's conceptual equivalent to empty string, 0, empty list, etc.)

Re: Advanced Python Features

#150

Earlier quoted context omitted.

1) the code you wrote isn’t Python. 2) inferring the type is int isn’t guaranteed to be correct in this case

I was merely giving an example that strong typing has nothing to do with having to write the types. (and, obviously, the inferred type (int -> int) is correct. )

Only if reveal_type only accepts an int. Just because the default value of i is 0 doesn't mean anything about what could be passed in.
Post reply on HN