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

151–160 of 199 posts

Re: WTFPython – Understanding Python through surprising snippets

#151

Post by 333c »

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.

Re: WTFPython – Understanding Python through surprising snippets

#152

Post by masklinn »

_y5hn wrote: post #136
masklinn wrote: post #122

Earlier quoted context omitted.

It's not "python late binding", closures behave this way in any language with mutable bindings[0]. The entire point of a closure is to close over its lexical context, if the lexical context is mutable and mutated before the invocation of the closure, the closure is going to reflect that change. for(var i=0; i x^i); } will behave the same way because it does the same thing, so will e.g. for i := 0; i in Go. One of the…

Works intuitively in golang: https://play.golang.org/p/pn2jBTaTNS8 package main import ( "fmt" ) // return a^n func Power(a, n int) int { var i, result int result = 1 for i = 0; i

I provided a Go example demonstrating that it does not. Your version

1. uses a slice of integers which completely misses the point

2. uses an IIFE which completely misses the point

The point is to look at what happens when you close over the iteration variable.

Re: WTFPython – Understanding Python through surprising snippets

#153

Post by masklinn »

gpderetta wrote: post #130
masklinn wrote: post #122

Earlier quoted context omitted.

It's not "python late binding", closures behave this way in any language with mutable bindings[0]. The entire point of a closure is to close over its lexical context, if the lexical context is mutable and mutated before the invocation of the closure, the closure is going to reflect that change. for(var i=0; i x^i); } will behave the same way because it does the same thing, so will e.g. for i := 0; i in Go. One of the…

C++: std::vector > powers_of_x; for (int i = 0; i works as one would intuitively expect (a different i is captured for each iteration). The issue is with those languages that conflate values with references.

…

> excluding the special case of low-level languages with capture clauses

Of course it works, you're specifically capturing `i` by value. It's not exactly surprising that doing things completely differently yields a different result.

Re: WTFPython – Understanding Python through surprising snippets

#154

Post by phlakaton »

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…

A contrarian's point of view:

> The very same operator is often misused as, or confused for, the operator for equality or assignation.

It will still be confused, I'm afraid. It's just a little less likely that that confusion will be silently accepted by the interpreter.

> Also to hint people at using it only when necessary.

Let's be clear: the walrus operator was never, ever, necessary. It's syntactic sugar to avoid extra lines of code. The hope is that it will be convenient and obvious enough that folks will prefer it to both extra lines of code and repeated sub-expressions, but the very advice that beginners ought to "ignore the existence of := for some time" (_plus_ the intentional deviation from other languages) suggests that this is not going to be nearly as obvious or convenient as its proponents might have wished.

Re: WTFPython – Understanding Python through surprising snippets

#156

Post by ezzzzz »

kraf wrote: post #4

Maybe "beautifully designed" is a bit much then In my experience Python is not very nice to work with. I do like the ecosystem for data science though, it's just amazing how much there is. Hopefully the language will grow into something better now that the dictator stepped down.

Yeah, I'm relatively new to Python as a JVM dev, but am finding myself (accidentally) in the realm of Data Science/Engineering and am looking to Python as opposed to Scala simply due to better Libraries. I do like that Python is really easy to be productive in, but the challenges of scale I guess will be learned as our team gains experience.

Re: WTFPython – Understanding Python through surprising snippets

#157

Post by doteka »

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

The many, many ways to print variables inside of a string are testament to that. I remember feeling kind of a chill when the number of methods hit three. Two is an acceptable number of methods if you are transitioning from one form to another as kind of a nod to the growing pains of a language, but at three you have hit some kind of watershed.

There's actually five now!

1. manual string concatenation 2. the old, printf-style. Still heavily used in e.g. stdlib logging module. 3. .format() 4. f-strings 5. string.Template in the stdlib

Yup, I definitely see this as one of the bigger failures in Python's design.

Re: WTFPython – Understanding Python through surprising snippets

#158

Post by joshuamorton »

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

As others mentioned, using lambdas this has been possible for ages. There's even a too to auto convert pre walrus code to a single line.

It's just that no one does it.

Re: WTFPython – Understanding Python through surprising snippets

#159

Post by gpderetta »

masklinn wrote: post #153
gpderetta wrote: post #130

Earlier quoted context omitted.

C++: std::vector > powers_of_x; for (int i = 0; i works as one would intuitively expect (a different i is captured for each iteration). The issue is with those languages that conflate values with references.

… > excluding the special case of low-level languages with capture clauses Of course it works, you're specifically capturing `i` by value. It's not exactly surprising that doing things completely differently yields a different result.

To be fair I missed the note at the end of your commend on my first read. Still, in the specific C++ example, no other capture clause is valid.

Also, python could have chosen a slightly different closure semantics and preserved sanity: instead of closing over the binding itself, it could close over each object reference separately (exactly in the same way the default parameter hack works).

Re: WTFPython – Understanding Python through surprising snippets

#160

Post by b0rsuk »

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…

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

It's less of a problem in Python because it has built-in module support. A global variable is only global in the module, unless you import it with "from foo import *", which lazy programmers do but is discouraged by style guides.

Post reply on HN