Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WTFPython – Understanding Python through surprising snippets

github.com

Post reply on HN
Print view View original

71–80 of 199 posts

Re: WTFPython – Understanding Python through surprising snippets

#71

Post by xscott »

fxj wrote: post #55
BiteCode_dev wrote: post #31

It's a good repo, but remember a lot of those are "A Good Thing™". The first snippet is a very good example: a := "wtf_walrus" doesn't work while: (a := "wtf_walrus") works. It's a fantastic design decision. Python took a long time before getting this operator, because it's a language that favors being readable, easy to use, and above all, to learn. But in many other languages, the very same operator is often misused…

in the zen of python (import this) it says: there should be one-- and preferably only one --obvious way to do it. sadly this is not true for a while in python now. Python became a language that can be really hard to read now.

Yeah, current versions of Python feel like Guido and the rest changed their minds about what they wanted.

Re: WTFPython – Understanding Python through surprising snippets

#72

Post by BiteCode_dev »

fxj wrote: post #55
BiteCode_dev wrote: post #31

It's a good repo, but remember a lot of those are "A Good Thing™". The first snippet is a very good example: a := "wtf_walrus" doesn't work while: (a := "wtf_walrus") works. It's a fantastic design decision. Python took a long time before getting this operator, because it's a language that favors being readable, easy to use, and above all, to learn. But in many other languages, the very same operator is often misused…

in the zen of python (import this) it says: there should be one-- and preferably only one --obvious way to do it. sadly this is not true for a while in python now. Python became a language that can be really hard to read now.

> there should be one-- and preferably only one --obvious way to do it.

Yes, this has been one of the hardest balance to find. And believe me when I tell you the community tries very, very hard. But it's a difficult problem: making the language evolves fast enough, but keeping it solid and stable. Very difficult indeed.

> Python became a language that can be really hard to read now.

Not in my experience.

My job involve going a lot from company to company. I see a lot of code, from a lot of different people.

The way people write Python hasn't change much during the last 15 years.

In fact, I'd say because of Python 3, there is less cruft all in all.

You do have a few heavy stuff. E.G: asyncio or the type hints. But how many code out there uses that ? Very little. Mostly, the code that needs it.

Which is good. This is what we want.

Re: WTFPython – Understanding Python through surprising snippets

#73

Post by avip »

masklinn wrote: post #68
avip wrote: post #53

Earlier quoted context omitted.

Does it though? So why doesn't a += b change the object id id(a) ?

As OP noted, given the existence of type(a).__iadd__[0] `a += b` essentially desugars to: `a = a.__iadd__(b)`. list.__iadd__ is (sadly) defined as something like def __iadd__(self, other): self.extend(other) return self So it's possible to have __iadd__ itself succeed modifying the list in place but then the "no-op" reassignment fail. [0] like many data model operations there's really a bunch of fallbacks depending o…

I'd almost consider this a subtle bug? None of the other += operators returns a value.

Re: WTFPython – Understanding Python through surprising snippets

#74

Post by rvanlaar »

Python 3 supports typing. The integration with VSCode is also nice.

The following is valid typed code and my personal favorite WTF:

  def func() -> int:
      return True
Because: https://github.com/satwikkansal/wtfpython/blob/master/README...

I understand the decision that was made in the python 2 era. Nowadays Boolean shouldn't be a subtype of `int`. It goes against the zen of python:

- Explicit is better than implicit.

It actually happened because I was using the new walrus operator (which I like).

  def calc(input: int) -> int:
      return input // 3

  def func(input: int) -> Iterator[int]:
     while input:= calc(input) > 0:
         yield input
*edit: code layout

Re: WTFPython – Understanding Python through surprising snippets

#75

Post by fxj »

NotSammyHagar wrote: post #5

If only it had curly braces instead of just indention. God, that kills me. And used unicode instead of ascii as the default. And there wasn't python 2.7 vs 3. Someone help me stop this list.

With the new walrus operator you dont need indents anymore. You can write everything in one line in an array:

e.g.

  y=0
  for i in range(10):
      x=i+1
      y=y+x*2
can be written as:

  [y:=0] + [[x:=i+1, y:y+x*2] for i in range(10)]
The square brackets are the new curly brackets.

Re: WTFPython – Understanding Python through surprising snippets

#76

Post by bakery2k »

xscott wrote: post #71
fxj wrote: post #55

Earlier quoted context omitted.

in the zen of python (import this) it says: there should be one-- and preferably only one --obvious way to do it. sadly this is not true for a while in python now. Python became a language that can be really hard to read now.

Yeah, current versions of Python feel like Guido and the rest changed their minds about what they wanted.

I think Python’s direction changed when Guido moved to Dropbox. Suddenly he was working on a million-line Python codebase, and started working to make the language more suitable for programming in the large.

Re: WTFPython – Understanding Python through surprising snippets

#77

Post by beagle3 »

jakear wrote: post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

The real WTF here is that you are getting a power output from thee ^ operator, when it actually does xor. Indeed, I've never seen JavaScript mix up operators :)

/s

Re: WTFPython – Understanding Python through surprising snippets

#78

Post by [deleted] »

owl57 wrote: post #69
edflsafoiewq wrote: post #35

Earlier quoted context omitted.

I don't find this at all unexpected. In an imperative language I expect a loop to be implemented by mutating a common variable.

Imperative loop, maybe. But list comprehensions are a sublanguage imported from Haskell and looking like Haskell, so it's somewhat natural to be surprised by mutable variables here.

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#79

Post by jakear »

beagle3 wrote: post #77
jakear wrote: post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

The real WTF here is that you are getting a power output from thee ^ operator, when it actually does xor. Indeed, I've never seen JavaScript mix up operators :) /s

HN isn’t able to render two adjacent asterisk, so I had to make do.

Re: WTFPython – Understanding Python through surprising snippets

#80

Post by xscott »

jakear wrote: post #8

My biggest complaint about Python is that it somehow doesn’t get flak for having the same (if not worse) scoping as JS, which gets endless hate for its function-scoped variables. (So much so that block scoped variables are the new normal in JS, but not in Py!) Take for instance: >>> powers_of_x = [lambda x: x^i for i in range(10)] >>> [f(2) for f in powers_of_x] [512, 512, 512, 512, 512, 512, 512, 512, 512, 512] To m…

Even more fundamental is the nonlocal/global stuff required in order to avoid declaring your variables. Many people are surprised by what this snippet does:

    a = 0
    def f():
        print(a)
        a = 1
    f()
    f()
Post reply on HN