8 ms·

> The risk of unpatched vulnerabilities If a company as 'small' as (pre-IBM) Red Hat can afford to support Python 2.7, then so can Apple: * https://developers

> The risk of unpatched vulnerabilities If a company as 'small' as (pre-IBM) Red Hat can afford to support Python 2.7, then so can Apple: * https://developers.redhat.com/blog/2018/11/14/python-in-rhel-8-3 https://developers.redhat.com/blog/2018/11/14/python-in-rhel... * https://access.redhat.com/solutions/4455511 https://access.redhat.com/solutions/4455511 Further, if Debian has the resources to support Python 2.x, then so does multi-trillion dollar company of Apple: * https://packages.debian.org/search?keywords=python2 https://packages.debian.org/search?keywords=python2 If they wanted to announce at the June 2022 WWDC that macOS 13 wasn't going to have it, that's fine. But we're several months into macOS 12.x and such a large change is bad form.

Redoubts 5y ago
Maybe they can afford it, but why should they?
- simlevesque 5y ago
  To offer a good service. To avoid breaking something the users depend on.
  - danaris 5y ago
    That's what Windows is for.
  - samtheDamned 5y ago
    Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.
  - Kalium 5y ago
    Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer. How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.
    - vetinari 5y ago
      Again, the issue is "when", not "whether". They could drop it with v12, or wait for v13, both would be fine. Dropping it in the middle of release cycle what people are objecting to.
      - deleted 5y ago
        [deleted]
    - ClumsyPilot 5y ago
      "How long is long enough to avoid breaking something the users depend on?" 10 years - a piece of software compiled with 'supported' libraries, SDKs and what have you should function for 10 years. An appliance or a service should function for 10 years and have spare parts avaliable for that long. That is the guideline I ise as a consumer, if I can see that something won't last a decade, I won't be spending money or time on it if i can avoid it. At that point it's no longer a durable good, it's a consumable.
      - deleted 5y ago
        [deleted]
      - lakhim 5y ago
        Python2.7 was supposed to be EOL in 2015(!). It was released in 2010. It had 10 years of support mainline.
        ClumsyPilot 5y ago
        There would still be Python 2.7 software being produced up to EOL, so you have to start counting from 2015.
        deleted 5y ago
        [deleted]
  - Cthulhu_ 5y ago
    If there are users that still depend on python 2.7, they can install it manually? I mean I already think it's... interesting that an operating system comes with (multiple) programming language interpreters, available to the end-user.
    - mrpippy 5y ago
      That’s true if they’re using it from the command-line, but not if they’re using apps that linked against the system SDK’s libpython2.7.dylib (and assumed PyObjC would be present)
      - TillE 5y ago
        Is there any significant software still using that? Apple is pretty aggressive about breaking backwards compatibility, as they did with x86, so it's no real surprise for unmaintained software to become completely unusable.
        Wowfunhappy 5y ago
        Notably, however, Apple didn't drop x86 support in a minor update.
        mrpippy 5y ago
        And kept the support present for I think a year and a half alongside a runtime warning message (and removed SDK support earlier than that)
        mrpippy 5y ago
        Based on what they’ve done, I guess the answer is no. My company was shipping (somewhat niche) software linking with the built-in python2 up until last year though, and it’s been a scramble since Monterey to rebuild things to avoid the warning message. Definitely thought we would have python2 until 13.0 though (and part of me wonders whether this is just a “brown-out” for the beta and 12.3 release will be back to normal)
    - 5y ago
- nicce 5y ago
  Yep. Comparison is not good since Red Hat et al. focus a lot on server side.
- intpx 5y ago
  Bingo. This falls under the scope of support for an enterprise linux company-- orgs pay them to keep stuff backwards compatible long after the upstream deprecates it. Apple is decidedly not an enterprise support organization. RHEL also doesn't want you using system python as your dev python. RHEL 8 uses 'platform-python' for the bits the system needs and if you install 3.6, they share the common bits If your using a mac as a dev box, and really need python 2.7, you still have options.
- deleted 5y ago
  [deleted]
stephenr 5y ago
They literally did that, in 2019: https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes#Scripting-Language-Runtimes https://developer.apple.com/documentation/macos-release-note..., and specifically mentioned *then* that Python2.7 was not recommended.
- Wowfunhappy 5y ago
  Yes, and I was surprised when Monterrey launched with Python 2 still included. But I really did think that since it was in Monterrey, it was going to stick around until at least macOS 13.
  - Spooky23 5y ago
    They probably had a major customer who needed it for some wacky reason.
  - stephenr 5y ago
    Let's face it: at this point macOS version numbers are a marketing tool, and not much more. It's only 2 major releases ago that a "x.y" release *would* have been considered "major".
    - Wowfunhappy 5y ago
      I don't think that's particularly relevant. It was pretty clear that between 10.0 and 10.15, the second number was the "major" version for all intents and purposes, and now it's the first number.
