Hacker News Reader

Comment by js2 | Hacker News Reader

> Over time, we’ve had a trend of adding unnecessary, low-payoff complexity to the language. Cumulatively, it has greatly increased the mental load for newcomers and for occasional users.

I couldn't agree more with this sentiment from Raymond Hettinger. I first learned Python starting with 1.5.2, and coming from a background of C and Perl. One of the things that really attracted me to the language was how compact it was. It took no more than an hour to learn most of the language, a day to read the entire spec, and maybe a second day to read the entire standard library documentation. It suffered from virtually no gotchas... nothing crazy like Perl's scalar vs list context, etc.

I haven't had trouble keeping pace with Python and I even probably agree with most of its changes. But this change really seems superfluous. How does it fit into the zen?

Can a language ever reach a point of being done?

View on HN

You're not alone. My goto example of this is the pathlib module added in 3.4. It has this feature for making it easier to concat strings representing file system paths...

    >>> from pathlib import Path
    >>> Path("foo/bar") / "baz"
    PosixPath('foo/bar/baz')

Don't get me wrong, the existing solutions until pathlib (os.path.join or string concatenation) left a lot to be desired. And there are certain tricky path-parsing things this module does that are wonderful. But overloading the __div__ operator for a "cute" API just feels... wrong...

Of course, after my initial disgust, I now use it everywhere :)

Note that you don't have to use `/` to do this, you can use Path.joinpath or call Path/PurePath with multiple path segments.

This is very much TIMTOWTDI. Larry Wall would be proud.

I think part of the reason Wall adopted TIMTOWTDI as a design is because he observed that it's what happens anyway, so you may as well embrace it.

The first time I used Python on a team, I learned that "One Obvious Way" was a lie.

In order to achieve OOW, you need really high-level features (assembly language programmers have every possible way to accomplish a task!), but also a very limited set of them (so nobody can pick the 'wrong' one). But as a general-purpose programming language, users also need power and flexibility.

It's an unstable tripod where as soon as one starts getting higher, you mess up the others. I can tell they've been trying to slowly raise all three (and deprecate/remove old and lower-level pieces from the bottom), but it's a delicate balancing act, and it's easy to run into other constraints, like complexity.

I'm not sure why it's wrong? Python isn't Haskell. If you're dealing with path manipulation a lot, it makes for much more readable code.

I'm curious, why not override the usual + operator, which is far more idiomatic, instead of trying to get cute by using using an operating which generally implies division. Yes, it's fun once you understand it, but at a first look, it's more confusing than useful, whereas + would be fairly self explanatory.

Well, / is path traversal; I think + would be too easily conflated with the “similar but importantly different” string concatenation, especially since « + "/" + » is an idiom in string-based path manipulation. For instance:

  p1 = "/a/b/c"
  x = "d"
  p1 + "/" + x == "/a/b/c/d"
  p2 = Path("/a/b/c")
  # If + replaced / for Path:
  p2 + "/" + x == Path("/d")

Now if you've just reflexively written the concatenation the way you did before, the type signatures match up but the result is completely wrong. The current situation where / doesn't exist for strings and + doesn't exist for Paths is much safer versus that.

You have a point, and I can’t tell you why they decided to go with /usr/bin/bash instead of usr+bin+bash back in the dawn of computing. I suppose you could write you own set of tools to change the entire ecosystem to use that convention, even providing new URL definitions.

But either way, I can’t see the problem with python defining the exact same operator to mean the exact same thing as you’d expect in that specific scenario.

The plus operator is traditionally expected to be symmetrical, i.e. a + b == b + a. The division operator, on the other hand, is not: a / b != b / a. The fact that a slash is used as a separator in paths is only a welcome coincidence.

In the context of strings, that's not true, and very commonly accepted:

"a" + "b" == "ab"

"b" + "a" == "ba"

Using + for string concatenation was an error introduced early in Python's design, and is to difficult to repair now.

And if you are not dealing with this all the time, it makes the code completely unreadable.

"Python isn't Haskell."

Not sure exactly what you're saying there? Haskell strikes me as far more likely to define an operator for that.

