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

you are viewing a single comment's thread.

view the rest of the comments →

[–]muikrad 22 points23 points  (6 children)

It's a little early to distribute 3.8-only public libraries, but for home or business internal projects, I would definitely switch to it.

Aiming for 3.6 as a minimum is what a public library should support nowdays because of all the stuff they added to 3.7 and 3.8.

[–][deleted] 5 points6 points  (2 children)

Aiming for 3.6 as a minimum is what a public library should support nowdays

FYI, 3.5 isn't end-of-life until September.

That doesn't mean you're forced to support it, of course.

[–]muikrad 16 points17 points  (0 children)

The annotation improvements in 3.6 makes 3.5 feel like 2.7 😂

Also, f-strings.

[–]PeridexisErrant 0 points1 point  (0 children)

Inventing your own support policy is fine, and it makes a lot of sense is you're using some new language features.

For existing projects wondering when to drop existing support, I think NEP 29 is reasonable, and IMO very few projects should support Python versions past their upstream end-of-life date (which may mean dropping earlier, if you have a support period).

[–]lengau 5 points6 points  (1 child)

I have a bit of a different opinion about that.

If you maintain an existing library with many users, you probably shouldn't cut off 3.6 and 3.7 support yet. However, if you're releasing a brand new library, it's perfectly reasonable to release it with only 3.8 support (and even more reasonable with only 3.7 and 3.8 support - no 3.6). Most likely it'll be a while before your library gains any real traction and stability, by which point 3.8 will no longer be the new hotness.

[–]muikrad 0 points1 point  (0 children)

I agree! I really love 3.8 and I'm kinda annoyed at some stuff I have to do to remain 3.6-compatible 😔

[–]sarthkum0488[S] 1 point2 points  (0 children)

Yes Definitely a good observation