classification
Title: Deprecate the binhex module, binhex4 and hexbin4 standards
Type: Stage: resolved
Components: Library (Lib), macOS Versions: Python 3.9
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: Nosy List: martin.panter, ned.deily, ronaldoussoren, serhiy.storchaka, vstinner
Priority: normal Keywords: patch

Created on 2020-01-16 09:14 by vstinner, last changed 2020-01-30 21:20 by martin.panter. This issue is now closed.

Pull Requests
URL Status Linked Edit
PR 18025 merged vstinner, 2020-01-16 09:22
PR 18276 merged vstinner, 2020-01-30 08:07
Messages (19)
msg360100 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-16 09:14
The binhex module encodes and decodes Apple Macintosh binhex4 data. It was originally developed for TRS-80. In the 1980s and early 1990s it was used on classic Mac OS 9 to encode binary email attachments.

Mac OS 9 is now heavily outdated, replaced by "macOS" (previously known as "Mac OS X").

I propose to emit a DeprecationWarning in the binhex module and document that it's deprecated.

I don't think that we have to schedule its removal yet, it can be decided later. A first deprecation warning emitted at runtime might help to warn last users, if there is any.

There are two binhex open issues:

* bpo-29566: no activity for almost 2 years (February 2017)
* bpo-34063: no activity for 1 year 1/2 (July 2018)

If we ignore global cleanup (done on the whole Python code base at once, not specific to binhex), the binhex was basically untouched since it has been ported to Python 3 (10 years ago). Maybe it means that it is very stable, which can be seen as a quality ;-)

I looked for "import binhex" in the first 10 pages of GitHub code search (restricted to Python programming language). I mostly found copies of Python test_binhex.py, no real usage of binhex.

On Stackoverflow, the latest questions about binhex has been asked in 2012:
https://stackoverflow.com/questions/12467973/binhex-decoding-using-java-code

I also found an answer suggesting to use binascii.a2b_hex() to decode a string the hexadecimal string "2020202020202020202020205635514d385a5856":
https://stackoverflow.com/questions/9683278/how-to-get-hard-disk-drivers-serial-number-in-python/9683837#9683837

But binascii.unhexlify() does the same than binascii.a2b_hex().

Attached PR deprecates binhex.
msg360105 - (view) Author: Serhiy Storchaka (serhiy.storchaka) * (Python committer) Date: 2020-01-16 09:30
binhex provides an encoding different from binascii.a2b_hex() and binascii.unhexlify().

If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

But it would be nice to create a separate package on PyPI that provides such functionality before removing it from the stdlib.
msg360109 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-16 09:43
> But it would be nice to create a separate package on PyPI that provides such functionality before removing it from the stdlib.

This issue is *not* about removing the module :-) Only to mark it as deprecated.

> If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

I have no opinion on that. I mean: in case of doubt, I prefer to not deprecate them. I never used any of these functions.
msg360113 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-16 10:16
> I also found an answer suggesting to use binascii.a2b_hex() to decode a string the hexadecimal string "2020202020202020202020205635514d385a5856":
https://stackoverflow.com/questions/9683278/how-to-get-hard-disk-drivers-serial-number-in-python/9683837#9683837

Oh wait, it is just unrelated :-) It's a typo in the StackOverflow answer: "import binhex; binascii.a2b_hex(...)". It should be "import binascii" obviously ;-) I didn't notice at the first read. binhex has no a2b_hex() function :-)
msg360201 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-17 16:32
> If deprecate the binhex module, we perhaps should deprecate also binascii.b2a_hqx(), binascii.a2b_hqx(), binascii.rlecode_hqx(), binascii.rledecode_hqx() and binascii.crc_hqx().

Ok, let's do that. I updated the issue title and my PR.
msg360202 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-17 16:54
Serhiy Storchaka asked:
https://github.com/python/cpython/pull/18025#issuecomment-575645748

"""
What is a benefit of deprecating it?

This module is a high-level interface to several functions in the binascii module. This is all macOS specific stuff, so you need to ask macOS experts. If this encoding no longer used in macOS, its support can be removed, with deprecating first. If there are no plans to remove, there is no reason to deprecate.
"""

The intent is to reduce the size of the standard library to reduce the maintenance burden of Python in general. The final goal is to remove the module. But that's a first step to check if there is still any user around. We should deprecate it for at least one cycle.

I understood that binhex4 and hexbin4 standards were used on Mac OS 9 but are no longer used on macOS, nor used anywhere else. See my first message.

Mac OS 9 is really outdated in 2020 and will likely be completly dead when Python 3.10 will be released (first Python release when we will be able to remove the module).

About the removal: I would like first write a PEP to propose a process to move old or unmaintained modules from the stdlib to PyPI. The "removal" would mean "move to PyPI" (but yeah, technically it would still be removed from the stdlib).

But I don't want to open a discuss on this hypothetical PEP *here* (I didn't write it yet :-D).
msg360203 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-17 17:01
BinHex format: https://en.wikipedia.org/wiki/BinHex

