Live data from Hacker News

WTF Python: Exploring and understanding Python through surprising snippets

github.com

141–150 of 169 posts

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

#141
post #137

Earlier quoted context omitted.

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 nice…

> we have better fonts, and screen proportions have changed.

I have two 24" 1920x1200 monitors which I develop with. Just three or four years ago I and most of my coworkers didn't even have that.

When I open VS Code in full screen using the default font size and two editors split vertically on my 24" monitor, I can fit 90 characters per line before I have to start scrolling horizontally. If I hide the side bar, I can fit 110 characters per line. If I reduce the font size to one which is barely tolerable, I can fit 114 characters per line with the side bar. I can finally fit a full 135 characters per line if I hide the side bar with the tiny font size.

If I snap VS Code to one half of my monitor with the default font and one editor and the side bar open, I can barely fit 80 characters per line. If I close the side bar, I can fit 110 characters per line.

If I open a JetBrains IDE using the default font size, no side bar, and two editors split vertically, I can fit 107 characters per line before I have to scroll. If I do a full screen side-by-side diff with the IDE, I can fit 108 characters per line on each side.

If I open a side-by-side diff in Bitbucket in a full screen browser at the default zoom level, I can fit about 85 characters per line on each side with the side bar open. If I collapse the side bar, I can fit about 108 characters per line on each side.

Of the environments I work in every day, the only ones which support 120 characters per line with comfortable font sizes and without consuming more than half the screen are Beyond Compare and Vim. Most of them don't even support 100 characters per line without making compromises and none of them support 160 characters per line.

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

#143
post #12

I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…

My theory is you didn't read past the couple of pages. There is some very interesting material in there that was news to me and I've been doing Python fairly intensively for the last fifteen years.

Edge cases are really interesting. It's important to know them, and it's no comment on the language.

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

#144

Earlier quoted context omitted.

> I'm glad it's becoming kind of ok to criticise that language, after years of it being untouchable I've only been following Python for a little over 20 years of it's ~30 year life, but I don't remember it ever being “untouchable”, or even just “untouched” by criticism.

Up until mid-2000s, no one had heard of Python. Then there was maybe ten years of “Whitespace? No!” But from say 2012 on there was a big movement of data science and education into Python and its general reputation was quite good. Edit: the XKCD antigravity comic was December 2007, so pretty early on all things considered. PG’s Python Paradox was 2004.

> But from say 2012 on there was a big movement of data science and education into Python and its general reputation was quite good.

When Python became popular in education, particularly for first CS courses, is when the public criticism from Scheme, Java, and and C partisans really skyrocketed.

Yeah, it has had recently a generally good reputation. That doesn't mean that it has been untouchable and immune to criticism.

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

#145
post #47

Earlier quoted context omitted.

There are some that you can find in [0], but they are often de-contextualized (and sometimes aren't really Python's problem, because there was a trade off that had to be made, and the LOL is just frustration as a result of the bad ergonomics that it creates), those and some others will eventually go in an longer post when I finally get that set up. To give one concrete example of an LOL PYTHON consider the @property…

If I understand correctly, I think the problem with your second example is that you should avoid checking for `True` with something like `if isFile` but instead `if isFile is True`. That would solve this specific problem (and is also slightly more efficient because no implicit boolean conversion is performed).

This one is a bit more subtle. Assume there are two classes on that uses @property and one that does not.

    class Here:
        @property
        def booleanPredicate(self):
            return random_bool()


    class There:
        def anotherBooleanPredicate(self):
            return random_bool()
    
    here = Here()
    there = There()
What happens in the following cases?

    here.booleanPredicate           # as expected
    here.booleanPredicate()         # loud failure
    here.anotherBooleanPredicate    # silently always True
    here.anotherBooleanPredicate()  # as expected
So you might think that you should _always_ use @property for boolean predicates, except that there are libraries that use the anotherBooleanPredicate version so you are now at risk for silent always True behavior (creeping sanity destroying evil behavior). To prevent the silent failure you should always start by calling the predicate so that it can fail loudly. Worse if someone does a refactor and misses going from @property form to function form then the silent failure literally cannot be detected by running the program (!).

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

#146
post #140

Earlier quoted context omitted.

> 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.

> if you genuinely think that then you can never achieve anything other than complaining on message boards and hodling US treasury bonds.

I mean... yes. That's, like, most people.

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

#147
post #12

I feel like WTFs caused by doing something deeply weird hardly counts against the language. Yes doing the walrus operator inside brackets works. Yes of course it's going to be doing weird things. Is this really surprising to anyone? It's not what that operator is for . Yes comparing strings with "is" works sometimes . It's not checking equality and it isn't supposed to. In another implementation using "is" might work…

I don't understand these comments suggesting this article is anti-python. I won't say it is the opposite. But the repo is literally stating the goal is to "Exploring and understanding Python through surprising snippets.". And I totally agree that analysing and trying to understand what is actually going on, when the language is behaving in a slightly unexpected way, is a great way to learn. So see this as a resource for people who want to learn, not for people with an “anti-python sentiment” (whatever that even means).

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

#148
post #3

Earlier quoted context omitted.

That one was all cynicism that baited the experienced and confused and discouraged beginners... this one actually takes the important next step of making it all teachable which is really great.

Oh no, someone was being funny! Think of the beginners, they can't deal with that! The wat talk is funny and educational. I watched it with just a couple of weeks of experience in JavaScript, and I learned a lot from it. There are other great resources (the good parts, the you don't know js series, etc), but none of them offer value so quickly . The wat talk is a great reminder to learn more about the language you ar…

Oh no, more sarcasm. If only I was in on the joke /s

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

#149
post #3

Earlier quoted context omitted.

That one was all cynicism that baited the experienced and confused and discouraged beginners... this one actually takes the important next step of making it all teachable which is really great.

Oh come on Gary literally runs a top notch teaching site and the link was a bit of fun on his previous teaching site.

Well he also started a spread of snark that made the entire industry look bad. His own site is called destroy all software. Even if that is meant to be ironic, even that irony isn't helpful.

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

#150
post #137

Earlier quoted context omitted.

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 nice…

Human brains are the same or worse (smaller) for 100_000 years or more.

What do you think is easier to read: one long line or the same text in columns with a suitable width? What do you think this width would be? The optimal width may depend on the language e.g., I'd use >1.5x for Java, to get the same information density per line as in Python.

Your eyes/working memory don't scale with the width of your monitor.

Post reply on HN