shawnz 5y ago
Supporting stone age system administration tools is basically Red Hat's core business though. That doesn't really seem like a fair comparison.
chupasaurus 5y ago
Debian drops the support of Python 2 starting with Bullseye ([0] and the supported versions list below): NOTE: Debian 11 (bullseye) has removed the "python" package and the '/usr/bin/python' symlink due to the deprecation of Python 2. [0] https://wiki.debian.org/Python#Python_in_Debian https://wiki.debian.org/Python#Python_in_Debian
- throw0101a 5y ago
  Python 2 is still available in Bullseye: * https://packages.debian.org/bullseye/python2 https://packages.debian.org/bullseye/python2 There has been no dropping of support: if you want Python 2.7 you can install in.
airstrike 5y ago
Just because someone has the resources to do something it doesn't mean that doing so is the right {business, technical} decision. You're confounding the two.
- reaperducer 5y ago
  {business, technical} Very HN: Business || technical. No concession for "Customer service."
  - airstrike 5y ago
    Customer service is still a business reason. It serves to keep your customers happy, and the calculus here is probably that there aren't enough customers to keep happy by maintaining python2.7 that would justify the costs and headache. You can't please everyone
diebeforei485 5y ago
They don't bundle Python, it has to be installed separately. macOS is going the same way, except that Apple doesn't have a package manager so it has to be a manual installation.
- zepto 5y ago
  This is false. Homebrew is no different from any other open source package manager. There is no need for a manual installation.
  - 7steps2much 5y ago
    >> except that Apple doesn't have a package manager > This is false. Homebrew is no different from any other open source package manager. Just to quote the literal slogan of homebrew: >The Missing Package Manager for macOS (or Linux) I think it is fair to say that Apple does in fact not have a package manager. Unless they do bundle homebrew with their OS nowadays?
    - zepto 5y ago
      You quote a marketing slogan. “Missing” in the sense that Apple doesn’t ship it. > Apple doesn't have a package manager so it has to be a manual installation. The quoted statement is clearly false. To maintain that python has to be installed by hand is incorrect. Apple the corporation doesn’t have a package manager. MacOS, the ecosystem does. No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux.
      - stephenr 5y ago
        > Apple the corporation doesn’t have a package manager. > MacOS, the ecosystem does. > No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux. macOS the OS has a package manager in terms of a tool to install packages. It does not have the ability to find/download packages to install though. In the sense of a package manager being able to download and install additional software, macOS has several choices available but none of them are included with the OS, or have the ability to update the OS. There is arguably no single "Linux ecosystem". There are numerous Linux-based distributions, which are largely comparable to macOS as an OS. One of the very key differences between each family of distro's is the package manager the OS ships with by default and uses to update itself. So no. macOS does not "have" a package manager that's comparable to those included by default with linux distributions, but there are several third party package managers available for it.
bastardoperator 5y ago
Bad form is coding against system binaries...

Redoubts 5y ago

Maybe they can afford it, but why should they?

simlevesque 5y ago
To offer a good service. To avoid breaking something the users depend on.
- danaris 5y ago
  That's what Windows is for.
- samtheDamned 5y ago
  Apple isn't in the business of spending excess money to avoid breaking things. If anything apple is the opposite.
- Kalium 5y ago
  Apple supported Python 2 for two years after it was officially sunset by the Python Foundation. They've been advising that they will drop support for longer. How long is long enough to avoid breaking something the users depend on? One more year? Five years? Fifty? I think we can all agree that it's reasonable to drop support at some point, making it just a question of when and at what cost.
  - vetinari 5y ago
    Again, the issue is "when", not "whether". They could drop it with v12, or wait for v13, both would be fine. Dropping it in the middle of release cycle what people are objecting to.
    - deleted 5y ago
      [deleted]
  - ClumsyPilot 5y ago
    "How long is long enough to avoid breaking something the users depend on?" 10 years - a piece of software compiled with 'supported' libraries, SDKs and what have you should function for 10 years. An appliance or a service should function for 10 years and have spare parts avaliable for that long. That is the guideline I ise as a consumer, if I can see that something won't last a decade, I won't be spending money or time on it if i can avoid it. At that point it's no longer a durable good, it's a consumable.
    - deleted 5y ago
      [deleted]
    - lakhim 5y ago
      Python2.7 was supposed to be EOL in 2015(!). It was released in 2010. It had 10 years of support mainline.
      - ClumsyPilot 5y ago
        There would still be Python 2.7 software being produced up to EOL, so you have to start counting from 2015.
        deleted 5y ago
        [deleted]
- Cthulhu_ 5y ago
  If there are users that still depend on python 2.7, they can install it manually? I mean I already think it's... interesting that an operating system comes with (multiple) programming language interpreters, available to the end-user.
  - mrpippy 5y ago
    That’s true if they’re using it from the command-line, but not if they’re using apps that linked against the system SDK’s libpython2.7.dylib (and assumed PyObjC would be present)
    - TillE 5y ago
      Is there any significant software still using that? Apple is pretty aggressive about breaking backwards compatibility, as they did with x86, so it's no real surprise for unmaintained software to become completely unusable.
      - Wowfunhappy 5y ago
        Notably, however, Apple didn't drop x86 support in a minor update.
        mrpippy 5y ago
        And kept the support present for I think a year and a half alongside a runtime warning message (and removed SDK support earlier than that)
      - mrpippy 5y ago
        Based on what they’ve done, I guess the answer is no. My company was shipping (somewhat niche) software linking with the built-in python2 up until last year though, and it’s been a scramble since Monterey to rebuild things to avoid the warning message. Definitely thought we would have python2 until 13.0 though (and part of me wonders whether this is just a “brown-out” for the beta and 12.3 release will be back to normal)
  - 5y ago
