My Wish for Python 4 | Hacker News Reader

My Wish for Python 4

aroberge.blogspot.com

31 pointslumpa31 comments

I think one of the nice things about Python is that most people write it in a similar way (with the exception of classes vs not and annotations). "There should be one-- and preferably only one --obvious way to do it." There are already "accents" on how people write code, and the beginner dialect sounds a bit too close to Visual Basic to me.

There are some chances to smooth out some warts. I like typed languages like TypeScript, though I find Python's type system not very natural comparatively.

My biggest gripe though is that it's not possible to write functional code where you can read the operations in order. For a contrived example, if you wanted to know the total length of all strings in a list that start with the letter 'a', you would do the following in C#:

    strings
        .Where(s => s.StartsWith('a'))
        .Select(s => s.Length)
        .Sum()

Each step follows the last: first you filter the list, then you get the lengths, then you add the lengths together.

The equivalent in Python is this (I broke it out into multiple lines for a better 1:1 comparison):

    sum(
        len(s)
        for s in strings
        if s.startswith("a"))

Okay, maybe in this example the only difference is the location of the if, but in more complex example I really lose the flow by using list comprehensions.

And before anyone says I can use `map` and `filter` assign each step to a variable and write it in an "imperative-ish" style, I find it difficult to come up with descriptive names for each intermediary variable, and don't want to call them `l1`, `l2`, etc.

Gripe over, hopefully I conveyed my message.

I agree with you that the C# example is far more readable.

One thing I like about Rust is that you can implement traits on standard library types. You can imagine implementing a "Where" trait on e.g Vec<T> (btw, you don't have to, since "filter" is already there) that would return an iterator that can be used by the next method in the call chain.

Unfortunately you can't "extend" standard library or built-in Python types like this.

In Rust your example would be:

   strings.filter(|s| s.starts_with("a")).map(|s| s.len()).sum::<u32>()

That chained syntax is entirely doable in Python.

I see no reason to object to a1, a2, a3 as intermediate steps in a computation. They don't have a name in your chained style, why does the name matter with the intermediates?

This is very clunky, but it is similar, could be streamlined.

    import aiostream
    from aiostream.stream import pipe
    import operator

    v = aiostream.stream.iterate(set("a ab abc ddd eeee abasdfadf".split())) \
        | pipe.filter(lambda x: x.startswith('a')) \
        | pipe.map(lambda x: len(x)) \
        | pipe.reduce(operator.add, 0)

    print(await aiostream.stream.list(v))

+1 for your sense of humor.

I also like to chain functions in sequence like this, I use the toolz library to do it in Python.

https://toolz.readthedocs.io/en/latest/api.html#toolz.functo...

"I.e. pipe(data, f, g, h) is equivalent to h(g(f(data)))"

I disagree that the C# example is more readable. Let me just compare your own human-language description of the task with the Python code:

    the total   length    of all strings in a list    that start with the letter 'a'
    sum(        len(s)    for s in strings            if s.startswith("a")          )

Of course that does not necessarily apply in all possible cases, but in this particular example it is practically a 1:1 match. The C# example is a better match with the way one would describe an algorithm:

    From a list of strings    take all strings that start with the letter 'a',    calculate their lengths    and add them up
    strings                   .Where(s => s.StartsWith('a'))                      .Select(s => s.Length)     .Sum()

I personally find the Python's syntax much closer to natural language in most cases, which is why the language has been called "executable pseudo-code".

> I disagree that the C# example is more readable.

You then go on to show that the Python example is closer to the English language. That doesn't prove better readability.

Fair point -- I do generally consider "readability" to be quite a subjective concept, with different people having different ideas of what is more or less readable.

For me personally, code that reads like natural language is generally more readable; however a) I am aware that other people have different preferences, and b) in some cases I also prefer a more "technical" approach.

Not sure what you mean in the 2nd to the last paragraph. I really prefer using the map function:

  sum(map(lambda s: len(s) if s.startswith('a') else 0,['abac','bced','asdasdf','lkjkl','assadf']))

The crazy sql like syntax of your C# example bugs me a lot.

The C# example is much, much easier to read for me than yours. The else specially

> sum(map(lambda s: len(s) if s.startswith('a') else 0,['abac','bced','asdasdf','lkjkl','assadf']))

I'd rather have comprehensions than map and filter that can't fit in pipeline.

> [Yes, type annotations can be extremely useful, but they do not (currently) "fit my brain".]

Why don't they fit your brain? I wonder if the author ever tried statically typed languages.

> I would like for Python 4 to get inspired by Racket and introduce "dialects".

> Having repeat as a keyword as is available in TygerJython and Reeborg's World for the construct repeat nb_steps:. It might perhaps be also useful to have repeat forever: as equivalent to Python's while True: . [Other possible uses of this keyword are described here.]

I don't see how this would be beneficial. You're basically proposing that beginners learn something that is literally not Python - then when they switch to the "main" dialect, they have to re-learn basic things all over again.

Lisps have this neat functionality where you get to basically define your own syntax, and that's really useful in a small set of cases (i.e macros in Racket, super duper useful, would wish C macros were as clean as Racket macros). But Python simply does not fit this mold. It wouldn't do Python any good to have a macro system - and it definitely wouldn't do it good if it has 4 different sub-languages, each of which have it's own syntax and warts.

