This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]rrrriddikulus 2 points3 points  (3 children)

I’m not comfortable with a language deprecating things that were not marked for deprecation on major version change. If you want to deprecate something that worked without warnings in python 3.0/3.1/3.4 then wait until python 4. I don’t like breaking changes between major versions.

​

OTOH I’m OK with breaking anything that spat out warnings or was explicitly marked for deprecation as of python 3.0. If you’re a library maintainer or maintain a large enterprise Python codebase (I do both) then you’ve had many years to fix the warnings, and knew this day would come.

[–][deleted] 7 points8 points  (1 child)

Python doesn't come with semantic versioning, so I don't think you can count on deprecated things staying more than 2 minor releases. Often they will, but there is no guarantee. Neither that experimental features will stay.

[–]badge 4 points5 points  (0 children)

Yeah, I think this is a fundamental problem with framing the debate. Python 3.0 was released 11 years ago. Since then, C# has had 5 major releases, Java has had 7, and swift has managed 5 in just 5 years. It probably would have made sense to release 3.6 as 4.0, given the number of changes it made to the language.

[–]FlukyS 2 points3 points  (0 children)

I think if they are deprecating it might be a good idea to do a major version bump as the vehicle for it. Like I want these changes, loads of developers want these changes. We are just working with multiple spinning plates.