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

61–70 of 183 posts

Re: Advanced Python Features

#61

Post by pydry »

robviren wrote: post #52

Every time I try to use Python I get this mixed feeling of liking how few guard rails there are between me and the logic I am making and this lingering worry that my code looks like fools attempt to use Python. So much exists as convention or loosely followed rules. Whenever I read articles like this I am wowed by the depth of things I didn't know about Python or how much has changed. It makes something like Go feel…

There are plenty of language features which let you re-use or build your own guardrails in python.

I do with the concept of truthiness and falsiness would be taken out and shot though. It's been responsible for far too many nasty bugs IME and it only cuts out a few extra characters. Not a great trade off.

Re: Advanced Python Features

#62

Post by jsjohnst »

hk__2 wrote: post #27
drumnerd wrote: post #22

Earlier quoted context omitted.

0 can be inferred as a float too, so doesn’t it make sense to type numbers?

Try: def f(i=0) -> None: reveal_type(i) The inferred type is not `float` nor `int`, but `Any`. Mypy will happily let you call `f("some string")`.

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

Re: Advanced Python Features

#63

Post by paolosimone »

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)

If the team is familiar with Functional Programming concepts, I'd actually suggest

  available_servers = (server for server in servers if server.check_availability())
  primary_server = next(available_servers, backup_server)
  deploy_application(primary_server)
which IMHO better conveys the intent to the reader (i.e. focus on "what to do" over "how to do it")

Re: Advanced Python Features

#64

Post by mzl »

hk__2 wrote: post #27
drumnerd wrote: post #22

Earlier quoted context omitted.

0 can be inferred as a float too, so doesn’t it make sense to type numbers?

Try: def f(i=0) -> None: reveal_type(i) The inferred type is not `float` nor `int`, but `Any`. Mypy will happily let you call `f("some string")`.

How would a typing system know if the right type is `int` or `Optional[int]` or `Union[int, str]` or something else? The only right thing is to type the argument as `Any` in the absence of a type declaration.

Re: Advanced Python Features

#65

Post by lenkite »

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.

Just like Microsoft maintains the Typescript handbook, I think the Python Foundation needs a "Idiomatic Modern Python Handbook" which always shows the most modern and idiomatic way to use Python features.

Re: Advanced Python Features

#66

Post by William_BB »

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?

Re: Advanced Python Features

#67

Post by brookst »

pydry wrote: post #61
robviren wrote: post #52

Every time I try to use Python I get this mixed feeling of liking how few guard rails there are between me and the logic I am making and this lingering worry that my code looks like fools attempt to use Python. So much exists as convention or loosely followed rules. Whenever I read articles like this I am wowed by the depth of things I didn't know about Python or how much has changed. It makes something like Go feel…

There are plenty of language features which let you re-use or build your own guardrails in python. I do with the concept of truthiness and falsiness would be taken out and shot though. It's been responsible for far too many nasty bugs IME and it only cuts out a few extra characters. Not a great trade off.

+1 — and it only saves characters when someone really knows what they’re doing. Most of is end up with `if (not result) or (result == “”)` and worse.

Re: Advanced Python Features

#68

Post by TACD »

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

Re: Advanced Python Features

#69

Post by djoldman »

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

Re: Advanced Python Features

#70

Post by rfoo »

hk__2 wrote: post #27
drumnerd wrote: post #22

Earlier quoted context omitted.

0 can be inferred as a float too, so doesn’t it make sense to type numbers?

Try: def f(i=0) -> None: reveal_type(i) The inferred type is not `float` nor `int`, but `Any`. Mypy will happily let you call `f("some string")`.

`Any` is the correct call.

It could be:

  def f(i=0) -> None:
    if i is None:
      do_something()
    else:
      do_something_else()
Yeah, I know it's retarded. I don't expect high quality code in a code base missing type annotation like that. Assuming `i` is `int` or `float` just makes incrementally adoption of a type checker harder.
Post reply on HN