Stroustrup said "Within C++, there is a much smaller and clearer language struggling to get out." The Python the author is describing is to me, even worse than C++ in terms of complexity.

My Python4 wishes would be to:

- make python packaging as polished as the rest of the language

- modularize the standard library a bit more, so that the precise chunks of battery to be included at install time can be more finely tuned

- start making the all the shiny new features (I grasp the marketing need for MOAR FEETURES!!!) to be library opt-ins. While I'm personally turned on by structural pattern matching, the anti-featuritis crowd has a point, too.

http://python-poetry.org/ solves packaging

I'm OK with getting that into the standard library.

I think having pluggable language features would be nice; on the one hand, you’d keep the “1 obvious way only” people happy- just don’t use it, or come to some agreement with your team - and on the other hand you’d be able to scratch itches for people whose main value for Python is plugging into its ecosystem rather than the language itself. Heck, why limit it to 4 dialects, you could have a whole Babel scenario where you could pip dialect install some nice language feature. I think people would mainly be using this type of feature to reduce mental burdens, for a small buy-in

Author of the blog post here. What you describe can already be done: https://aroberge.github.io/ideas/docs/html/. For example, if you wish to use a new syntax so that you can use Decimal literals, you can install https://pypi.org/project/decimal-literal/.

That's quite cool! Do you think it would be possible to do something really quite crazy, like eta reduction like in Haskell?

Any code transformation is possible to do in theory

> A second dialect would be an "experimental" dialect.

Python already has that in the form of the `__future__` module.

> A third dialect would be a "beginner" dialect. > This beginner dialect would be, in version 4.0, a strict subset of the main dialect. > it might perhaps make sense to eventually introduce a few additional keywords and constructs not available from the main dialect

While I like the idea of the beginners using only a subset of the language, I don't like the alternate keywords; while it might make getting into the language easier for someone coming from another one, I'm afraid it might actually slow down the adoption later on.

In fact nothing (except for the effort required to actually do it) prevents that "strict subset" concept to be introduced in Python as it is, by marking certain features/keywords as "advanced" and adding a flag on the interpreter to throw a warning (or even an exception; there could be two settings) if one is used. That is not unlike the way the -O and -OO flags currently work.

> a fourth dialect would be a "static" dialect

I don't think that this could (or should) be introduced, as it goes directly against some of the Python's basic concepts.

I agree with the post (by ggm) desiring that Python 4 were instead called something else; I think Python 3 should have been something else too.

I would also really like Python 4 to take a different approach to strings; more similar to Python 2.

The native format for strings should be a byte vector, with additional tags denoting if it has an encoding and if that encoding is validated. Coertsion of data type between byte vector and validates string should be automatic, but only performed in contexts that require a type.

Additionally the native type should be either UTF-8 (matching the 96% on the web as of 2021) or WTF8 (Like UTF-8, but encodes invalid byteforms in escape sequences so they round-trip) from Rust.

https://www.w3.org/International/questions/qa-who-uses-unico...

https://simonsapin.github.io/wtf-8/

My wish for python4 is that it isn't called python. I think at this point, language divergence would be more beneficial

Agreed. I would rather just have Nim evolve into a Python successor, alas that doesn't seem too likely.

Han, Nim seems nice. I never heard of it before.

From your post I was under the impression it was a super-set of python, or was compiling down or up to python ( what a weird thing that would be )

I'm getting older, I remember when Python was the new cool perfect language on the block, but that no real job existed using it. Specially outside of tech hotspot before remote.

Well, I think python has been consistent at no sucking too much. And it payed off. Slowly but surely it took hold on the job market, captured data-science overnight.. and voila.

Language are less of an 'blocker' it seams. with infrastructure being a commodity, and polyglot microservices being trendy... nobody care what your API is made off.

So don't loose hope on Nim. ( and it does look really neat, but I promess myself to digg more into Elm before try out something else )

I'm far from a python expert, but I'm a user since a long while now. I never followed closely the dynamic of the community. From my point of view the 2.x vs 3.x was never too much of an issue. The stuff I had to maintain in python were either already dead dev-wise, non-critical, or green-field.

All that introduce my thought while reading : "is it too much too ask?" If the need for having 3 dialects is all is needed in for core python 4... It's a good place too be, no?

My wish for Python 4 is for it to get faster.

There was a proposal on here recently about a guy who wanted to speed it up by like 3x. What happened?

echoing to my other response here. As a outsider to python, but user of the language, that something that would appeal more to me as a first thought that what the article describes.

I do see the value of the dialects proposed. But that sounds more like a nice to have than a core 'new big version number' feature. ( and maybe it was intended this way, I have no idea what's in python 4 roadmap and who makes it )

A perf gain of 6.3 % or something would be a nice looking bullet point on the release-note. And that would drive adoption.. who doesn't want a faster, shinier implementation ? ( me ! )

You should give PyPy a look. It's really amazing if you're writing actual Python code (and not just gluing together libraries). PyPy is to V8 and modern JavaScript engines as Python is to Eich's original JavaScript.

It's also amazing at gluing together your own C libraries.

My wish for Python 4 is to compile to the same IL as Python 3 to be able to mix Python 3/4 libraries, or keep backwards compatibility. Rust showed that it can be done.

Mine : Make the colons optional

Reply on news.ycombinator.com