Although Haskell will define something other than /, which unless you jump through some hoops is going to be the fractional division operator [1]. You'd have to be crazy to try to give a "path" an instance of Fractional, though I'd be intrigued to hear someone's definition of the "reciprocal" of a path.

[1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...

> I'd be intrigued to hear someone's definition of the "reciprocal" of a path.

..

Reciprocal is its own inverse, so the reciprocal of a/b/c and d/e/f can't both be "..".

The closest you could come is an anti-path, where if you are at a/b/c, you could have c'/b'/a' that when combined together produced the root path of both these things. You could then have things like b'/a, which represents "rise up to the previous directory, which is named 'b', and descend into a" where the reciprocal is a'/b. I'm done fiddling with this for now, but it's possible you could work this into a sensible scheme with some concept of "reciprocal". It's useless in practice because who wants a .. operator that asserts the name of the directory it is rising from? (And presumably, what, errors if it isn't right? Refuses to rise like .. does at the root?)

However since Fractional instances also have to be Num instances [1], and there's no practical way to fill in most of those, it's not going to get you very far. And the Fractional requirement of fromRational, while you can try to write something that turns a Rational (which in Haskell is specifically two Integers being used as a ratio) into a path, it's going to be very silly.

[1]: https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelu...

yeah but haskell would use ///

at least

I think this is fascinating because I generally agree that Python is seeing a bunch of features it doesn't need. But then your go-to example is one of my all time favourite feature adds. I deal in path concatenation all the time.

Maybe the answer is that none of us work in all the domains where Python is used, so we are all speaking with ignorance/elitism when we decide which list of features are superfluous.

I won't show you my pipe library then

I don't think that's out of line for Python. I mean, it overloads * for string and collection repetition...

I've stopped recommending Python as a new language for people. It was my go-to for a long time, but after sitting with a couple of people trying to learn it, I discovered the hard way that it has passed the "easy-to-learn" horizon a long time ago.

I am deeply unconvinced the proliferation of features is even remotely necessary or helpful.

But then, I admit I've become deeply skeptical of the whole "language as a proliferation of features" model of language development in general. Python is just a particularly frustrating example because it's a clear case of a useful simple language becoming a huge, complex language that isn't really that much more useful. I'm coming around to what doesn't go into a language being more important, because there's always another feature the language needs and always some reason to put it in. If you don't have a clear thesis on why and how you're going to reject things, you won't often enough.

Can you expand on what you think has become difficult and what you recommend now?

The big problem is when the beginner first encounters some external code. One particular case was trying to teach a QA automation engineer about what was going on. First of all, I was having trouble tracing back all the definitions involved due to the excessive "cleverness" involved in assembling the API, but we'll put that down to the testing API doing things it shouldn't.

The problem I had was that I had to explain "oh, well, this is a generator because of the yield, and the arguments don't show up in the documentation for the function because it's introspecting on the keywords you pass in dynamically, and this here is a generator comprehension with its own syntax, and this is what the decorator on top is doing on this code, which is why this is breaking" and honestly it kept going like that for a while. When it all worked it was fine, but when anything broke, it's become far too easy in Python, and arguably idiomatic Python, to erect a rather intimidating wall of features and automatic rewirings and fancy decorators and suddenly to fix their problem the novice is swallowing all of twenty years of language development in one shot... or they give up and do something else.

I don't have a current go-to recommendation, though I've found myself recommending "Go but stay away from any concurrency features for a good long time" a few times. Ignoring all the other controversies that HN likes to indulge in, that's not a half-bad intro to "real programming" for a modern language. It's not the only good choice, of course.

Ah interesting. I totally hear that.

Your idea of a beginner is someone in a mature environment though, I guess my thought when I read your previous comment was a total beginner starting from a blank slate.

I couldn't agree more. All of these people teaching python to children is so crazy to me when the language is so BIG!!

> I haven't had trouble keeping pace with Python and I even probably agree with most of its changes. But this change really seems superfluous. How does it fit into the zen?

Explicit is better than implicit, Simple is better than complex, Readability counts, I'm sure others would match.

Positional-only parameters are useful in general and even necessary to implement / override APIs originally defined in / for C (which has always had access to positional-only parameters). Currently, defining an optional positional-only parameter is:

    def foo(*args):
        if len(args) > 1:
            raise TypeError(f"Expected at most 1 argument, got {len(args)}")

        if args:
            arg = args[0]
         […]

* the number (and optionality) of positional parameters is completely invisible and implicit rather than readable and explicit

* it requires various non-trivial assertions repeated every time

By contrast, with PEP 570 this becomes:

    def foo(arg=None, /):
        […]

It does require the knowledge of "/" but spells out exactly what the contract is clearly, cleanly, and without requiring additional developer legwork.

I read the PEP and understand the argument (no pun intended). I'm just not convinced. I don't find the justifications given in the PEP at all persuasive. Rarely have I ever needed to enforce positional over keyword arguments and the rare times I've needed to, I can use:

    *args, **kwargs

as needed, and again, don't find the PEP's arguments against doing so convincing.

Also, I mean, come on, if a function signature is:

   ord(c)

It's pretty damn obvious not to use "c" as a keyword argument. And as hard as it is for programmers to name things, I can't recall ever struggling to name a function parameter.

If you need to rename a parameter that it's likely someone might be calling as a keyword, then bite the bullet and break backwards compatibility or just introduce a new function name if backwards compat is truly that important. (And besides, this has to be one of the more trivial checks for a static analyzer to find.)

> the number (and optionality) of positional parameters is completely invisible and implicit rather than readable and explicit

It's invisible in the function signature, but it should be in the function documentation or as a last resort, read the source. I find myself reading Python library source code not infrequently because it's not unusual to need to understand a function's behavior. Getting the function call correct is like the least hard part? But again, this really feels like an edge case.

> it requires various non-trivial assertions repeated every time.

In fact, that's a pretty trivial assertion if you ask me. ¯\_(ツ)_/¯.

FWIW, I don't find:

    (arg=None, /)

to be a legible syntax for declaring "this function takes a single optional positional argument". And in its full form, this is truly ugly:

   def f(pos1, pos2, /, pos_or_kwd, *, kwd1, kwd2):

Seriously, WTF. The library author couldn't make up their mind about pos_or_kwd? Why even allow that? This is no better:

   def f(pos1, pos2, /, *, kwd1, kwd2):

Just no.

Maybe I'd be more convinced with a cleaner syntax. I think the Per-Argument Marker option proposed in the PEP is a lot more obvious (not sure about using a '.' though) and think the argument against it is pretty weak: "While this approach may be easier to read, it has been rejected because / as an explicit marker is congruent with ∗∗ for keyword-only arguments and is less error-prone."

I note that "less error-prone" is stated without evidence and that "is congruent with ∗∗" is definitely against the zen.

But generally, as I said, the entire PEP is not convincing to me. Anyway, I'm sure I'm repeating the arguments against the PEP others have made and Guido has ruled in favor anyway, so I'm just screaming at the ocean.

On one of the threads, they suggest destructuring syntax.

Taking that a bit further and ignoring backwards compatibility entirely:

    def foo([po1, po2], pk1, pk2, *args, {kw1, kw2, kwd1=default, kwd2=default, **kw}):
       pass

And it implies some obvious shortcuts:

    def all_pos_only[po1, po2, po3=default, *args]:
       pass

    def all_kw_only{kw1, kw2, kw3=default, **kw}:
       pass

As a fan of Clojure, I would love for Python to get rid of most of strange and archaic (IMO) unpacking syntax and just switch wholesale to Clojure-style destructuring. In my opinion, it's a single solution for all of those problems and it ends up looking a lot cleaner. It's also just a lot easier to work with if you're trying to unpack a single value from a nested structure or define a flexible API.

If I ever saw this in real life:

    foo([po1, po2], pk1, pk2, *args, {kw1, kw2, kwd1=default, kwd2=default, **kw})

I'd think... that function is trying to do too much with its parameters and should be multiple functions.

Now yes, I realize an author could already do that with ∗args and ∗∗kwds, but the fact that the author would need to handle the argument parsing is sufficient disincentive to prevent most people from doing so.

But if you had to refactor the above function, you wouldn't have to reverse-engineer some argument parsing. You'd know how it must be called anywhere in the project, just by looking.

And generally, I think the disincentive rationale is self-defeating:

* the premise behind disincentive is you're dealing with someone who is (at least in the moment) careless

* now they're going to have to write more code to do a thing they've set out to do

* but we've already selected for an individual who is writing carelessly

In this case, it can only work if extra argument checks are the last straw that causes this individual to say "enough" and refactor that function. For what my experience is worth, I think this is unlikely.

> The library author couldn't make up their mind about pos_or_kwd?

I really like the possibility of optionally calling a positional-argument function with named keyword arguments, which can be more legible in some calling contexts. I would argue that in most cases most function arguments should be of the pos_or_kwd type. YMMV.

The reason Python added keyword-only arguments was so that library authors could freely reorder them (e.g. add a new keyword argument before another, or add another positional argument before keyword arguments) without breaking backwards compatibility.

The only reason to have positional-only arguments is to allow libraries to rename their arguments (without changing the semantic meaning) and guarantee that calling code doesn’t break. This doesn’t seem like a very strong need.

> would argue that in most cases most function arguments should be of the pos_or_kwd type.

Oh, that’s definitely the case. My point was: why would you have a function that had three different kinds of params: pos only, keyword only, and pos_or_kwd. That would be insane. You probably wouldn’t. That it’s allowed (after this PEP) is an consequence of this change which is just more evidence to me that the PEP isn’t needed.

A huge perk of doing it at the function definition level is that IDEs can give you a more reasonable function signature.

Seeing "foo(args)" as an autocomplete necessitates looking at the docs to find out what "args" gets used for.

I've asked this question too and what I think what is going on is that the python dev community is still pretty active - and people love to change things, get their code and ideas into the language. I think they've been pretty good about rejecting a lot of the really awful stuff, but not as good maybe at thinking about what is really necessary.

And this type of discussion makes me think about Django - it used to be a nice little simple framework, then it got a big community around it and grew every nature of features to such a point that I think nobody should actually use it. The code ends up being pretty awful and I think probably the rise of Flask coincides with Django getting too big and too complex over a period of years.

Jose Valim has said that there is no plan for an Elixir 2.0, because he feels it is pretty much "done" in terms of major features. It's a refreshing change.

I feel the same but about Java. I feel that with Java, however, it is much, much worse because of its enterprise friendliness and thus being much more reluctant about breaking changes to the language. I would love to see certain features getting dropped from languages as new ones are added. I think Python has done an okay job of keeping the language consistent and simple and cleaning up the libraries, etc.

Funny enough, I first used Java in 1995 or so. What a nice little language I thought then. I then managed to avoid it through its enterprise madness of the 2000s and finally started using it again around 5 years ago. It's still bureaucratic but I don't find the language itself complex.

> Can a language ever reach a point of being done?

TeX? Yes, I know there are still new releases occasionally, but as far as I know, it's feature-complete, and only occasionally gets bug fixes. I wish the developers of more languages, and software in general, would recognize when their projects were done. Unfortunately, that doesn't seem to be the way things are headed.

Unchecked type annotations were when change for the sake of change seemed to take over in Python.

perl is hard only if you come from a certain point

trust me, if you have no apriori regarding what a programming language is, perl will make a lot of sense

Well if you want my path it was something like: BASIC, 6502 assembly, Fortran, Pascal, C, C++, Scheme, Perl, shell (sh, tcsh, sed, awk, etc), Java, Python. A bit of PHP in there somewhere. Some TCL and lua and ruby too.

I may have the order a bit mixed up. I started with perl 4 and got to be reasonably adept, using it as my primary language from maybe 96-2000. I've used Python as my primary language since 2000. I'm pretty fluent in C, Java, Objective C and shell.

Anyway, I had to fix a couple hundred line Perl script the other day and it had me scratching my head for long enough that I was pretty close to rewriting the whole thing in Python. One thing I really love about Python is that it's trivial to test bits and pieces of code via the REPL.

you have a point, perl might give too much linguistic rope for people to hang themselves and future maintainers, but I'd slightly argue that it's because people don't grasp the nature of contexts

python lost the 'only one obvious right way' zen long ago sadly.

Reply on news.ycombinator.com