The question here is not only if binhex remains popular, but more generally if we want to continue to maintain it forever. Each module has a cost on the overall Python maintenance burden.
msg360429 - (view) Author: Ronald Oussoren (ronaldoussoren) * (Python committer) Date: 2020-01-21 20:13
I agree with deprecating binhex.
msg360501 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-22 19:44
New changeset beea26b57e8c80f1eff0f967a0f9d083a7dc3d66 by Victor Stinner in branch 'master':
bpo-39353: Deprecate the binhex module (GH-18025)
https://github.com/python/cpython/commit/beea26b57e8c80f1eff0f967a0f9d083a7dc3d66
msg360502 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-22 19:45
> I agree with deprecating binhex.

Good :-) It's now deprecated.
msg360517 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2020-01-22 22:43
Is there a recommended replacement for calculating CRC-CCITT? Do it yourself in Python code, or use a particular external module?
msg360518 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-22 22:45
> Is there a recommended replacement for calculating CRC-CCITT? Do it yourself in Python code, or use a particular external module?

What is your use case?
msg360519 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2020-01-22 23:21
Building and verifying the checksum in "RTA protocol" that uses this: <https://rms.nsw.gov.au/business-industry/partners-suppliers/documents/specifications/tsi-sp-003.pdf>. But I understand CRC-CCITT is one of the two popular 16-bit CRC polynomials, used in many other places, according to <https://en.wikipedia.org/wiki/Cyclic_redundancy_check#Polynomial_representations_of_cyclic_redundancy_checks>.
msg360605 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-24 10:29
> Building and verifying the checksum in "RTA protocol" that uses this: (...)

Are you simply asking to not deprecate binascii.crc_hqx()?
msg360669 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2020-01-25 05:09
Of course I would prefer “crc_hqx” to stay, because we use it at work. But I understand if you think it is not popular enough to justify maintaining it.

But I was more asking if the deprecation notice should point the way forward. This function is no longer recommended, so what should users do instead? Or at least explain why it is deprecated.

In my case, I may eventually write or resurrect a simple Python CRC implementation that shifts one bit at a time. But other people may desire a faster C implementation.
msg361020 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-30 08:09
> Of course I would prefer “crc_hqx” to stay, because we use it at work.

I propose to deprecate it because I understood that it was strictly related to binhex4 and hexbin4 protocols. If there is an use case outside these protocols, I'm fine with maintaining it.

The first motivation was to drop the binhex module in the long term, I'm less worried about specific binascii functions.
msg361023 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-30 08:56
New changeset c38fd0df2b4cbc1cc906d8dfe23f63b67cd6965f by Victor Stinner in branch 'master':
bpo-39353: binascii.crc_hqx() is no longer deprecated (GH-18276)
https://github.com/python/cpython/commit/c38fd0df2b4cbc1cc906d8dfe23f63b67cd6965f
msg361024 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2020-01-30 08:57
binascii.crc_hqx() is no longer deprecated. I close again the issue.
msg361078 - (view) Author: Martin Panter (martin.panter) * (Python committer) Date: 2020-01-30 21:20
Thanks Victor
History
Date User Action Args
2020-01-30 21:20:06martin.pantersetmessages: + msg361078
2020-01-30 08:57:13vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg361024

stage: patch review -> resolved
2020-01-30 08:56:44vstinnersetmessages: + msg361023
2020-01-30 08:09:19vstinnersetmessages: + msg361020
2020-01-30 08:07:53vstinnersetstage: resolved -> patch review
pull_requests: + pull_request17651
2020-01-25 05:09:55martin.pantersetmessages: + msg360669
2020-01-24 10:29:36vstinnersetmessages: + msg360605
2020-01-23 03:18:48vstinnersetstatus: closed -> open
resolution: fixed -> (no value)
2020-01-22 23:21:58martin.pantersetmessages: + msg360519
2020-01-22 22:45:08vstinnersetmessages: + msg360518
2020-01-22 22:43:32martin.pantersetnosy: + martin.panter
messages: + msg360517
2020-01-22 19:45:46vstinnersetstatus: open -> closed
resolution: fixed
messages: + msg360502

stage: patch review -> resolved
2020-01-22 19:44:25vstinnersetmessages: + msg360501
2020-01-21 20:13:04ronaldoussorensetmessages: + msg360429
2020-01-17 17:01:15vstinnersetmessages: + msg360203
2020-01-17 16:54:25vstinnersetmessages: + msg360202
2020-01-17 16:32:19vstinnersetmessages: + msg360201
2020-01-17 16:31:51vstinnersettitle: Deprecate the binhex module -> Deprecate the binhex module, binhex4 and hexbin4 standards
2020-01-17 14:23:34serhiy.storchakasetnosy: + ronaldoussoren, ned.deily
components: + macOS
2020-01-16 10:16:20vstinnersetmessages: + msg360113
2020-01-16 09:43:12vstinnersetmessages: + msg360109
2020-01-16 09:30:28serhiy.storchakasetmessages: + msg360105
2020-01-16 09:22:27vstinnersetkeywords: + patch
stage: patch review
pull_requests: + pull_request17420
2020-01-16 09:14:45vstinnercreate