Best just not to depend on Apple’s installed scripting languages for your own purposes. It’s used by and for the system, not users. Many people have been misled and misinformed about that.
A few things:
-
I feel quite comfortable with installing Python3 with or without homebrew; I will likely go with brew just because it’s so much easier and well packaged. I would not remove the current 2.7 version of Python since there may still be a few things in MacOS that use it (at one time, many of the print services had Python underneath, but that seems to all have been eliminated at this point). Also my current scripts are written to Python 2.7, and I would not remove it until I had everything upgraded and running under Python 3.
-
Yes, I am wondering about whether pyobjc will be upgraded with Catalina or not. It’s sort of a moot point, as I have noticed that there are components right now in MacOS frameworks that are not present in the current implantations (for example, the printing classes of AppKit do not seem to be fully represented in the AppKit loadable into python). As a result, I think that for tasks that are not “native” to Python I will likely have to look elsewhere, and I have decided it’s time to learn Swift and write things as necessary in Swift.
-
I disagree with the concept of NOT using scripting languages to support my personal tasks. I have a lot of scripts in Python that support operations in Hazel, Alfred, and Keyboard Maestro not to mention some that are run as independent programs at the command line for various tasks (for instance, when QuickBooks stopped being able to import data directly from the bank my business uses, I wrote a program in Python to translate the downloaded CSV transaction data in the the Intuit Interchange Format (IIF) for importing into QuickBooks. There is no reason I can think of why I should not continue to use that program in Python under future versions of MacOS, unless they throw away the Darwin underpinnings and no longer work as a Unix-like system at the command line.
-
I recognize that some of my scripts will need updating for new versions of the OS. For example, since Finder tags are not scriptable in AppleScript or JXE, I have written my own Python module to handle them (presently using mdls, xattr, xxd , and plutil under the hood, but possible I will rewrite using the xattr python module. I anticipate the need to update this script for Catalina (as I did for Mojave). Just part of the upgrade process for me, unfortunately. Even if I wrote this module in Swift, there is the change that the API will change and I would have to do upgrades with a new version of MacOS.
If you are pointing at my comment, I said “Best just not to depend on Apple’s installed scripting languages for your own purposes”… implying amongst other things, if you find you need to upgrade Apple’s stuff to suit your own needs, things might break. And given there is no need to mess with Apple’s stuff like that, then why do it?
Just my two bits.
Absolutely correct! If I understand correctly, MacPorts facilitates this without the need for virtual environments (HomeBrew does not). That’s not to say that virtual environments aren’t useful.
Apparently no longer, since they are being removed!
I totally agree, however as @Wolfie has already pointed out, the Apple-installed versions are always out of date. Earlier in this thread, @tjluoma noted that the licensing for bash does not allow Apple to include the latest version with MacOS, I wonder if the same is true for Python, Perl, Ruby, etc.
Hopefully they won’t remove ruby entirely, or it will be harder to get brew to install (although I’m sure they would figure out a work-around soon enough).
I would think some of these languages may be packaged with, or as addons too Xcode.
I’m sure someone will come up with a curl script that will take care of any legwork involved in getting homebrew setup.
True that. I ran into major issues when trying to get things set up on my computer for a Digital Humanities workshop back in May. I did finally get things working, but by the end of the process I could really relate to this XKCD strip:
1 Like
That was SO my experience! 
Hmm. ls -l /usr/bin/py* in Catalina (most recent beta):
lrwxr-xr-x 1 tom staff 74 Jun 30 07:36 pydoc → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/pydoc2.7
lrwxr-xr-x 1 tom staff 74 Jun 30 07:36 pydoc2.7 → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/pydoc2.7
lrwxr-xr-x 1 tom staff 75 Jun 30 07:36 python → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 tom staff 82 Jun 30 07:36 python-config → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
lrwxr-xr-x 1 tom staff 75 Jun 30 07:36 python2 → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 tom staff 75 Jun 30 07:36 python2.7 → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7
lrwxr-xr-x 1 tom staff 82 Jun 30 07:36 python2.7-config → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/python2.7-config
-rwxr-xr-x 1 tom staff 31456 Jun 30 14:07 python3
lrwxr-xr-x 1 tom staff 76 Jun 30 07:36 pythonw → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
lrwxr-xr-x 1 tom staff 76 Jun 30 07:36 pythonw2.7 → …/…/System/Library/Frameworks/Python.framework/Versions/2.7/bin/pythonw2.7
Ruby is there too. As is Perl. But old versions.