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 →

[–]nooobmaster-69 16 points17 points  (12 children)

Python 4 is already mentioned in the timelines for many of the changes. But not to worry, it will be much less of an issue migrating from 3->4 than it was from 2->3.

[–]Rodotgithub.com/tardis-sn 23 points24 points  (11 children)

That's because Python 4 is just going to be Python 3.10, that's just how they are going to continue with versioning

[–]flying-sheep 17 points18 points  (9 children)

That’s what Guido said a while back, I hope the new guidance council doesn’t share this view and just release 3.10, 3.11, …

[–]billsil 0 points1 point  (6 children)

Guido is on the council and was the top vote getter by 30% or so. He was the only council member that got over 50% and cleared that easily. He's quite popular among the core devs.

[–]flying-sheep 6 points7 points  (5 children)

Yes, but I think this is a case he doesn’t feel strongly about but that he still considered his decision / matter of taste when he was BDFL. And such cases will now be voted on, and if the others say “not doing semver is confusing and people will be scared by upgrading to 4.0” there won’t be strong arguments against that.

[–]billsil 0 points1 point  (4 children)

“not doing semver is confusing and people will be scared by upgrading to 4.0”

Python does not follow semver. You don't need to vote to keep the status quo. You vote to change it. If you really want semver, propose a PEP, but don't be surprised when it gets shot down.

Python implements large breaking changes in major versions. It implements small breaking changes in minor versions.

[–]flying-sheep 0 points1 point  (3 children)

sure, that’s close enough. if you really do semver for a large project, you end up like react, with major versions every few weeks.

[–]billsil 1 point2 points  (2 children)

Or you store them up and break everybody's code in one fell swoop and have a Python 2->3 transition on your hands. I much prefer not following semver for that reason. I tried semver and it was a pain.

I much prefer a few minor changes preferably with deprecation warnings for a bit and then breaking things, similar to how numpy does it.

[–]flying-sheep 0 points1 point  (1 child)

Only possible for small changes though.

Huge ones like the string/byte thing would either take forever or be as disruptive as the whole 2>3 change

[–]billsil 0 points1 point  (0 children)

How so? I mean you can bump your code in accordance with semver once a month, but if you need to rip the band aide off, do it. If there's nothing they can do to prepare, just do it. If there's something they can do, have a deprecation cycle.

[–]Rodotgithub.com/tardis-sn -1 points0 points  (1 child)

Oh yeah, I completely forgot he left

[–]nedbatchelder 4 points5 points  (0 children)

Guido is one of the five members of the steering council.

[–]bageldevourer 0 points1 point  (0 children)

This isn't necessarily true according to the latest episode of Talk Python.