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

121–130 of 183 posts

Re: Advanced Python Features

#121

Post by pdabbadabba »

klankeser wrote: post #111
stitched2gethr wrote: post #109

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

I think that GP's point is that you could accomplish the same thing by simply having separate functions with different names, signatures, and return types.

Re: Advanced Python Features

#122

Post by pjmlp »

krelian wrote: post #42

Python has evolved into quite a complex language considering the amount of features that come built-in. The documentation, while complete, does not facilitate discovery of many of those features.

Python has always been quite complex, people get deceived by how simple Hello World looks in Python.

Using it since version 1.6.

Re: Advanced Python Features

#123

Post by mdaniel »

mcdeltat wrote: post #86

Good article! I found the typing bits particularly interesting. This part of the language has been evolving rapidly recently, which is cool if you like static typing. Although I think the example of type alises in section 4 is not quite right. NewType creates a new "subtype" which is not equivalent to the original type. That's different to TypeAlias, which simply assigns a name to an existing type. Hence NewType is s…

> which is cool if you like static typing.

I don't believe any reasonable person would call Python statically typed, it just now has a pathway though which one can send additional documentation, with all of its caveats

  python3.13 -c '
  foo: dict[str, list] = "lol"
  print(foo.keys())
  '
And, yes, I am aware of the chorus of "just sprinkler more linters"

Re: Advanced Python Features

#124

Post by phailhaus »

lucideer wrote: post #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 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.

Re: Advanced Python Features

#125

Post by pjmlp »

hsbauauvhabzb wrote: post #91
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 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.

Meanwhile some 3GL language developers, think they can explain.

Re: Advanced Python Features

#127

Post by ryandv »

stitched2gethr wrote: post #109

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

It's an implementation of "ad-hoc polymorphism", where, for example, it may make sense to "add" (+) together numbers of various types: integers, floating points, rational numbers, etc.

Thus the (+) operator for addition is "overridden" or "polymorphic" in the types of numbers that can be added together.

The argument for having a polymorphic signature rather than just multiple separate "monomorphic" functions is similar to that for "generics," otherwise known as "parametric polymorphism": why not just have a function `forEachInt` for iterating over lists of ints, a separate function `forEachChar` for iterating over lists of characters, and so on?

Higher levels of abstraction and generality, less boilerplate and coupling to any particular choice of data structure or implementation.

You could of course go the route of golang which indeed just had you write "monomorphized" versions of everything. Several years later generics were added to the language.

Alternatively, you throw everything out and never have to worry about typing or polymorphism, at the cost of static safety.

Re: Advanced Python Features

#128

Post by abirch »

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…

I love Guido's balance. You don't need type checking and annotations if you don't want to use them. They are nice when you're playing in more complex systems, however, completely optional.

Re: Advanced Python Features

#129

Post by mjr00 »

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…

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

Python got popular and widely adopted for the same reason PHP did: 1) it was readily available everywhere and 2) it's an easy language for beginners to pick up and get real applications working quickly.

But it turns out that the language features desirable for a quick prototype done by your fresh-out-of-college founding engineer aren't the same as the language features desirable for your team of 100 engineers trying to work together on the same codebase.

Python is at an odd intersection where it's used by everything from large teams building robust backend applications (particularly in the data/ML space), to data scientists hacking on scripts interactively in Jupyter, to ops people writing deployment scripts. You don't need type checking and annotations if you're writing a few one-off scripts, but you'd be crazy to not take advantage of them for a larger application.

Re: Advanced Python Features

#130

Post by quotemstr »

davidatbu wrote: post #40
hk__2 wrote: post #18

Earlier quoted context omitted.

Same experience here, Python’s typing experience is awful compared to TypeScript, even post-3.12. Mypy’s type inference is so dumb you have to write arguments like `i: int = 0`; `TypedDict`s seems promisable at first and then end up as a nightmare where you have to `cast` everything. I miss TypeScript’s `unknown` as well.

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.
Post reply on HN