|
|
Subscribe / Log in / New account

Alex's approach

Alex's approach

Posted Jun 27, 2024 18:59 UTC (Thu) by pizza (subscriber, #46)
In reply to: Alex's approach by mb
Parent article: Python grapples with Apple App Store rejections

> Apple *clearly* caused the breakage. That's why they should care.

Why would Apple care about squishing an ant as they walk?


to post comments

Alex's approach

Posted Jun 27, 2024 19:04 UTC (Thu) by mb (subscriber, #50428) [Link] (5 responses)

It's their decision. No (apps with) Python for Apple users then. I don't see why this is Python's problem.

Alex's approach

Posted Jun 27, 2024 19:55 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (4 responses)

Reality is that it's Python's users' problem, and projects have a tendency to listen to their users' problems, and do something about them.

Alex's approach

Posted Jun 27, 2024 20:15 UTC (Thu) by mb (subscriber, #50428) [Link] (3 responses)

Sure. Many Projects tend to put workarounds everywhere instead of really fixing things.
Happy whack a mole.

Users must complain to Apple. They broke Python.

Alex's approach

Posted Jun 28, 2024 9:04 UTC (Fri) by NYKevin (subscriber, #129325) [Link] (2 responses)

That is not what will realistically happen. What will happen is that everyone who wants to run Python on iOS will get a rejection the first time, Google it, discover the problem, write and carry their own patch, and submit a modified application without this string.

Or CPython can fix it once and we can all move on with our lives. IMHO the easiest solution is to just drop the string from urllib altogether - it's there to support Apple devices in the first place. Apple doesn't want it there? Fine, it's gone. Good riddance.

Alex's approach

Posted Jun 28, 2024 15:43 UTC (Fri) by mb (subscriber, #50428) [Link] (1 responses)

>Google it, discover the problem, write and carry their own patch

That's Ok. They decided to play by the rules of Apple. So they should carry the workaround for Apple's stupid decisions.

Why should Python care?

>Apple doesn't want it there? Fine

Yes. It's fine. It's their decision and their problem.

>Fine, it's gone. Good riddance.

Do you realize that this is not a fix of the actual problem?
Apple will append something else to the list of forbidden words tomorrow.

Why should we let Apple indirectly make stupid decisions for an independent Open Source project?

Alex's approach

Posted Jun 28, 2024 18:53 UTC (Fri) by NYKevin (subscriber, #129325) [Link]

The question is not why Python should care about iDevices. The question is why Python should care about the Apple ecosystem at all. itms-services is not a standard protocol. It appears in no RFC (that I've ever heard of). It is purely an Apple thing. And now it is causing problems, that were also created by Apple.

Why should Python even waste time thinking about any of this? Just yeet the whole thing out of urllib, and Apple developers who want to use this protocol for whatever reason can take a PyPI dependency.

But you don't even need a PyPI dependency, because urllib already DTRT on protocols it does not understand:

>>> urllib.parse.urlsplit('nonsense://www.example.com:80/foo/bar')
SplitResult(scheme='nonsense', netloc='www.example.com:80', path='/foo/bar', query='', fragment='')

The string itms-services only appears in a list that tells the parser that it "uses netloc" (i.e. it should have a netloc part after the scheme, unlike say file://). As you can see above, it will happily parse nonsense schemes with netloc even if they are absent from said list. So at most, this might get you stricter checking in a few corners of the API, but it is probably not a showstopper.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds