Apple Finally Removing Python 2 In macOS 12.3 (macrumors.com) 70
Apple will no longer bundle Python 2.7 with macOS 12.3, according to developer release notes for the upcoming software update. MacRumors reports: Python 2 has not been supported since January 1, 2020 and no longer receives any bug fixes, security patches, or other changes. Apple says that developers should use an alternative programming language instead, such as Python 3, but it's worth noting that Python 3 also does not come preinstalled on macOS. Developers can run the stub /usr/bin/python3 in Terminal, but it prompts users to install Xcode developer tools, which includes Python 3.
Re: (Score:2)
That said, why do they insist on using the Python 3.x series for it too is a bane that must be vanquished!
Python—of any variety—isn't installed by default. Developers either need to install the XCode CLI tools before they'll get Python 3.
Re: (Score:3)
Re: (Score:2)
Over 15 y ago I wrote a kernel driver and I distributed it as a macOS package. I had to run custom logic to install/uninstall the files, the simplest for me was to write the logic in Python. It was either that or doing it in Posix compliant shell, PITA, or write an installer/uninstaller in ObjectiveC.
That made sense at the time, I have no idea what is common to do these days as hooks in the pkg installers.
Re: (Score:2)
Python _always_ was installed by default.
That is why we have this _news_!!
Because _now_ it is no longer installed by default.
Developers either need to install the XCode CLI tools before they'll get Python 3.
Nope. You simply download it from python.org, or install homebrew and type "brew install python 3" or you install Anaconda.
Re: Almost good news. (Score:1)
This is true but recall that in order to install homebrew, youâ(TM)ll still need to install the Xcode CLI tools. I use that approach: CLI -> brew -> pyenv -> python -> pip
This said, my comment above is playing the devilâ(TM)s advocate, and I personally donâ(TM)t see why having to install the CLI tools would be a problem, especially given that it is a painless process.
As you point out, there are many other ways to install python for those not versed into terminal too (eg, anaconda,
Re: (Score:3)
That was the choice I had about six years ago when it would have taken thousands of man-hours to reinvent all those wheels. I've not had need of Python for a few years though my thinking is that most of those wheels would have been upgraded by now.
Re: (Score:2)
That's kind of a real world thing. You choose a third party library and are stuck with it. The people with the money aren't paying you to constantly be trying out new libraries, or upgrading libraries if nothing is broken. My guess is that the Python 2.7 that the third party library ues in one script does not get fixed until it's a major emergency. I literally cannot do this unilaterally before unless I do it on my own time and get the test team to agree to test it on their own time.
If this was part of
Forget it Darinbob (Score:2)
It's Slashot.
Re: (Score:2)
Which is incidentally the website with the voting system that has the least amount of abuse. If one would think this bad, one should try Reddit, Youtube, or Hacker news and see completely on-topic responses that are both insightful and factually undeniably correct receive heavy downvotes.
I do not understand why such a system needs to exist, so that these comments can be hidden? I rarely ever see a comment below -1, so it's not as though they take up sufficient space and if one put the filter at -1, or 0, o
Re: (Score:3)
Seriously, what sort of mindset waits until their language is firmly entrenched in the enterprise and then decide to change the language in a way that breaks backwards compatibility?.
The same kind of mindset that doesn't get scoping right until release 2.2 [python.org].
In short, amateurs - people who think there is nothing of value in the programming language literature because that theoretical stuff is potentially confusing, and hence non-Pythonic.
Re: (Score:2)
Ha, I remember Larry Wall telling me "You computer scientists are all the same..." just because I pointed out that a symbol table can keep track of types without having to have special characters are prefixes. Ok, I was being snarky at the time, and Perl is a great language that I used a lot.
Re: (Score:2)
I find myself agreeing. — Python is mismanaged from both a language design and business perspective in inexcusable ways, and yet is very popular, but Perl also became very popular back in the day when it became known as a write-only language due to generating unreadable code. These examples to me show how popularity has little to do with quality. Some might argue that simplicity leads to popularity, but Rust also became very popular very quickly and is noted to require a certain theoretical foundatio
Re: (Score:2)
Re: (Score:1)
You are welcome to run RHEL where it will be supported until 2024. That being said, it's not like they dropped this on anyone by surprise, we've had over 12 years of advance notice. Granted you couldn't actually do much with Python 3 back in 2008. But by the mid-2010s Python 3 was well supported by all the major libraries you need for Python to be useful. The real mistake people made was using python for long-lived projects in the first place. For LTS you are far better off with any number of crusty boring
Re: (Score:3)
It does not matter how much notice there is. For either corporations no private people that use it in scripts on their home box, it is simply not attractive to have to trace every single Python script they ever wrote and update it for 3, which is both work and can introduce regressions.
And yes, in light of that Python does this, in hindsight it was a mistake, but no one could have expected them to be so, frankness be, stupid 15 years back.
Re: (Score:2)
Code written for 32 bit? Gotta port it now to 64 bit or won't work.
Code written for PowerPC? Gotta port it now to x86.
Code written for x86? Gotta port it now to ARM.
Code written in Objective-C? Gotta re-write it now in Swift.
Code written in OpenGL? Gotta re-write it now to Metal.
Code written in Carbon? Gotta port it to Cocoa.
Re: (Score:2)
Porting your code from one architecture to another should be a trivial recompile if the code is properly written in the first place. I have a bunch of old C code that was written for VAX and still compiles and runs today on architectures that didn't even exist when the code was written.
Re: (Score:2)
And some of it's a complete re-write in a new language. Objective-C to Swift, OpenGL to Metal, these won't be simple re-compiles.
Re: (Score:2)
The biggest value of 3 is that 2 is dropping support; that is the biggest incentive to switch. This does not even considered that most of the new features could have been backported to 2.7, but weren't to incentive to switch, and the use of unicode throughout in many ways also makes things more difficult since many things use unicode that really should be using bytes because they interact with the outside world and have no guarantee to be receiving unicode data.
Python 3 programs tend to crash when being p
Re:Almost good news. (Score:5, Insightful)
It was such a shame that python refused to at least have backwards aliases for a lot of things. Little things like if you wanted memory-efficient numeric counter you had to use 'xrange' in 2 and 'range' in 3, with 'xrange' not even being allowed. Various modules being renamed to be consistent style (good I suppose) but the old names not provided at all. If not for things like that, it would be much easier to do python 2/3 compatible code (having to be explicit u'' and b'' strings, using the specific except syntax that is compatible with both, etc.
Of course, python 3 has fun surprises in the core libraries. "New in 3.6, deprecated in 3.7, to be removed in 3.11" things happen so that you can't even assume a new 3.y core can run code written for 3.x. The language's maniacal focus on 'one way to do it' really screws thing up when they decide the 'one way' was wrong later and try to burn the old way to the ground as they produce a new way.
Re: (Score:2)
If only you could do something like an ifdef so that the same script could run in both python2 and python3...
I know the python community, the hardcore guys not writing casual scripts to get work done, insist on the "one way to do things", I have often found multiple ways. Because I don't use it as an application creation language, it is not may day-to-day job, just a few scripts that are supposed to make my life easier without lots of politics or style purists getting upset. At least my Perl books are sti
Re: (Score:2)
Yeah, but having a gob ton of modules doing:
try:
range = xrange
except NameError:
pass
makes an otherwise pleasant looking script look ugly, particularly as the little hacks here and there add up. Basically having two whole sets of imports wrapped in try/except.
This is of course assuming that the writer of code you are using actually bothered to update for the next release at all. Python requires module developers to really stay on top of things as language f
Re: (Score:2)
python refused to at least have backwards aliases for a lot of things.
Hi, I am a software developer who mainly uses Python.
'xrange' not even being allowed
Do this:
xrange = range
Then you can use it as much as you like. "Not allowed"? It's there if you want it.
Do you want the language permanently cluttered up, having both xrange() and range()? I'll tell you now: I really don't.
If you want to do something six times: range(6)
If you want a list of numbers from 0 to 5 inclusive: list(range(6))
I don't need two f
Re: (Score:2)
I mostly use Python and I know all about ability to do all this and six, but my point is it places the burden on the user, not the language. I don't mind that range() changed from a list to a generator and accept that people supporting both would have to accept that range no longer does what it used to. I mind that if someone wanted to cleanly support 2 and 3 they had to do all sorts of try/except importerror, try: range = xrange, except NameError pass, and/or pull in a third party compatibility module fro
Re: (Score:2, Interesting)
> I want Python 3 to die.
Why stop at 3? The entire language was designed by a fucking moron. Using whitespace to designate code blocks is utterly retarded. There is a reason C/C++ devs align #if 0 .. #endif on the far left to maintain readability and from debug code cluttering up the codebase. It is like Guido never actually debugged code before.
Python is for amateur programmers too dumb to understand pointers or performance.
The lack of backwards compatibility shows how shorted the design was. /Oblg.
Re:Almost good news. (Score:5, Informative)
Actually that part isn't so bad. And Python did not invent it, a few languages before it did the same thing (and thus you learn in vi how to stop using tabs) It's not that difficult to get around. There are lots of other things to put on the top ten list of design decisions that could be rethought.
>
Python is for amateur programmers too dumb to understand pointers or performance.
To be fair here, Python was originally intended as a scripting language. It was not intended to write full blown production applications, or to stick on the back end of your money making web interface. Performance should not normally be a concern in a scripting langauge.
Re: (Score:2)
It is very bad, especially in conjunction with Python's bizarre insistence of bubbling exceptions being used for non-exceptional logical state.
Since in Python “try”/“except” occupies a similar role to “else”/“if”, one often encounters such blocks that have to be intended one level deeper every time since no analogy to “elif” exists.
Re: (Score:2)
Python is for amateur programmers too dumb to understand pointers or performance.
Nah, it's just for tasks where those things aren't your primary concerns. For some jobs its appropriate to maximize performance. For others it's better to get the job done quick.
Re: (Score:2)
Using whitespace to designate code blocks is utterly retarded.
No one forces you to use Python.
And if you are a sane developer you would indent your code exactly as Python demands it: anyway.
Point is: Python developers, love that feature. And that is one of the main reasons they use Python, calling it "retarded" is just plain stupid.
Endif / fi is the right way to do it (Score:2)
{} is also totally retarded. Better to have different terminators for different statements. And the single statement IF is a pain in {} languages.
VBA got all this right.
Re: (Score:2)
Using whitespace to designate code blocks is utterly retarded.
Hey, now! If it was good enough for COBOL...
Re: (Score:2)
I'm glad they are finally killing off Python 2.7 because the 2.x series is horrible and needs to die.
Yes.
That said, why do they insist on using the Python 3.x series for it too is a bane that must be vanquished!
They don't insist. The summary says they don't include it in MacOS.
Re: (Score:2)
It is in Xcode. And to do almost any development on MacOS you need to first install Xcode or Xcode command line tools. Xcode command line tools are even a prerequisite for Mac Ports and Brew.
(Now if you just wanted a simple scripting language there's always bash. Hmm, the Mac keeps telling me to stop using bash; literally, it tells me to use zsh instead, apparently one developer's personal opinion about shells has made it into actual released code...)
Re: (Score:2)
I expect it is more like one lawyer's personal opinion about licenses. If Apple says don't use it, then any app store thing will not require it in time.
I use zsh on Freebsd. My only real issue with it is some of the default settings seem backwards to me. An example is wildcards must match something or zsh indicates and error while other shells tend to pass unexpanded wildcards along. That can be a pain with rsync remote:*.foo . which has to be quoted until that option is turned off.
Re: (Score:2)
So... I have to install Xcode and lose 40gB of disk just to run a python script? Got it.
Re: (Score:2, Informative)
Just a suggestion: Maybe you should stay away from Python in general? Because, while totally unsuitable for beginners IMO, both 2.x and 3.x are actually pretty nice scripting languages.
Re: (Score:2)
I'll agree that the languages are capable scripting languages. It's a shame that they don't value backwards compatibility more highly (notably 2->3, but even 3.x has been fraught with removals that may impact your code or third party libraries).
Re: (Score:2)
Except that the part that's painful to port is in a third party library, used to auto-generate some C files.
If unsuitable for beginners, then I'd argue unsuitable for a scripting language. Apparently though, the consensus is that Python 2.x is totally unsuitable for everyone, whether or not nice scripting language.
News to me (Score:2)
Re: (Score:3)
The fact that it was installed by default on older macs was one reason it was used by some of us. It's a pain to tell developers how to install all the myriad tools used for a product build, and having one that's just there by default is handy. I know some tester once made a tool using Ruby and the other testers were highly annoyed at the time about the hoops to jump through to get it installed and running.
Re: (Score:1)
except Ruby has shipped as part of MacOS for a long long time too.
Re: (Score:2)
Ah right. The problem I think was the tester used a newer version that he downloaded and used features not in the pre-supplied version.
Re: (Score:2)
We use pyenv to install python, much more control than using brew, since other brew packages will end up installing a different version than what you want. You get access to newer releases faster as well.
Re: (Score:2)
Apple removing more functionality as usual (Score:2)
Why should we have to install the Xcode bloatware just to have Python now? Sure, no doubt Brew can do it or you could build from source but much nicer to have it out the box and it's not as if it takes up much space.
What next, unix shells and Terminal itself become optional extras?
Re: Apple removing more functionality as usual (Score:1)
Re: (Score:2)
Some essential tooling on Gentoo and Red Hat-based systems is Python-based, so those systems would need Python, although they need not, necessarily, use the "system/default Python."
I'm starting to see the advantages of not depending on a system/default Python in the more general case, as there are too many things that can break from one version to the next, not the least of which are improperly updated pip packages. Better to use pyenv or some other mechanism to tie each script to the correct Python versio
Re: (Score:2)
You can just install the XCode command line tools - without the full XCode - to get stuff like python, make, gcc, etc.
Actually make may already be installed - it's been a while so I don't remember which tools are there by default and which get added by the command line toolset.
Re: (Score:2)
Why should we have to install the Xcode bloatware just to have Python now? Sure, no doubt Brew can do it or you could build from source but much nicer to have it out the box and it's not as if it takes up much space.
What next, unix shells and Terminal itself become optional extras?
It will just install the command line tools, not the entire Xcode eco-system. Another way to do it is to just install Anaconda instead... As for shells, I'm guessing some people will be very annoyed that bash is no longer the default shell on MacOS. Zsh is - the shell I knew and loved decades ago.
Re: (Score:2)
The default shell is just a configuration option in Terminal. :P
Easy to change
Re: (Score:2)
Brew needs Xcode too. Or at least Xcode command line tools. At least if installing from scratch, as opposed to update an existing one. Mac Ports too, which is more stable than Brew is I thnk. Now maybe that's not bad, but getting Xcode command line tools is a major pain if you don't want an Apple account or developer ID.
As for shells, if you start an interactive Bash in Catalina it warns you that you should be using zsh instead :-)
Just as well (Score:5, Funny)
I could never get Python to work on Apple devices anyway.
print (â(TM)Hello world!â(TM))
File â(TM)<stdin>â(TM), line 1
print (â(TM)Hello world!â(TM))
^
SyntaxError: Invalid syntax
Re: Just as well (Score:2)
Must be the smart quotes :D
Re: (Score:2)
It's what you get when you use Microsoft Word as your editor.
NO, don't install Xcode to get Python... (Score:5, Informative)
...unless you'd build a 20-storey office building to get a Starbucks.
Get the latest python 3 from python.org. there's a Mac installer, and you're getting the current official one (something that Apple has been pitiful about providing since jump. Maybe a wealthier company could afford to do it well...)
Then you might try PyCharm community edition for an IDE. It's pretty awesome even in the free community edition, and if you need the full Django and other framework support the pro version offers, the licence fees are not onerous.
And you don't have to sign an Apple NDA just to develop.
Here's my cool script (Score:4, Funny)
It will make your life easier. But you have to download and install Xcode first before you can use it.
Sure I could have written it in Bash, Perl, Awk, or C and saved you the hassle of installing gigabytes of stuff to run my 10 line script. Don't you like the feeling of using a throw away tool that is written in a modern, elegant language?
Re: (Score:2)
Or just install Python, a 38M download: https://www.python.org/ftp/pyt... [python.org]
Good - Py3 was a bug fix (Score:1)
The newly mandated parens on the built in print statement didn't seem 100% necessary, except I guess as long as they were breaking things they might as well make the language self consistent and elegant. So (shrug).
Re: (Score:1)
Re: (Score:2)
One can argue that the Python3 rollout was done badly, but it is very hard to argue that Python2 had not accumulated enough ongoing breakage that a new version with potentially breaking changes was needed.
How else in your view could we have gotten those fixes? How would you have incrementally improved 2 until it eventually became 3?
Dont' use python for long lived projects (Score:3)
nothin new (Score:1)
Good. It proves Macs are NOT developer machines. (Score:1)