Hacker News Reader

Comment by CivBase | Hacker News Reader

Python is a very intuitive and easy-to-read language for experienced programmers, but I wouldn't consider it a "beginner-friendly" one. It's packed to the brim with features that are hard for beginners to understand without first coming to grips with a more simple language. Those features are extremely useful for experienced programmers who want to get stuff out the door quickly and easily, but they're overwhelming for novices. Most experienced developers I work with produce what I would consider to be pretty bad Python code - not because they are bad developers but because they haven't had enough experience with Python to understand everything it comes with out-of-the-box.

View on HN

I literally just finished a leetcode problem[1] to practice some python. I found two solutions, one seems more "pythonic" to me and the other seems more clear though also more verbose.

Clear/Verbose -

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        x_coords = sorted(x for x, _ in points)
        greatest_diff_so_far = 0

        for i in range(len(x_coords)-1):
            diff = x_coords[i+1] - x_coords[i]

            if diff > greatest_diff_so_far:
                greatest_diff_so_far = diff

        return greatest_diff_so_far

Pythonic -

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        xs = sorted(x for x, _ in points)
        return max(x2-x1 for x1, x2 in zip(xs, xs[1:]))

I'm curious which approach is bad/worse? On the one hand, the "pythonic" approach seems brief and kind of neat and I feel clever writing it. On the other hand, it is also ~20% slower per my testing, it's less obvious what it's doing, and it would be harder to make some change to the logic (or add logging/metrics) without completely rewriting it.

On the one hand, just from the reasons I wrote above, it seems to me like the first way is better and the second worse, but on the other hand, the first way is what I would write while knowing zero python features. Curious if anyone else has thoughts on this.

1 - https://leetcode.com/problems/widest-vertical-area-between-t...

A super common solution to the problem of too many ideas packed into a clever solution is just naming intermediate things. For example, naming the zip(...) is a little change that goes pretty far in making the second one more obvious:

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        xs = sorted(x for x, _ in points)
        neighboring_coordinates = zip(xs, xs[1:]))
        return max(right-left for left, right in neighboring_coordinates)

or even naming the width generator:

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        xs = sorted(x for x, _ in points)
        neighboring_coordinates = zip(xs, xs[1:]))
        widths = (right-left for left, right in neighboring_coordinates)
        return max(widths)

Same thing, just with more built in explanation. It's easy to go overboard, of course, but it's a useful go-to to make stuff more obvious.

Whitespace helps too! And I think using `sorted(key=)` is more Pythonic than a generator expression ;)

   from operator import itemgetter

   def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
       xs = sorted(points, key=itemgetter(0))
       x_pairs = zip(xs, xs[1:])

       widths = (right-left for left, right in x_pairs)

       return max(widths)

NumPy also has stuff to solve this sort of thing built-in:

   from numpy import diff

   def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
       xs = sorted(points, key=itemgetter(0))
       widths = diff(xs)

       return widths.max()

For the last bunch of years, wherever my instinct says to add white space, I instead put a comment. If you want something to be a visually separate entity, it’s the perfect place to put a couple words about that entity, and it still gets the visual separation in an editor with any syntax highlighting at all.

> And I think using `sorted(key=)` is more Pythonic than a generator expression ;)

But it doesn't do the same thing. The original code extracted the xs from the coordinate pairs, sorted; your code sorts the coordinate pairs by their x values, but doesn't extract the xs from them.

Oops! Good point! Unfortunately too late for me to edit.

Clever has its applications and its drawbacks. First off, you may not feel very clever when you need to read the code you wrote (no caffeine, or a hangover, or an incipient cold ...), or perhaps the next coder to pick up your code is not as clever.

I save clever for the real mechanics of problems, for data structures, and occasionally optimization of running time if that is a factor (it often is not as much as you would think).

I eschew clever if it seems like it is just a way to pack a lot of stuff into fewer lines of code. One of the reasons that Perl attained a reputation of "write once, read never" unmaintainable code (whether or not it was justified) is a culture that cultivates "one-liners" and packing everything down into a minimum space. Our filenames in Windows no longer have to be 8.3. We are not constrained to write our code in a few kilobytes.

I programmed in the days where you might have two kilobytes in which to program. In those days, extreme terseness was a value. It is not any longer. "Cat" and "man" and "mv" are holdovers from those days. This is not a telegram where you are charged by the word. I program for total obviousness and sometimes that makes my code seem "dumb." I might do only one or two things per line. That's really fine.

Just as an example, I wrote this obnoxious web app in Perl as part of my job. At some point, some students were to take it over, but they didn't know Perl. I received an excited phone call from them at some point: they were able to understand and port my application to a language they were familiar with because I commented, I was not clever in packing, and I kept it to "one or two things per line."

