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

61–70 of 199 posts

Re: WTFPython – Understanding Python through surprising snippets

#61

Post by [deleted] »

masklinn wrote: post #54
jakear wrote: post #38

Earlier quoted context omitted.

Interesting, I don’t use python day-to-day, so I had assumed that the delayed capturing of the iteration variable was a lambda thing. Looks like this is still broken: for i in range(10): def mul(x): return i^x powers_of_x.append(mul) That to me coming from a JS background is totally wild

Why would it be "totally wild" coming from a JS background when the corresponding JS code: for(var i=0; i i^x); } behaves the exact same way for the same reason? By definition, a closures closes over its definition context, it doesn't capture the values at definition time but instead keeps referring to said definition context. If the definition context is mutable and modified, the closure reflects that change when it…

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#62

Post by CallocRoast »

aidos wrote: post #57
tyri_kai_psomi wrote: post #50

Earlier quoted context omitted.

Unfortunately, this is not true. Although the equality operators are a favorite bikeshedding topic, the largest source of errors in JS code bases are type errors. Using a "non-sane" equality check, such as those with type coercion would actually mask or alleviate these source of bugs you mention.

I was thinking more of the case where the types match but objects and arrays with the same contents are considered different. I’ve watched every member of my team get stung by it again and again - and then have to create workarounds to get past it.

I don’t agree and this behavior shouldn’t be surprising. The alternative would be to walk the container and compare the value of each element, which could be horrible.

Re: WTFPython – Understanding Python through surprising snippets

#63

Post by masklinn »

bakery2k wrote: post #48
Luyt wrote: post #45

Earlier quoted context omitted.

A while ago, I was also sceptical about the walrus operator, although I use assignments in expressions all the time in C++. But when I was perusing a library written Python the other day, I found five spots in which the walrus operator would make sense - eliminating one line of source code without readability suffering from it.

Is saving 5 lines of code really worth breaking Python's "one way to do it" design principle?

Python's principle is not an has never been "one way to do it". Python's principle is:

> There should be one — and preferably only one — obvious way to do it.

Which is a very, very different assertion. And there remains one — and exactly only one — obvious way to do an assignment, because the walrus operator is literally invalid syntax as a statement:

    >>> [a:=1]
    [1]
    >>> a:=1
      File "", line 1
        a:=1
         ^
    SyntaxError: invalid syntax

Re: WTFPython – Understanding Python through surprising snippets

#65

Post by XuMiao »

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

I've coded in python for >10 years and C# for ~half of that. I prefer indentation-based control flow purely because it condenses code vertically and creates consistent indentation with actual purpose (many of the devs on C# projects I've dealt with have had inconsistent tab/space settings and no linting). If anything, the one thing I hate about Python3 is dynamic typing - inferring datatypes in function bodies is gre…

Python does have a lot of problems, but it's so far the most flexible language like English.

High level programming language is meant to communicate, not to dictate the computation. Python happens to be easy to understand by humans.

Re: WTFPython – Understanding Python through surprising snippets

#66

Post by [deleted] »

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

Second this. I can’t understand finding Python beautiful or even elegant. It just took a hodgepodge of features from languages like Haskell and C++, and repackaged them clumsily. It’s good for writing short scripts and throw-away code, but it shouldn’t be used as a serious programming language.

[deleted]

Re: WTFPython – Understanding Python through surprising snippets

#67

Post by CallocRoast »

bakery2k wrote: post #48
Luyt wrote: post #45

Earlier quoted context omitted.

A while ago, I was also sceptical about the walrus operator, although I use assignments in expressions all the time in C++. But when I was perusing a library written Python the other day, I found five spots in which the walrus operator would make sense - eliminating one line of source code without readability suffering from it.

Is saving 5 lines of code really worth breaking Python's "one way to do it" design principle?

That principle was bullshit anyway. There have always been multiple ways to do things, the one way was just whatever the elder Pythonista deemed to be pythonic that day.

Re: WTFPython – Understanding Python through surprising snippets

#68

Post by masklinn »

avip wrote: post #53
bakery2k wrote: post #39

Earlier quoted context omitted.

`a += b` does something along the lines of `a = a.__iadd__(b)`. Here `__iadd__` performs the actual append, but then the assignment fails.

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 on what is and is not implemented

Re: WTFPython – Understanding Python through surprising snippets

#69

Post by owl57 »

edflsafoiewq wrote: post #35
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…

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.

Re: WTFPython – Understanding Python through surprising snippets

#70

Post by jwilk »

the_mitsuhiko wrote: post #23
heinrich5991 wrote: post #14

Earlier quoted context omitted.

UTF-8 is the current default.

It uses unicode but it doesn’t use UTF-8 by default as external encoding and never as internal encoding except for an optional secondary buffer.

What do you mean by "external encoding", "internal encoding", "secondary buffer"?
Post reply on HN