4 ms·
While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now: % /usr/bin/python WARNING: Python 2.7 is not re
by mrsuprawsm 5y ago
While the warning shows for python2, it doesn't show for python3, implying that it's here to stay for now:
% /usr/bin/python
WARNING: Python 2.7 is not recommended.
This version is included in macOS for compatibility with legacy software.
Future versions of macOS will not include Python 2.7.
Instead, it is recommended that you transition to using 'python3' from within Terminal.
Python 2.7.16 (default, Mar 25 2021, 03:11:28)
[GCC 4.2.1 Compatible Apple LLVM 11.0.3 (clang-1103.0.29.20) (-macos10.15-objc- on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
% /usr/bin/python3
Python 3.8.2 (default, Dec 21 2020, 15:06:04)
[Clang 12.0.0 (clang-1200.0.32.29)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>>
- deleted 5y ago[deleted]
- _wldu 5y agoPython is to Unix/Linux/Mac what PowerShell is to Windows. It's here to stay.
- jbverschoor 5y agoNo it’s not. And it won’t
- cortesoft 5y agoI am pretty sure bash is the powershell of Unix/Linux/Mac
- syshum 5y agobash is more akin to cmd/batch then Powershell. there is a TON more you can do with powershell than you can with bash. Plus object pipelines are superior to text pipelines You can also install Powershell on Linux. So I would say Powershell is the Powershell of Linux
- mishac 5y agoyou can install bash on windows too.
- flukus 5y agoI don't think powershell is even the powershell of windows. You get some of the better sysadmins using it, but working in the c#/windows world I see developers rarely touching powershell, certainly nowhere near as often as you'll see Linux develops writing a shell script. I wouldn't be surprised if C# was more used for "scripting" purposes than powershell, it usually ends up shorter and more readable anyway.
- suprfsat 5y agoThat's because it's not part of the base OS: % /usr/bin/python3 xcode-select: note: no developer tools were found at '/Applications/Xcode.app', requesting install. Choose an option in the dialog to download the command line developer tools.
- Wowfunhappy 5y agoNote how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all. I don't like how Apple handles this. If you have the developer tools installed, it's not especially obvious what is part of those tools and what is actually bundled with the OS. And so it's not surprising that some scripts I've come across will silently break in semi-odd ways without the dev tools. Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense?
- kbenson 5y ago> Note how despite not coming with the OS, `python3` is still placed in the Apple-only `/usr/bin/` directory. And a binary exists at that path either way, it's just a stub by default. Because none of this is confusing at all. There's long been problems with this on UNIX systems. For a long time there's generally been three categories of software to track (OS provided, third party managed, manually compiled/installed), and two different locations to put them (/usr, /usr/local. / is different and has/had other constrains and reasons behind usage). OS provided packages go into /usr, stuff a user manually compiles and installs goes into /usr/local, but where does a third party package manager put stuff? It's not OS provided, but it is packages and maintained, so /usr seems valid. At the same time, it's user installed, so /usr/local seems valid. Both make the other used of those locations more complicated to reason about. > Also, why is Python a developer tool, but Perl isn't? Or ZSH, for that matter? Does the distinction actually make any sense? Possibly because some are used by the OS to actually do things for the OS (not sure if Apple finally got rid most those dependencies or not). The problem of the OS shipping a component for it's own needs that gets used by others is a decades old problem at this point. It's complicated because if it's available users to use, they'll use it, and when the OS wants to update or change it in some way it can break user assumptions. If users update it system wide, they can break OS assumptions.