Python’s tug of war between beginner-friendly and advanced features (opens in new tab)

...although that might all be the fault of aws-cli. Which by the way doesn't install on a vanilla Ubuntu 20.04 ami via apt which is just... really really bad.

Aws cli continues the inexplicably horrible aws interface that makes me shake my head at people lauding their might, along with their console.

The console rewrite... anyway, pip seems to be a headache, certainly not as good as gems.

I was sad to hear about the change to ReScript though. ReasonML targeting the browser and native seemed nice to me, although I do agree the documentation situation and DX wasn't ideal.

For what it's worth, there are a lot of good interesting languages out there that aren't Python and have pretty good library ecosystems. Kotlin, Elixir, and Elm come to mind. But they don't exactly fit the Python niche.

What you're describing sounds to me like a modernized Common Lisp with commercial backing. Rework CLOS a bit, clean up some of the other crufty old weirdness, and give me a big selection of high-quality well-supported libraries like Numpy, FastAPI, Trio, etc.

The advantage of doing it in some Common Lisp derivative is that things like React JSX are pretty much "free" and wouldn't much seem out of place, whereas in Javascript they need a whole separate build/compilation step and are often portrayed as black magic fuckery.

edit 1: Arguably Julia could be used for a task like this, but its library ecosystem and language runtime are heavily skewed towards numerical computing and data analysis.

edit 2: Raku also sounds like a possible candidate here, but it obviously lacks widespread adoption and last I heard it fell significantly short of Perl 5 performance. I'm not sure what kind of library ecosystem it has nowadays and I doubt we're going to see big commercially-backed library development efforts for it, soon or ever. Perl 5 has a huge ecosystem of course, but it's such a nasty warty language with nasty warty tooling.

This is offensive. Whether the people who work hard to make and share (for free) half baked libraries are addicted to drugs is really not part of the main thrust of your argument. You could leave it out, save words, and not have distracting comments from people like me while still making your point.

I know the mantra is that the standard library is where things go to die, but I believe that to be cultural. I still have code running somewhere probably that uses the cgi library, which was perfectly well-suited for a Windows serve where the page in question got an average of seven hits a day, never to scale much beyond that (you'll have to trust me on this, for amusement I reviewed ten years of logs for just that page to find nothing out of the ordinary, and there are reasons it would not need to "scale" in the future).

Each library and each string-formatting method and so on is a choice, and those choices impose a lot of speedbumps and cognitive friction.

   import cv2 

This, and library documentation. It's probably the single practica issue I have with D and Nim. They seem to have fairly robust standard libs but when I look for something specific it always turns out this feature is missing, outdated, or badly documented.

https://dotnet.microsoft.com/apps/aspnet/web-apps/blazor

I seriously cannot think of anything I could do to exceed Python.

Does it do everything? No. But name a tool with significantly greater overall reach. Some compete, but seriously. . .

If you are new, chances are do not yet know what is a quirk and what is idiomatic.

It can be challenging and frustrating trying to follow guides or tutorials and they are all doing things differently - which is the "right" way? You have no idea as a beginner.

If dealing with uses after free and lack of bounds checked access in release code is still a fun factor.

> Java -?-> Go

Not at all, unless one misses Java 1.4 with loots of if/else boilerplate.

Having said that, isn’t Deno close to what you’re looking for?

In turn, implicit variable declarations (using the same syntax for initialisation and assignment) are a reasonable choice for a language that aimed to be “executable pseudocode” and that supports mixing initialisation and assignment in a single statement (e.g. `a, b, self.c = foo()`).

It's amazing that people can program in imperative languages at all, yet it feels easy. I wonder how much trouble this causes for somebody learning how to program in a modern high level language.

Maybe golang comes closest to that (and concurrency is messy in there), but I'm not sure if it fulfills the "beginner-friendly" criteria from the perspective of a python developer.

Making programs execute faster could be. And there using many cores is one implementation strategy among many complementary ones. But the current landscape of programming languages shows that languages focusing on execution speed and parallelism have smaller user bases.

Also, re this data interpretation of Python's killer app, this usage of Python is something fairly recent and happened after Python had already broken into mainstream usage in the industry. A lot of small and big applications have been built using it before the data and ML things got in vogue (like Youtube, Dropbox, Spotify etc at the bigger end).

However, their scheduler really needs speed ups, and they do run into weird data handling bottlenecks in my experience.

I'd argue it replaced Perl.

What does it matter to you if there are features in the standard library you don't use? The full python embedded distribution is only 8MB including runtime.

But otherwise, yes - make f-strings the “one obvious way to do it” and use `format` only when necessary. And get rid of the old %-formatting.

Also consider making f-strings the default: https://pyfound.blogspot.com/2020/04/all-strings-become-f-st...

`format` is still useful, particularly when working with pre-templatized strings. It's also a (relatively) new feature; Python 2 didn't have it at all.

OTOH, I wouldn't cry if Python 3.X finally removed %-formatting. `format` does everything that `%` does, with a much nicer API (especially in 3.7+).

f-strings work well in simple cases. But once the things you want to output are somewhat larger expressions, format() works much better.

Example: instead of something like

    print(f'{id:<5}  |  {", ".join(members}:<50} |  {", ".join(str(score) for score in scores):<30}')

    print('{:<5}  |  {:<50} |  {:<30}'.format(
        id,
        ", ".join(members),
        ", ".join(str(score) for score in scores),
        ))

No, please.

F-strings are useful for some things, but there's a good reason. to define templates other than deep in code for ease of editing them distinct from functionality (often, completely externally to code) and using str.format supports that.

If anything, I'd prefer r-strinfs as the default with both escape handling and formatting non-default options, but the status quo is acceptable and better than r-strings as the base.

Kotlin solved the syntax and language warts on top of a good runtime.

For python the syntax is (mostly) good but the runtime and package management needs a rehaul.

    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)

    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)

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

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)

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

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.

    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

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.

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

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(xs[:-1], xs[1:])  # explicit

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

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.

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.

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.

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.

