Live data from Hacker News

WTF Python: Exploring and understanding Python through surprising snippets

github.com

131–140 of 169 posts

Re: WTF Python: Exploring and understanding Python through surprising snippets

#131

Earlier quoted context omitted.

They're also an escape hatch, def main(): funcs = [] for x in range(10) def f(x=x): return x funcs.append(f) print([f(x) for f in funcs]) The "x=x" default argument is necessary here. In this example it's just a constant but this trick is often used with mutable defaults.

You're talking about something different. The parent comment is about mutable default arguments are shared between all calls to that function [1], but you seem to be talking about functions defined in for loops all sharing a reference to the same variable [2]. [1] https://github.com/satwikkansal/wtfpython#-beware-of-default... [2] https://github.com/satwikkansal/wtfpython#-loop-variables-le... > In this example it's…

These are two manifestations of the same feature: function arguments's default values are evaluated when the function is defined.

In one case, the value is a non-mutable int, while in the other it's a mutable list, but in both cases each call to those functions will share the same value for that argument (unless overriden).

Re: WTF Python: Exploring and understanding Python through surprising snippets

#132
post #107

Earlier quoted context omitted.

> I've been seeing a growing anti-python sentiment lately Not speaking for the quality of the article, but on that sentiment: maybe it's just that the pro-python sentiment is eroding. I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable (at its core, not the 2 -> 3 migration). At least that's my sentiment as someone who really doesn't like it (but I'm a professional, I sti…

You lost me at: “I prefer JS (modern) to Python”. Just... how?

As someone who's not a fan of JS in the browser, https://github.com/denoland/deno is _shockingly_ nice for "script-sized" tasks that need more performance than bash+jq makes easy.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#133
post #97

Earlier quoted context omitted.

Why that exception?

None, True, False are singletons and are never constructed again after initilization of the interpreter (and have been keywords in python2). That's why "is" is always safe. Small integers, as they are kept around, probably are as well (5 is (2+3) works). I think what gets dropped during the conversation is, that we've been living with Java doing it this way (is being == and == being .equals) for decades and nobody re…

[deleted]

Re: WTF Python: Exploring and understanding Python through surprising snippets

#134
post #25

Earlier quoted context omitted.

I agree with most of your points, because in most cases, people try something very weird, and they are surprised that the result is something even weirder (or they just didn't think through the example logically). Except the string comparison with "is". It's confusing, because there are no errors, and when I try them in the Python REPL, it "works". The code is logical, I tested the example and it works... ...except w…

The confusion there is caused by english not disambiguating between equality and being-the-exact-same-thing-ness. I'll grant that "is" is a bit of a footgun for new users, but it's not a WTF in the sense that the language is doing something weird. Rule of thumb is use == for everything except True/False/None. Once you get going with python you'll learn the meaning of is eventually, and you'll still barely ever need t…

Noob question: instead of using == except for True/False/None, what about just using == for all comparisons?

Re: WTF Python: Exploring and understanding Python through surprising snippets

#135
post #130
post #125

Earlier quoted context omitted.

> "Hard to scale" isn't really a coherent argument against any mainstream programming language. It is odd that you would say that, because it is a very common complaint about languages with dynamic typing. As the program grows larger static typechecking becomes more and more helpful.

That is one of the many interpretations of "not scalable" I suppose... Regardless, python has tools to do that. Instagram and Dropbox in particular have written quite a lot about their internal usage and built and open sourced additional tooling (e.g. MonkeyType - that lets your code type annotate itself).

Fact that they had to do that does prove the point, doesn't it?

How about organizations that hit the scaling point, but are not big enough to invest into tooling like that?

Re: WTF Python: Exploring and understanding Python through surprising snippets

#136
post #130

Earlier quoted context omitted.

That is one of the many interpretations of "not scalable" I suppose... Regardless, python has tools to do that. Instagram and Dropbox in particular have written quite a lot about their internal usage and built and open sourced additional tooling (e.g. MonkeyType - that lets your code type annotate itself).

Fact that they had to do that does prove the point, doesn't it? How about organizations that hit the scaling point, but are not big enough to invest into tooling like that?

No. MonkeyType is open source.

It's exactly the kind of tooling that makes your life easier if you have multiple teams and wanted to start enforcing static type checks with MyPy and having an IDE that understood your types.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#137

Earlier quoted context omitted.

Line length isn't a python issue. A line length of 80, is. (Thus the punch card reference). My stint in python made me appreciate A line length more, but 80 got to be absurd.

What does a line length of 80 have to do with punch cards? My understanding is that 80 was originally chosen because that was the standard number of columns on a terminal. It has been continued to be used because it happens to be roughly just under half the width of a typical 16:9 or 16:10 monitor at normal font sizes, making it ideal for window snapping and side-by-side diffs. I have to review code in other language…

It's actually 79 chars.

> the standard number of columns on a terminal

are inherited from punched cards.

https://stackoverflow.com/a/4651037/257493

But in 2021 I can resize my TTY Emulator, we have better fonts, and screen proportions have changed.

A column length of 80 is in the ancestral DNA of computers because it was the number that packed nicely onto a sheet of paper. That paper was that size because it fit nicely into a paper portfolio and filing cabinet. The portfolio was that size because it was a reasonably big-enough sheet to adjust the paper cutter to.

80 has nothing to do with humans reading code. It's all post-hoc justifications and fairy tales. The whole thing is a 200 year old legacy system bug.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#138

Earlier quoted context omitted.

To take one of your complaints: > Why do my lines of code need to fit on a punched card invented decades before the language was invented? Keeping lines short helps keep information density high, allows you to fit more views of the code on screen without wrapping, and encourages use of intermediary variables to keep complexity per line low. This isn't a Python issue. Any decent style guide will have a maximum line le…

Line length isn't a python issue. A line length of 80, is. (Thus the punch card reference). My stint in python made me appreciate A line length more, but 80 got to be absurd.

PEP8 (the generally-used Python style guide for any non-Python people reading along) defaults to 79 characters, with an option to increase it to 99.

Personally I'm fine with either option, but I think lines much longer than 99 characters start to get pretty awkward. If you really do need longer lines than that occasionally you can mark an exception for whatever style checker you're using.

Re: WTF Python: Exploring and understanding Python through surprising snippets

#139
post #136

Earlier quoted context omitted.

Fact that they had to do that does prove the point, doesn't it? How about organizations that hit the scaling point, but are not big enough to invest into tooling like that?

No. MonkeyType is open source. It's exactly the kind of tooling that makes your life easier if you have multiple teams and wanted to start enforcing static type checks with MyPy and having an IDE that understood your types.

So before it was open sourced, all those companies that couldn't pull it off themselves had scaling problems or not?

So before Python had types was it hard to scale or not?

Seems like you are defending "Python with types and lots of tooling" rather than Python "nice and simple language (until not)".

Re: WTF Python: Exploring and understanding Python through surprising snippets

#140
post #87

Earlier quoted context omitted.

Critiquing X, or even warning people about surprises in X, is not "anti-X". Have people picked up this weird idea from fandom culture or something? This article is not saying that people should not use python. It's not criticizing the maintainers for making stupid decisions, as far as I can see. It's just saying "if you do this, you'll get a surprising result", and in the process teaching people more about how it act…

> I've written a lot of C in the subsequent 20 years or so. It has some particularly nasty traps. Acknowledging that does not make me anti-C. depends on your cultural background I guess. Some people see literally everything that is not 100% risk-free as inherently bad.

Well, possibly, but if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds. Everything has risks and it's a question of enumerating them and deciding how and whether to manage them.
Post reply on HN