nicce 5y ago
Yep. Comparison is not good since Red Hat et al. focus a lot on server side.
intpx 5y ago
Bingo. This falls under the scope of support for an enterprise linux company-- orgs pay them to keep stuff backwards compatible long after the upstream deprecates it. Apple is decidedly not an enterprise support organization. RHEL also doesn't want you using system python as your dev python. RHEL 8 uses 'platform-python' for the bits the system needs and if you install 3.6, they share the common bits If your using a mac as a dev box, and really need python 2.7, you still have options.
deleted 5y ago
[deleted]

stephenr 5y ago

They literally did that, in 2019: https://developer.apple.com/documentation/macos-release-notes/macos-catalina-10_15-release-notes#Scripting-Language-Runtimes https://developer.apple.com/documentation/macos-release-note..., and specifically mentioned *then* that Python2.7 was not recommended.

Wowfunhappy 5y ago
Yes, and I was surprised when Monterrey launched with Python 2 still included. But I really did think that since it was in Monterrey, it was going to stick around until at least macOS 13.
- Spooky23 5y ago
  They probably had a major customer who needed it for some wacky reason.
- stephenr 5y ago
  Let's face it: at this point macOS version numbers are a marketing tool, and not much more. It's only 2 major releases ago that a "x.y" release *would* have been considered "major".
  - Wowfunhappy 5y ago
    I don't think that's particularly relevant. It was pretty clear that between 10.0 and 10.15, the second number was the "major" version for all intents and purposes, and now it's the first number.

shawnz 5y ago

Supporting stone age system administration tools is basically Red Hat's core business though. That doesn't really seem like a fair comparison.

chupasaurus 5y ago

Debian drops the support of Python 2 starting with Bullseye ([0] and the supported versions list below): NOTE: Debian 11 (bullseye) has removed the "python" package and the '/usr/bin/python' symlink due to the deprecation of Python 2. [0] https://wiki.debian.org/Python#Python_in_Debian https://wiki.debian.org/Python#Python_in_Debian

throw0101a 5y ago
Python 2 is still available in Bullseye: * https://packages.debian.org/bullseye/python2 https://packages.debian.org/bullseye/python2 There has been no dropping of support: if you want Python 2.7 you can install in.

airstrike 5y ago

Just because someone has the resources to do something it doesn't mean that doing so is the right {business, technical} decision. You're confounding the two.

reaperducer 5y ago
{business, technical} Very HN: Business || technical. No concession for "Customer service."
- airstrike 5y ago
  Customer service is still a business reason. It serves to keep your customers happy, and the calculus here is probably that there aren't enough customers to keep happy by maintaining python2.7 that would justify the costs and headache. You can't please everyone

diebeforei485 5y ago

They don't bundle Python, it has to be installed separately. macOS is going the same way, except that Apple doesn't have a package manager so it has to be a manual installation.

zepto 5y ago
This is false. Homebrew is no different from any other open source package manager. There is no need for a manual installation.
- 7steps2much 5y ago
  >> except that Apple doesn't have a package manager > This is false. Homebrew is no different from any other open source package manager. Just to quote the literal slogan of homebrew: >The Missing Package Manager for macOS (or Linux) I think it is fair to say that Apple does in fact not have a package manager. Unless they do bundle homebrew with their OS nowadays?
  - zepto 5y ago
    You quote a marketing slogan. “Missing” in the sense that Apple doesn’t ship it. > Apple doesn't have a package manager so it has to be a manual installation. The quoted statement is clearly false. To maintain that python has to be installed by hand is incorrect. Apple the corporation doesn’t have a package manager. MacOS, the ecosystem does. No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux.
    - stephenr 5y ago
      > Apple the corporation doesn’t have a package manager. > MacOS, the ecosystem does. > No different from Linux. There is no Linux package manager. There are numerous open source package managers for Linux. macOS the OS has a package manager in terms of a tool to install packages. It does not have the ability to find/download packages to install though. In the sense of a package manager being able to download and install additional software, macOS has several choices available but none of them are included with the OS, or have the ability to update the OS. There is arguably no single "Linux ecosystem". There are numerous Linux-based distributions, which are largely comparable to macOS as an OS. One of the very key differences between each family of distro's is the package manager the OS ships with by default and uses to update itself. So no. macOS does not "have" a package manager that's comparable to those included by default with linux distributions, but there are several third party package managers available for it.

bastardoperator 5y ago

Bad form is coding against system binaries...