To be fair, cat, man and mv are things you type many times per day when working in a unixy environment.

Interesting, I'm using this [0] to test and got different results. The Pythonic function is 2% slower on 3.9.1 AMD 4900HS but 17% faster on 3.9.1 E5-2660 v2 VPS and 6% faster on 3.6.9 i5-3570S bare metal.

I personally think either function is fine. The max finding code pattern in the long function should be familiar to most. For the Pythonic function, I don't think it's less obvious enough to matter. You have a list of stuffs and you want to find the max so you wrap it in the max function. Maybe zip(xs, xs[1:]) can take a bit to recognize but I think it's eh. For the Pythonic one, one can also write

    all_diffs = [x2-x1 for x1, x2 in zip(xs, xs[1:])]
    return max(all_diffs)

Using list is also markedly faster than the Pythonic generator for me, which is to be expected: ~16% faster than both.

[0] https://gist.github.com/squaresmile/8dd08898851a4e19359cdb30...

That is interesting. Trying your timeit code I've come to see that maybe something was wrong about how I was estimating the different performance. I was just using cProfile and profiling the two functions with big inputs and then comparing the cumulative time results that way. When I use your timeit examples my results (Intel Core i7-6700K CPU @ 4.00GHz) are different and closer to yours (pythonic ~1% slower). Thanks for sharing.

I just solved this problem yesterday and my code looked exactly like your second one. Even xs was the same, except I used a and b instead of x1 and x2 cause I always do that. But I actually like yours more.

This is a very personal opinion, but I do like the second one more. I find it easier to read, but maybe that's just because I'm used to that style. And maybe you're more likely to have to rewrite it for a change, but that's kind of okay since there's less code there.

On readability, here's how I'd read it out loud:

Sort all the Xes from points. Return the max of the difference between two points that are next to each other.

I find that quicker to put in my head than the equivalent parsing of the first solution, and exactly the intention of the code.

I know a lot of people have jumped in already, but no one has come up with the intermediate version I think I'd've probably written (with one variable rename 'cause that's really long):

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        x_coords = sorted(x for x, _ in points)

        max_diff = 0
        for x1, x2 in zip(x_coords, x_coords[1:]):
            max_diff = max(max_diff, x2 - x1)

        return max_diff

Possibly dumb question, but why do type hints for a leetcode problem?

I assume you meant using leetcode's editor without type checking then yeah, there's much less benefit using type hints there.

In my vscode setup with mypy strict, pylance basic and python 3.9 though, type hints all days for me. I personally forget the arguments types like 1 second after I write the function. Maybe I'm conditioned by typed python.

Leetcode codes usually have simpler data structure and without 3rd party libraries so that's even easier to add types for.

Edit: Oh looks like Leetcode python code template has type hints

i'd honestly ask, why not?

when you paste this code, it's infinitely more readable out of its original context with those hints.

I would argue it's less readable, substantially. Type hinting was never about readability, it was about getting IDEs/tools to do type checking for you.

     def max_width_of_vertical_area(points):
        xs = sorted(x for x, _ in points)
        return max(x2-x1 for x1, x2 in zip(xs, xs[1:]))

Just seems easier...

Although I see both sides, I personally lean towards finding that type hints improve readability. And since I tend towards consistency, that ends with most/all functions being typed.

Though I spend most my time writing Swift code, which definitely influences my preference.

And then who-ever reads your code has no idea what "points" is. We had readable "type-annotation" 10+ years ago with comments to functions, this is just a logical extension to that. People need to know how to call your function, whether it's a statically-typed language or not.

Would you say this is "less readable substantially" than your example?

    def max_width_of_vertical_area(points):
        # type points: List of List of int
        xs = sorted(x for x, _ in points)
        return max(x2-x1 for x1, x2 in zip(xs, xs[1:]))

I would never comment that such a function takes a `List of List of Int` - I would instead describe `points` as being something like an `Iterable of Pairs of Numbers`.

Are Python type hints able to specify types like that?

The new type-hints sure: List[List[int]] (and you can do this to any arbitrary types or levels of nesting. See fancy example at the end.). But older iterations before the formal type-hint spec had varied/non-standard ways of doing it. Some machine-readable but others more for the user (like List of List of int). Even once the type-hint spec got approved, it was backported to older versions of python using docstrings.

My experience even before that was mostly with PyDev in eclipse. The trick back then was identifying good spots to add type-hints, afterwhich the "IDE" would take over and propagate them through the different variables and calls using static code analysis. It was surprisingly good and helped immensely with very few actual instances of types being hinted. Another one was PyCharm that would "save" or "cache" the types during debug/test runs and use them as type-hints without you explicitly having to define them.

