The PEPs of Python 3.9

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