My Wish for Python 4 (aroberge.blogspot.com)

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

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

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?

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/

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

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.

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.

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

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

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

    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()

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

> [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 wish for Python4 would be please never exist.

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

Mine : Make the colons optional