3 ms·
It’s very much an “or” situation from a practical standpoint. Maybe not exclusively or, but it’s unrealistic to say one does not significantly affect the other.
by uranusjr 5y ago
It’s very much an “or” situation from a practical standpoint. Maybe not exclusively or, but it’s unrealistic to say one does not significantly affect the other. Python core dev (CPython or otherwise) is already thin on resource for a long time, and you can’t just keep adding things without cleaning up old cruft. Parties most involved in development of the Python language (CPython devs, the Steering Council, etc.) value sustainability most, so it makes sense they decide to drop old stuff when they see no need of it. On the other side, parties that value stability more (e.g. libraries authors) need to actively lobby their goals to the core devs so they can assess the situation correctly and find the right balance between the two. You can’t just sit there and expect people to understand your needs; you have to tell them, which is what pydantic failed to do in this situation.
- BiteCode_dev 5y agoThere was an even smaller team in 2.X, and 2.X broke less stuff while still providing new features. So no. It's a matter of product vision here.
- uranusjr 5y ago> 2.X broke less stuff while still providing new features. By putting off all the cleanups to Python 3. I think I like their current approach better.
- BiteCode_dev 5y agoPython 3 was necessary for cleaning. Having default new style classes, super() and so on are goodies, not necessities. It was necessary for the things that are were not easy to do without breaking compat such as unicode, fixing comparison bugs, etc. Now none of the stuff that broke compat in 3 after the initial release were things that were necessities. They were goodies. You don't need make from __future__ import annotations as default. You don't need to make async/await keyword.
- uranusjr 5y ago> You don't need make from __future__ import annotations as default. You don't need to make async/await keyword. By the same logic unicode_literal and print_function should have never been the default? Yeah I guess you can make that case, but I’m not in your camp. Sorry, goodbye.
- BiteCode_dev 5y agoI literally wrote "It was necessary for the things that are were not easy to do without breaking compat such as unicode"
- aflag 5y agoI see the point that unicode_literal being quite important, but what about print_function? How does it make coding more difficult or awkward?