On the other hand, your example is valid Typescript, although if you use attempt `x + 1` then Typescript will yell at you for incompatible types.

Unfortunately your example is also a problem in Python, if not worse:

    def foo() -> int:
        return 42

    # valid
    x: int = foo()

    # also valid
    x: int = foo

First, is that in no other text form, does white-space change meaning such that the text becomes "unreadable" (sure your docs may be formatted a little weirdly, but hey someone can still read it). Simple python is close enough to prose that people get confused.

Second, is that they haven't learnt to grok compiler messages - the program either works or doesn't work. Coupled with number 1, it basically means they can't /see/ any issues or fix them.

Part of me wants to forbid all "dumb" text editors for introductory programming courses and make everyone use an AST-based one that only allows you to create syntactically correct programs. Unfortunately there's zero chance of that happening any time soon...

As for teaching JavaScript’s pain points... that’s not really how I operate. I’d rather they know the general rules and come across edge-cases when they’re in a position to solve them, rather than overload them with information. Automatic semi-colon insertion is powerful enough to get you through several large-scale projects, so there’s essentially no point to discuss it prematurely as anything but a curiosity, “this could be a gotcha, so keep your code clean”.

Finally, comparing the error linters in VSC for Python versus javascript, especially if you //@ts-check... I think JavaScript actually does a better job.

Incidentally, Ruby has a similar problem for self-learners.

For almost every science or engineering domain, python has some of the best in class libraries available (either native or as bindings to the standard C libraries everybody uses). It is more likely than not a plug in or scripting language for the engineering desktop application you use. It will let you do everything from interactive data analysis to web development, to scripting and devops, to cutting edge ML research in the same language using mature and battle tested tools. This is extra nice if you are combining many different domains, like doing Machine Learning and Computer Vision on GIS data and presenting the results on an interactive web site.

Especially if you're ambition in life isn't to be a professional programmer, but rather a professional that uses programming to do his job, then learning just one language is very enticing and python is probably the language that is most likely do have everything you need to get the job done, no matter what that job might be.

Numpy, scipy, matplotlib, flask, django, tensorflow, ... all the way down to tiny packages like emcee makes it an extremely compelling ecosystem to develop software in.

