Personally, I believe that the main branch should support the latest features. If users need to use them, they can opt for previous releases rather than building from the main branch source code. Moreover, the feature support for operating systems should not be deprecated, as they may be removed at any time due to performance issues. WDYT?

I should summon another OS enthusiast, listen to his opinion.

cc@zooba

I'm not too sure what your point is. We're not supporting anything new--we're just removing support for some macros, which have very little maintenace burden anyway. I'm not opposed to removing them if they aren't available on any system that Python can be built for, because then we're just getting rid of code clutter, but I want to be absolutely sure before we do.

If users need to use them, they can opt for previous releases rather than building from the main branch source code.

Rant aside, that's not encouraging. Ideally, we want people to migrate to new versions, not brush people off with "download <3.14 instead if you need to use that."

Moreover, the feature support for operating systems should not be deprecated, as they may be removed at any time due to performance issues.

Sure, but we're awrapper over OS features--we'd be deprecating our wrapper for a feature, not the feature itself.

I'm not too sure what your point is. We're not supporting anything new--we're just removing support for some macros, which have very little maintenace burden anyway. I'm not opposed to removing them if they aren't available on any system that Python can be built for, because then we're just getting rid of code clutter, but I want to be absolutely sure before we do.

I'm almost sure that it doesn't exist in the main branches of Linux and freeBSD.

So my current idea is to wait for zooba answer. I'm not sure whether there is a compatible system similar to netlink in windows.

Edit

So my point is that if there is a compatible system in Windows, then I will turn off this PR. If it does not exist, then this PR can be merged, because we don't need to maintain some macro packages that do not exist.

I'm almost sure that it doesn't exist in the main branches of Linux and freeBSD.

Great, but we support more than just their current main. I get that these macros aren't onmodern systems, but what about the older versions that we support? Will we give a nasty surprise to them with 3.14?

I'll yield to Steve, but I doubt he'll be in favor of dropping support for things without checking to make sure that nobody is using them.

I get that these macros aren't on modern systems, but what about the older versions that we support? Will we give a nasty surprise to them with 3.14?

Yes, that's what I'm worried about, so the PR is a draft. I'm not sure if there is a cpython that migrates the old-system to the main branch.

I searched through Linux kernel sources for these. The most recent version of Linux that included any of these constants was 2.6.17, which was EOL in October 2006. I don't know how much of an afterlife Linux kernel versions have after EOL though.

Thanks for the merge of@gpshead. Here, I know a new OS enthusiast :)