python macOS Monterey 12.3 killed python — now what? 🐍

[Chris Messina]

While there is documentation about the removal of Python in macOS 12.3, I wonder if it would make sense to provide a link to this documentation in the context of this error message? Furthermore, it may make sense to catch these errors on macOS 12.3 and provide a specific error to explain to the user what caused this? Otherwise I think many users will be angry/frustrated at Alfred and won't know what to do next. 

FWIW, the performance of the scrolling section of this dialog is also very slow/laggy for me... not sure why.

 

Lastly, it seems like, in addition to a redesigned error message as suggested above, it might make sense to add a link to Alfred's documentation about the demise of python when someone selects the [not installed] language here:

 

 

[scottpie]

Oh crap, is THIS why suddenly none of my online-based workflows are working? Yikes!

[vitor]

@scottpie For an explanation and fixes, see: 

 

[scottpie]

Thanks!

[Meow]

[rant]

I'm kind of furious that this is happening. Python3 was a standard for multiple years. Apple warned in 2019 that Python2 is going away. Why Alfred developers didn't include a solution years ago? They are coming up with new versions. What was the hold up?

 

The reason I'm up set is that my custom workflows stopped working and I need to fiddle with some external text files to make myself productive again. I have a multi-computer setup and  I really liked the fact that all workflows were synced automatically. 

 

What do I do now? Install Raycast?

[/rant]

 

Why can't we just include /usr/bin/python3 in the drop down?

Edited May 31, 2022 by Meow

[vitor]

Just including /usr/bin/python3 in the dropdown wouldn’t have changed the situation. You don’t need the dropdown to use a language. You never did. Most popular Python 2 Workflows don’t use the dropdown to call Python 2 (I should know), they use /bin/bash or /bin/zsh and call python from there. Developers have been able to use Python 3 in Workflows for a long time, and several do: @Acidham is my go-to example of someone whose Workflows have been in Python 3 long before the Apple deprecation.

 

I don’t understand the point about external text files and syncing Workflows. You can add any file to the Workflow’s folder and those will sync too, that’s expected and the proper way to set up Workflows. You reference them via their relative path.

 

I can try to help you with whatever is tripping you up, but I need a specific question to know where you’re having issues.

[wolph]

@vitorWhile those methods do work, on my system it appears to be significantly slower than the old Python integration (at least for the first run).

 

I don't understand why `/usr/bin/python3` is not included as an option though. That's been available for several OS X versions already.

[vitor]

1 hour ago, wolph said:

(at least for the first run)

 

That’s the important bit. Executables always run slower the first time because macOS does checks when that happens. Those are outside of Alfred’s (or any app’s) control. Speed-wise, it makes no difference to run the script from the dropdown or a previously saved file. The dropdown method is essentially saving the script and running it.

It is possible for your Python 3 code to be slower than the Python 2 counterpart. Even by official benchmarks, Python 3 started off slower. Not sure what’s the current state, but remember /usr/bin/python3 is itself behind the current release by a few years.

 

1 hour ago, wolph said:

That's been available for several OS X versions already.

 

Thing is, it hasn’t and still isn’t. If you have it you won’t notice, but run /usr/bin/python3 on a fresh macOS install and instead of the code running you’ll be greeted by macOS asking you to install the developer tools. Just like /usr/bin/swift, /usr/bin/python3 is a shim. That’s why many Python Workflow developers—despite not using the dropdown to invoke Python—still chose to go with Python 2; it was a better experience to the user and many were expecting Apple to eventually make Python 3 available, not to remove languages.

 

This isn’t to say /usr/bin/python3 shouldn’t or won’t be available in the dropdown, it just means simply throwing it in haphazardly wouldn’t have been a good approach. With Apple finally removing languages, the dropdown itself has improved: historically it only included languages which were really there, installed on the system by default, but it now detects Homebrew installs of the previously-included languages and is thus in better shape to support more. That doesn’t mean it makes sense to include any and all languages, though. Languages like node and lua would be tougher sells, because you can’t expect any user to have ready access to them when sharing your Workflow.

[wolph]

1 hour ago, vitor said:

That’s the important bit. Executables always run slower the first time because macOS does checks when that happens. Those are outside of Alfred’s (or any app’s) control. Speed-wise, it makes no difference to run the script from the dropdown or a previously saved file. The dropdown method is essentially saving the script and running it.

 

That's not entirely true though. Right now it has to run both zsh and python instead of just python. Perhaps there is a different way of running it that I'm not aware of, but right now I don't see any way around running both of them. The external script option does not work because that does not support argv for some reason.

 

1 hour ago, vitor said:

It is possible for your Python 3 code to be slower than the Python 2 counterpart. Even by official benchmarks, Python 3 started off slower. Not sure what’s the current state, but remember /usr/bin/python3 is itself behind the current release by a few years.

 

 

Good point, to check I've done a little benchmark but I'm not noticing any meaningful difference here:

$ for i in /usr/bin/python3 /usr/local/bin/python[0-9].[0-9]{,[0-9]}; do time $i -c 'import sys;print(sys.version)'; done
3.8.9 (default, Oct 26 2021, 07:25:54)
[Clang 13.0.0 (clang-1300.0.29.30)]
$i -c 'import sys;print(sys.version)'  0.03s user 0.01s system 92% cpu 0.038 total
2.7.17 (default, Oct 24 2019, 12:57:47)
[GCC 4.2.1 Compatible Apple LLVM 11.0.0 (clang-1100.0.33.8)]
$i -c 'import sys;print(sys.version)'  0.01s user 0.01s system 90% cpu 0.030 total
3.7.13 (default, Mar 16 2022, 20:46:34)
[Clang 13.0.0 (clang-1300.0.29.30)]
$i -c 'import sys;print(sys.version)'  0.02s user 0.01s system 89% cpu 0.035 total
3.8.13 (default, Mar 16 2022, 20:38:02)
[Clang 13.0.0 (clang-1300.0.29.30)]
$i -c 'import sys;print(sys.version)'  0.02s user 0.01s system 90% cpu 0.035 total
3.9.12 (main, Mar 26 2022, 15:52:10)
[Clang 13.0.0 (clang-1300.0.29.30)]
$i -c 'import sys;print(sys.version)'  0.03s user 0.01s system 91% cpu 0.037 total
3.10.4 (main, Apr 26 2022, 19:43:24) [Clang 13.0.0 (clang-1300.0.29.30)]
$i -c 'import sys;print(sys.version)'  0.02s user 0.01s system 91% cpu 0.033 total

 

 

1 hour ago, vitor said:

Thing is, it hasn’t and still isn’t. If you have it you won’t notice, but run /usr/bin/python3 on a fresh macOS install and instead of the code running you’ll be greeted by macOS asking you to install the developer tools. Just like /usr/bin/swift, /usr/bin/python3 is a shim. That’s why many Python Workflow developers—despite not using the dropdown to invoke Python—still chose to go with Python 2; it was a better experience to the user and many were expecting Apple to eventually make Python 3 available, not to remove languages.

 

 

Oh wow... I wasn't aware of that. I stand corrected.

 

In that case I think I'll just switch over to /usr/local/bin/python. If the user is required to install something anyway, it might be better to go for this.

 

With regards to languages in the dropdown, it would certainly be nice of alfred would include more options. As can be seen in the benchmark above, I've got half a dozen python versions available and the dropdown doesn't show any of them. Having /usr/local/bin/python3 or /usr/bin/python3 at the very least would be an improvement.