Shell scripting, e.g. dev ops? Ruby for me, Perl for complex regular expressions.

Web development? This depends.

High performance environment? Golang, C.

Basically, the care where Python is called for is the scenario where it offers a library you absolutely need, not anywhere it’s definitely the best language for the job, because it rarely is.

Another big benefit is how it makes your code self-documenting -- and makes that self-documentation self-enforcing. If you are making an API for consumption, it's dead simple to make it very clear how it's structured, and to set & enforce contracts for its usage.

For me, in general it is more about its power to ease the cognitive load associated with coding. Having to constantly look up documentation to see what the types of arguments are and in what order they need passed brings me out of flow. When I don't have to think about that, I can spend more time focused on the problem at hand. That doesn't mean I can't program without them; I have to do a fair amount of Vue stuff at work and I make it work despite not being a front end guy. But my preference is always for static typing.

Over time, this has a very noticable impact on development speed, and in a very painful way for the individual developers who need to spending your time tracing the various call paths in unrelated code and build up a mental model of the involved types every time they want to do a nontrivial change, and then deal with the fallout of unintentional bugs due to missed code paths for an unpredictable amount of time as they are discovered.

So when there is a solution that can completely eliminate this class of bugs in an automated way, this sounds like a very appealing feature.

How do you know what the argument “details” should be?

The function documentation says “takes the query details” ... so people sit down in the repl and just screw around with the functions to try to figure out what they do, or search for examples of how they’re used.

with type hints, this discovery process for other programmers was significantly quicker and on boarding was faster.

I mean, sure, just write better docstrings, but type hints can’t get out of date, because it’s a type checking error.

Maybe a better solution is rust style “compiled doc strings” so the documentation can’t be wrong, or rust style inline unit tests that show examples of how to use functions... but python has neither.

It’s been my experience that type hints for your own code... eh. But if you’re working in a team, they’re valuable.

For example I'm sure you've had runtime production errors where you tried to call a method on a null object many times. That is the kind of thing last generation type systems couldn't help you with, and new systems do.

(In statically typed languages with implicit nullability, nulls create the same problem.)

Basically, explicit contracts are Good, and types are a subset of explicit contracts that are more easily enforceable than most.

Same here. The arguments for it seem to be:

- It allows you to find bugs in your code without running it. I’ve concluded that my workflow must be different from people who make this claim - I never write code without testing it. This is more comprehensive than relying on a type checker, because it finds all kinds of errors, not just type errors.

- It’s a form of documentation of function parameter and return types. This is better served by comments, because type hints are usually inaccurate in a duck-typed language like Python. For example, I see hints like `def twice(x: int) -> int: return x+x`. The correct type for a function like that isn’t `int`, it’s something like `addable`.

Guess you're just a better programmer. I've run into many in JavaScript and Python.

There are many, many things that can be expressed with types... depending on the type system. In Haskell, when you look at a function type, you instantly know whether it returns an optional value (a Maybe), or if it has side effects (IO), etc. You can also tell how general the function is, by how abstract its parameters are.

An example of something that becomes possible with a rich type system: https://hoogle.haskell.org/

It's very disturbing from the application Dev world view where people seek longer names for reasons, but after spending time in FP/LP and math you quickly forget long names. You seek variable count reduction most the time also.

   for outer_index over array1
      for inner_index over array1[outer_index]
        print array1[outer_index][inner_index]

Or it could work with a custom type with overridden operators through __getitem__.

It's a stretch to call it "completely normal" though I believe you're correct in a strict sense: you could always construct the rest of your program such that it would contain that line and still compile. It would be extremely bad style.

Half of them are about functions like range() and .values() becoming lazy instead of returning simple lists. I think this is a genuine blow to ease of use, though it does get rid of performance pitfalls.

The other half are about / always doing float division. But I think that's actually more intuitive for people who aren't already used to other programming languages, and it's much more predictable given that Python is dynamically typed and floats and ints sometimes get mixed up. It's also not awkward to work around, you can just write // instead of /. (Working around the other issue requires wrapping list() around things, which gets ugly very fast.)