We should also make sure that these slight (and potentially frustrating-to-debug) differences in stdlib functionality are documented, too.
3 Likes
This would work:
>>> import dis
>>> dis.dis('"secivres-smti"[::-1]')
0 0 RESUME 0
1 2 LOAD_CONST 0 ('secivres-smti')
4 LOAD_CONST 1 (None)
6 LOAD_CONST 1 (None)
8 LOAD_CONST 2 (-1)
10 BUILD_SLICE 3
12 BINARY_SUBSCR
16 RETURN_VALUE
This is the kind of paint choice I’d leave entirely up to those who even know how iOS builds are done in the first place (not me). Questions I don’t know the answer to and don’t really need to myself: Does it even use autoconf? Isn’t it effectively detectable at build time because the builder already know the platform being built for by then? 
That sort of construct is risky though because it could easily be broken by future changes to the compiler; there is no reason we could not compile that code to just LOAD_CONST "itms-services".
It’s actually somewhat surprising to me that we don’t, since other binary operators are generally optimized in the compiler.
4 Likes
Is there no option to just talk to Apple about a more automated exception process here?
This all seems kind of roundabout to get to the point. This is Python, they’ve heard of it. Find the right people and I’m sure it can be figured out with minimal changes.
Having differences in functionality between app store versions and python.org is suboptimal.
1 Like
In short? No.
I’m guessing you’ve never tried to submit an app through Apple’s App Store processes. Their review processes are famously opaque and inscrutable. Experienced developers with high profile apps that have been published for years sometimes get minor app updates rejected with no particular explanation or reasoning. They do not discuss details, and they don’t have a higher authority to appeal to.
Yes, Apple knows that Python exists; however, that doesn’t translate into an active relationship between Apple and the CPython core team (at least, not one that I’m aware of). FWIW, if there’s any Apple engineers who are interested in such a relationship, I for one would welcome that development.
6 Likes
To be clear: the original report was with the macOS App Store, not the iOS App Store. Since that report, I’ve had an independent report that the same problem exists for the iOS store (which isn’t surprising).
Your point about -patch is reasonable, though. I’d add that although we’re currently only aware of a patch that is needed for macOS and iOS, if such a requirement were to emerge for another platform (e.g., for Android), it might be useful to have a generic “apply known patches” mechanism.
So, with bike shed brush in hand, I’d suggest --with-app-store-compliance that interacts with platform identification to work out which patches are required.
1 Like
Agreed. At the very least, we need to document the new configure option; it would also make sense to include a warning in the patched function(s), and a note in the platform guide that the configure option exists and may be required for some uses.
Agreed - and there’s no guarantee that Apple, upon learning that this is what Python is doing (since the code and this discussion is in the open), wouldn’t add i!t!m!s, smti, and any other potential variants to the ban list. That why I think patching is the better option.
1 Like
It would also cover us if Windows or any other app store ever needs similar shenanigans, so +1 for that spelling from me. (Edit: although Windows is a bad example, since that build doesn’t use autoconf)
If you’re not publishing through a platform’s official app store you may not care to jump through hoops that only exist as part of the app store’s review process.
Target platform detection is a valid reason for using a platform independent name for the config flag, though.
Thanks to everyone for the input; I’ve just submitted #120984 to implement the --with-app-store-compliance option.
5 Likes