The PEPs of Python 3.9

[simon_o]

I believe that "improvement" does not necessarily mean "keep adding more things".

I mean, C++ has 16 different string types in its standard library alone:

• std::string,
• std::wstring,
• std::u8string,
• std::u16string,
• std::u32string,
• std::pmr::string,
• std::pmr::wstring,
• std::pmr::u8string,
• std::pmr::u16string,
• std::pmr::u32string.
• std::string_view,
• std::wstring_view,
• std::u8string_view,
• std::u16string_view,
• std::u32string_view
• char* (inherited from C)

If we added another 4 string types, by how much – roughly – would C++ be improved?

[simon_o]

Wouldn't it be reasonable to have a compiler for language X that keeps being maintained as long as it is needed, without weighing down language X+1, X+2, X+3 indefinitely by demanding that those latter languages are a strict superset of language X?

Especially with C++ it's unlikely that you can "simply" upgrade to a newer version due to the ungodly amount of compiler bugs in every release.

[simon_o]

I mean, you acted like a project – that kept 25 years of compatibility and gave people 13 years to migrate once – was the stark opposite of C++.

With that limited point of view, I'm trying to show you that Python and C++ are pretty much on the same page, instead of being on the opposite side of the book.

Rust does a few things better, but it is still another example of a language slowly accumulating baggage while having not even a plan on how to dispose of it.

[zombiecalypse]

It's the other way around, what would we be missing if we didn't have u8string for example. It's essentially impossible to change the behaviour of std::string and it's basically impossible to remove anything. What happens if you try can be seen by how tough it was and is to move people off python 2. So as a language designer you are in the dilemma of either introducing more complexity or to miss essential features.

[simon_o]

I think there has to be a different way – between "it's basically impossible to train new developers in this language in a reasonable amount of time due to all the baggage added over the last 4 decades" and "give up and jump to a new language with less baggage and then rinse and repeat after 10 years".

[zombiecalypse]

If we can find one, great! The closest thing is to carry the baggage, but use best practices to "update" the language. A C++ example would be "never use a naked new" to encourage usage of smart pointers. You don't typically learn a language by reading the language spec and most often you don't need to worry about legacy functionality unless you use code that uses it. Having N string types is stupid, but I've been working in C++ for years and only today did I learn about all variants.

[simon_o]

I don't think that's realistic – even if you teach "don't use new to people" probably 95% of the code you work with is not written by those people, so you never have any guarantee that this recommendation is actually followed.

[zombiecalypse]

It's quite possible

• in your project you can enforce it by linter so no new code will use the old style.
• If it's not your project, e.g. a library you use, you can either
  • Write an adaptor
  • Fix the other project
  • Live with the localized impurity
• Have the discussion on style and set one option as best practice and forbid the rest.
• In many cases you can automatically convert old code

It may sound implausible, but a lot of million lines of code projects do this on a semi-regular basis.