Strip the functionality altogether.

Posted Jun 27, 2024 14:45 UTC (Thu) by pavon (guest, #142617)
Parent article: Python grapples with Apple App Store rejections

I'd question whether something like itms-services scheme support really belongs in a standard library to begin with. That is a pretty niche functionality for a single operating system. Most python software running on macOS will never use it, just things like installers. There isn't equivalent support for the dozens of Windows-specific schemes that Microsoft uses.

Obviously, you'd need to give time to deprecate it, so another work-around would be needed for the short-term, but in the long-run if Apple wants to make it hard to integrate with their platform, then stop supporting those integrations and let application developers use a third-party library.

Costs vs Benefits

Posted Jun 27, 2024 16:35 UTC (Thu) by nickodell (subscriber, #125165) [Link] (1 responses)

I think that when asking whether to remove it, we should ask what the cost of the feature is. If you look at the PR which adds this support, excluding tests, it is added in one line of code. (https://github.com/python/cpython/pull/104312) This seems like pretty minimal maintenance burden.

Costs vs Benefits

Posted Jun 27, 2024 20:26 UTC (Thu) by pavon (guest, #142617) [Link]

The cost was negligible, until Apple decided to make it more expensive by requiring different behavior and thus different builds depending on how the user installed the app.

Strip the functionality altogether.

Posted Jun 28, 2024 15:21 UTC (Fri) by smurf (subscriber, #17840) [Link]

> I'd question whether something like itms-services scheme support really belongs in a standard library to begin with.

Well, this one's easy.

Some URL schemes contain a network location ("netloc"). Some do not.

People tend to expect the URL parser to reply with a struct that breaks out the netloc for URLs that contain them.

As urllib.parse contains a whitelist of URLs with netlocs (sensibly IMHO) it needs to contain this string.