Fancy example:

List[Dict[str, MyCustomTypeGeneric[str]]]

Which gives you a list of dictionaries with keys of type string, holding values MyCustomTypeGeneric with generic type str.

> I would instead describe `points` as being something like an `Iterable of Pairs of Numbers`.

Yes, Iterable[Tuple[Number, Number]] is a valid type, though 2D points are probably Tuple[Real, Real] or just Complex, not Tuple[Number, Number].

People? It’s a leetcode problem...

leetcode adds them automatically and I just didn't bother to take them off. leetcode also names the functions with camelCase versus whatever_this_is_called (which is the python way).

> whatever_this_is_called

Snake case.

this-is-called “kebab case”

ThisIsCalled “Pascal Case”

I would guess the Pythonic approach is slower due to the slicing operation, which creates a new shallow copy of the original array.

I found the second much easier to read.

Particularly the for loop into the range of the length of the coords minus one, is difficult to wrap my head around and easy place for mistakes to sneak in.

With that being said, I have had my difficulties wrapping my head around zip, and don't have difficulties anymore, which might actually be in favor of parents point.

FWIW, it was easier to me to follow your intent with the second example. The only clunky thing about is was the zip followed by the comprehension. It might be slightly nicer with something like:

   return max(xs[1:]-xs[:-1])

...using something like numpy. I wonder if APL/J has successive element operator.

J has the verbs behead[0] (for xs[1:]) and curtail[1] (for xs[:-1]), so the J oneliner for the above code would be

    <./ ([&}. - }:) xs

[0] https://code.jsoftware.com/wiki/Vocabulary/curlyrtdot [1] https://code.jsoftware.com/wiki/Vocabulary/curlyrtco

Thanks. The "right way" to do max of the differences (with the sort) in J might be something like?

  >./-2-/\/:~ xs

If you're gonna bring numpy into it you may as well use np.diff():

    def maxWidthOfVerticalArea(self, points: List[List[int]]) -> int:
        return np.diff(sorted(x for x, _ in points)).max()

My mind just cannot visualize what zip is doing. I’ve written production code with zip and I’ve finished leetcode problems with zip. But every single time I need a piece of paper to help me through it.

I’m fine with most of the rest of Python’s functional-style iterable helpers. But something about zip just doesn’t work for me.

Zip is just "pair each x with each y". Literally:

  [1,2,3,4]
  [5,6,7,8]
  # go down each column, yielding these in order
  [1,5]
    [2,6]
      [3,7]
        [4,8]

And then you drop ones with no pair. So zipping [1] and [2,3] makes just [1,2]. The same is true if you reverse the arguments, so [1,2] and [3] => [1,3]

The example is sorta obtuse at a glance[1], but this: `zip(xs, xs[1:])` equates to this:

  [1,2,3,4]
  [2,3,4] # copy and drop the first element
  # outputs columns
  [1,2]
    [2,3]
      [3,4]

So it's a one-liner to make a list of of each consecutive pair of items in a list. All `zip(x, x[1:])` do the same thing regardless of the ultimate use of such a construct.

But yeah, I have seen some very confusing uses of zip before sitting and thinking for a bit. TBH I think much of it is just familiarity though - after seeing a million `for (i=0;i<thing.len();i++) { ... }` I can pattern-match and figure this out easily:

  for (i=0, l=thing.len(); i<l-1; i++) {
    list.push([thing[i], thing[i+1]])
  }

(though `i<l-1` ease may depend on font) but similarly-common functional idioms just don't slide into position as easily. Yet.

[1]: I'm guessing it's the equivalent of finding the largest "gap" between a bunch of sizes of things.

