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

191–199 of 199 posts

Re: WTFPython – Understanding Python through surprising snippets

#191

Post by xscott »

Scarblac wrote: post #185
xscott wrote: post #177

Earlier quoted context omitted.

The other three lines are not unrelated. If you just take the first three lies (and the last one), it's fine: a = 0 def f(): print(a) f() Maybe this is all obvious to you, but I'll bet you can't name any other language which behaves this way. Compare the original Python to JavaScript (or Lua, Perl, Tcl, Ruby, C, Scheme, Rust, Clojure, or ...): a = 0 function f() { console.log(a) a = 1 } f() f() This one behaves how I…

Of course I'm not a good judge, I have been programming Python since 1.4 and my colleagues also all have Python experience. But at least I like the idea that it gives an error message when confronted with ambiguity. That way it doesn't do something you didn't expect silently. Sadly it only gives it at runtime, not at compile time.

I'm not sure what your point is about Python 1.4. Maybe it's that you're past the point where these things trip you up.

However, there are plenty of cases where Python won't give an error message too. Make a typo somewhere in the middle of your function, and it'll quietly introduce a new variable instead of letting you know. A rarely used branch of an if-statement could hide this indefinitely. This could also be avoided (or at least mitigated) by requiring variables to be declared explicitly.

Re: WTFPython – Understanding Python through surprising snippets

#192

Post by [deleted] »

jakear wrote: post #100
BiteCode_dev wrote: post #94

Earlier quoted context omitted.

> Why should people only use it when necessary? Because we have experience with things such as easy of learning, cognitive load, writing simple to read code, making it hard to introduce bugs... This comment show how little experience one can have with it, and yet make a quick judgment to offer to "fix" things. E.G: > eel free to use it in all places you’d previously use the assignment operator.”. Simple, easy to unde…

I don’t think you’ve actually understood my proposal, and the snide remarks about completely unrelated languages don’t help your argument. To reiterate, my proposal is that the walrus operator has the exact same semantics as the assignment operator, but creates an expression rather than a statement. A linter rule could then be added prohibits the assignment operator, and converts all instances of it to the walrus ope…

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#193

Post by [deleted] »

dr_zoidberg wrote: post #133
BiteCode_dev wrote: post #105

Earlier quoted context omitted.

> and the snide remarks about completely unrelated languages don’t help your argument. Granted, I apologize. It was childish. > but creates an expression rather than a statement. Expressions are limited in Python for the same reasons. It's the same rational that got us tone done lambdas. People code with a certain style using it, which is not the style we want to promote for Python. > A linter rule could then be adde…

> yet ignore the fact that the actual creator of the language was so against the addition of this operator that he saw the community’s insistence on it as reason to step down as BDFL. Regarding this part, Guido specifically addressed the toxic debate as the reason for stepping down as BDFL, and not the operator per se. (Yes, I'm reinforcing BiteCode_dev's reply on this point)

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#194

Post by ktm5j »

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…

Did you get far past the first example? Because a lot of these seem just plain unacceptable..

How about this from the second example:

  >>> a, b = "wtf!", "wtf!"
  >>> a is b # All versions except 3.7.x
  True
  
  >>> a = "wtf!"; b = "wtf!"
  >>> a is b # This will print True or False depending on where you're invoking it (python shell / ipython / as a script)
  False
Or this from further down

  >>> a = 256
  >>> b = 256
  >>> a is b
  True
  
  >>> a = 257
  >>> b = 257
  >>> a is b
  False

Re: WTFPython – Understanding Python through surprising snippets

#195

Post by michaelcampbell »

nickserv wrote: post #173
michaelcampbell wrote: post #137

Earlier quoted context omitted.

As a relative newcomer to Python (compared to most, but I do use it professionally every working day for a year, and some non-working days for personal stuff), I find this to be the case. At work I have to use Django, and it's almost a chore to find anything explicit or obvious in it. Its level of abstraction is "Too Damn High" as the meme goes, IMO. It feels like saving boilerplate for the sake of it which just make…

This is the danger with high level frameworks, everything is abstracted away, and with a dynamic language like python the black magic can go very deep. If you've ever taken a look at something like Flask or Cherrypi, the difference is very apparent. That said, I've been doing some Rails lately, after years of Django, and I'm finding the experience to be worse from a readability point of view. Metaprogramming everywhe…

Thanks; I've glanced at Flask and it makes a lot more sense to me, but this is a project of immense size and age, and not under my control, so I just have to live with it. Overabstraction for the sake of it seems to be Django's mantra. Then there's Django Rest Framework, and the 3-4 different filtering mechanisms.

It's really a nuisance.

Re: WTFPython – Understanding Python through surprising snippets

#196

Post by kevincox »

ktm5j wrote: post #194
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…

Did you get far past the first example? Because a lot of these seem just plain unacceptable.. How about this from the second example: >>> a, b = "wtf!", "wtf!" >>> a is b # All versions except 3.7.x True >>> a = "wtf!"; b = "wtf!" >>> a is b # This will print True or False depending on where you're invoking it (python shell / ipython / as a script) False Or this from further down >>> a = 256 >>> b = 256 >>> a is b Tr…

I agree. I wonder how confusing it would be to make `is` not allowed on integers or strings. Or define it to be equivalent to `==` for those types. Using `is` in these situations is almost always a big, if for whatever reason you really need it you can do `objectid(x) == objectid(y)` which is usefully explicitly.

Re: WTFPython – Understanding Python through surprising snippets

#197

Post by woogley »

333c wrote: post #151
rvanlaar wrote: post #74

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…

For what it's worth, I like that a bool is an int. It enables concise constructions such as sum(is_true(data) for data in items) to count how many items in an iterable satisfy a condition.

Just for fun, I thought of a way to do this if booleans didn't coerce:

    sum(1 for data in items if is_true(data))

Re: WTFPython – Understanding Python through surprising snippets

#198

Post by NotSammyHagar »

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

1. forget python 2.7 exists 2. can't help with the whitespace, sorry; also take care handling Makefiles

I have worked at places where they insisted on 2 space indention, which made it much much harder to read the code and follow indention levels. It was just stupid of course. That's what really turned me off of python. I know there are bad formatting options for c style languages, and the editor should make it clear. but 2 spaces is too little, too late.

Re: WTFPython – Understanding Python through surprising snippets

#199

Post by NotSammyHagar »

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

Unicode had been the default for 13 years. 2.7 reaches End of Life in less than 2 weeks. And as for curly braces, try typing: python -c "from __future__ import braces" In a terminal :)

That wasn't what I expected. I thought it would say all is well! Funny.
Post reply on HN