Think of a physical zipper, where the two sides with the teeth come together to interlock...

  xs = [1,2,3,4,5,6,...
  ys = [a,b,c,d,e,f,...
 
  [    (1,a),
       (2,b),
       (3,c),
       (4,d),
       (5,e),
      |6| |f|
     |7|   |g|
    |8|     |h|
    |9|     |i|
    |0|     |j|
     .       .
     .       .
     .       .
  ]

https://kezan.eu/wp-content/uploads/2016/05/Zipper_Thumb_144...

    zip(xs[:-1], xs[1:])  # explicit

    zip(xs, xs[1:]) # implicit

I guess the second approach requires you to be more familiar with Python's concise syntax capabilities while the first is a nice waterfall model that anybody can read.

Depends on your team. If you wrote stuff in the second way you would be obstructing, adding friction to less python experienced developers but you would be minimizing the amount of code written.

It's hard to say, which is right or wrong here but the opacity of the second approach as you mention adds unpredictability.

I honestly think Dart is a very good solution from the culmination of various classical languages we've been using so far with Java and Javascript but there just doesn't seem to be any major FANG company investing in creating something more "modern" with Python.

I think it is a testament to Python's accessbility and also the depth it provides for experts as well. I guess the forced indentation is what gets to some developers but its a minor inconvenience.

Most developers produce bad code - period.

And I think most Python developers that produce bad code do so because they try to use too many of the whiz-bang features - or overuse bad design patterns.

You can do almost anything with functions namespaced in modules - KISS.

I am learning python right now, Python is not only non beginner friendly, it's also not C-family(java,c++,js...) friendly(assuming most developers knew some C before taking on Python). That been said, it's versatile enough for me to continue, but calling it beginner-friendly is misleading to say the least.

I disagree with it being non beginner-friendly. Too many of the resources are geared towards beginners, and its docs aren't as thorough as Java's.

Python is pretty awful for beginners really. Every keyword has half a dozen meanings and invisible characters can break your program.

People say scheme is hard but it is by far the easiest to teach, especially compared to Python.

What language would you consider beginner-friendly?

Python is great glue. But it's huge. Packed full of features. Has all sorts of syntactic sugar. It's the C++ of scripting languages. Great for an intermediate programmer who just needs to slap something together. But at the very beginning, these can actually be drawbacks because there's so very much to learn.

I would suggest something small, that you can realistically fit all in your head. I honestly believe Pascal is still an excellent choice. For something a little less low-level and more scripting-like, Lua seems nice. The JavaScript ecosystem is awkward, and there are things to criticize (no integers?) but by itself, it's a nice small language as well.

> It's the C++ of scripting languages.

This is such a fantastic analogy. Thank you!

C++ tries to be all the paradigms, even if they're bolted on. Python is similar in that regard. Complex OO, functional, exceptions, decorators, lots of container types, iterators, generators, operator overloads... The only thing it's missing is a macro language.

Python's "batteries included" standard library stance takes it even beyond the C++ analogy in terms of sheer volume of out of the box capabilities you get.

Python has a built-in macro language. It's called Python.

Checkout Hylang, a Lispish language that compiles to Python, or maybe a Lispish syntax for Python? You can write pieces of code in .hy files and import them from .py files and vice-versa.

And then you have macros like in macros that traverse and transform code.

But Python still has a reputation of being a simple language for beginners. I’m not sure how that reputation endures. Is it just because of the lightweight syntax?

Because Python is easier to start programming with, BASIC like, but a large majority fails to actually read the official documentation.

If they would do that, then they would realize Python is as powerful as Common Lisp, Ada, C++,.... with similar doc size in pages.

It is deceptively simple. The Python learning curve looks like a snake - https://fabienmaussion.info/acinn_python_workshop/figures/xk...

Does this curve really represent everyone's experience?

I never experienced the "I hate Python" phase. I think I went straight from "So exciting" to "productive" phase with Python.

I hated Python 2 because it did the Wrong Thing with integer division (it didn't cast to floats), so my attempts at simple scripts just didn't work.

I reencountered Python at a data science course that was somehow mandatory for my masters in ODE numerics. It has a HUGE availability of standard and third-party packages, so you can be INSANELY productive. I'd write in Brainfuck if it was the only way to have like Pytorch and giotto-tda and networkx and fastapi in the same room.

My only hate Python is how hard it is to push for JIT adoption versus other dynamic language communities.

Back to the original question, is there any other language that doesn't look like this?

Why the requirement for a beginner to know their entire language? Writing code is fundamentally about making changes to a system with incomplete knowledge - abstraction, encapsulation etc. Working in the presence of unknown language features is another facet of the same thing.

So you don't get bogged down in details. There are many programmers out there who can glue libraries together but have no understanding of algorithms. If you want to focus on the CS side of it, remove all distractions.

My first CS professor insisted the first year be done all on the whiteboard. And this wasn't back in the dark ages. It was long after every student had a personal computer on their desk. Everything was done in a low-level pseudocode somewhere between Algol and C.

She felt that computers and actual programming languages would get in the way of learning the principles. I'm not quite that hardcore. But she was on to something. I learned more from that class than any other.

You can avoid getting bogged down by learning a limited subset of a language, though. e.g. in Python you could teach most algorithms with just conditionals and functions, and keep things pure functional using only tuples for storage. Introduce assignment, lists and loops whenever it suits you.

Coincidentally well timed - the new PEP on pattern matching would be great to include in the limited subset for teaching:

https://www.python.org/dev/peps/pep-0636/

The above tutorial is based on user input but to my mind this mechanism seems equally good for teaching recursion on data structures as you would in say, ML.

> It's the C++ of scripting languages.

Sorry, but Perl still wins there.

Pascal is nice to teach the basics, but I would be very discouraged if I had started learning something that's so rarely used in the "real world".

That's a fair point. Pascal is no longer a commercially significant language. Still, I do run into solid little projects that are written in FreePascal from time to time. Sometimes not so little.

https://wiki.freepascal.org/Projects_using_Free_Pascal

Lua was the first language i learned where i actually started to 'get' programming. I'd tried python and a bunch of other languages before that, but lua was simple and barebones enough i could focus on learning how to program instead of how the language worked.

When i tried to learn python i got caught up in trying to learn imports and classes and other things before i actually fully understood how stuff like variables, arrays and functions worked.

Lua could benefit from a larger standard library for sure.

Don't get me wrong, i've got my issues with lua, it's good at what it's designed to be, a small easily embeddable scripting language that plays nice with C, but i've definitely hit some limits with lua on larger stand alone projects that make it not so suitable.

Its tiny standard library, which kind of makes it limiting, I think is a boon for learning. It forces you to remake the wheel at times. Despite not being an OOP language, I learned about OOP by trying to write my own class system in lua using metatables, hitting the limits of what I could do, and looking into languages with built in classes that had all the 'things I was missing' in my own hackish OOP attempts in lua.

As far as learning goes, not having the tools baked in forces you to learn about how they actually work when you have to remake them. It might not be efficient for people who just want to get the job done, but for learning it's definitely helpful.

Lua's also used in a bunch of 'fun' things. It's used as a scripting language in tons of games, half the time when I look up lua stuff these days it's all about roblox...which I think is big with the kids or something...it's used in fantasy consoles like the pico8 and the tic80, it can be used to script whole games with things like LOVE and the solarus engine.

Personally, I found it to be a good language overall for inspiring self-motivated learning. There's always something fun that can be accomplished with lua relatively easily.

I don't think there is one objectively best language for anyone to start with, but I'd suggest something with a relatively concise set of features so as not to overwhelm a novice or hand-wave away important details.

I am very happy that I started with C. It has surprisingly few features compared to most languages and it gave me a good appreciation for how memory is managed at a relatively low level. The biggest downside was that it took me a long time to learn how to make anything I thought was "cool" at first (like GUIs, graphics, sounds, or networking). Some people might struggle with that.

I rarely write C code now. It's not as practical for the kinds of things I make and I have nitpicks with it just like any other language. But I don't think that's the point. Your first programming language is an instrument for learning first and foremost. Once you've become adapt at one language, it's relatively easy to pick up more.

I'm not the person you replied to and my perspective is pretty limited overall, but when I was younger, I found Visual Basic to be the easiest thing for a beginner. However, that's as much about the IDE as it is about the language. I remember when the Visual Studio express/community editions were first coming out. Visual Basic was a relatively simple, readable language, and the IDE itself made it simple to pick-and-place GUI components on to forms and write callbacks for them, even before I understood the concept of event-driven programming. I felt really empowered, making GUI applications that previously seemed to me like they would require years of study and experience to create.

Scheme is great. It has basically no syntax to bog you down and you can focus solely on the algorithm side of programming.

I came here to say the same thing. A lot of the discussion with modern languages focus around syntax. Why not use a Lisp which has very minimal syntax and focus on solving problems instead?

Do you have an opinion about Common Lisp? I know that Scheme is more minimal and cleaner but since you recommend Scheme I want to know what your opinion about Common Lisp is.

Not the OP, Common Lisp relates to the genesis of IDEs alongside Smalltalk, as such it has a very good developer experience, alongside native compilation, which can only be fully appreciated when using the surviving commercial offerings.

Yes, I answered the question from a very different angle (Pascal or Lua) but my motivation was also avoiding the learner from drowning in syntactic details. Scheme would be even better than that.

And good native code compilers to choose from.

Does one need to use advanced features? The interessting aspect of python IMHO is the "pseudo code"-nature of it's syntax that you already have on the basic levels. So a beginnwe need to learn only a sjort bit and can write friendly code that feature are feature can be enriched with something more advanced over time.

If anyone has any recommendations for good ways to pick up this knowledge except by attrition, I’d be interested in hearing them!

How to write idiomatic Python? This talk is often recommended: https://www.youtube.com/watch?v=wf-BqAjZb8M

Reply on news.ycombinator.com