FazBrowse GitHub Viewer | Trending |
URL:
| Home
Tools: [Download Repo ZIP]   [Original HTTPS Page]

gh-157695: Rename HAVE_ICONV to _Py_HAVE_ICONV by vstinner · Pull Request #157821 · python/cpython · GitHub

  1. python
  2. cpython

Repository navigation

gh-157695: Rename HAVE_ICONV to _Py_HAVE_ICONV - #157821

Merged
vstinner merged 3 commits into
python:mainfrom
vstinner:rename_iconv_macro
Sep 22, 2026
ConversationCommits (3)ChecksFiles changed
Merged

gh-157695: Rename HAVE_ICONV to _Py_HAVE_ICONV#157821
vstinner merged 3 commits into
python:mainfrom
vstinner:rename_iconv_macro

Conversation

vstinner commented Sep 19, 2026 •
edited by bedevere-app Bot
Loading

Copy link
Copy Markdown
Member

bedevere-app Bot mentioned this pull request Sep 19, 2026
Open

vstinner commented Sep 19, 2026

Copy link
Copy Markdown
Member Author

cc @serhiy-storchaka

The HAVE_ICONV macro is new in Python 3.16.

vstinner mentioned this pull request Sep 20, 2026
Merged
serhiy-storchaka approved these changes Sep 21, 2026
View reviewed changes

serhiy-storchaka left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality

I do not mind, but does it make difference if most of configure macros are HAVE_* and this is standard?

encukou commented Sep 21, 2026

Copy link
Copy Markdown
Member

does it make difference if most of configure macros are HAVE_*

Before we fix things, we should stop making them worse.

and this is standard?

Which standard is that?

serhiy-storchaka commented Sep 21, 2026

Copy link
Copy Markdown
Member

I do not know if this is a formal standard, but many projects use HAVE_*.

vstinner commented Sep 21, 2026

Copy link
Copy Markdown
Member Author

I do not mind, but does it make difference if most of configure macros are HAVE_* and this is standard?
(...)
I do not know if this is a formal standard, but many projects use HAVE_*.

It's fine to use HAVE_xxx macros to build a project. What bothers me is that Python exposes these macros in its public C API.

It's rare that a project exposes its HAVE_xxx macros in public header files. Example of a search on my Fedora 44 which has 6,130 header files in /usr/include:

$ find -name "*.h"|wc -l
6130

$ grep -l 'define HAVE_' -R /usr/include/|grep -v /python3|grep -v /pypy3
/usr/include/ncurses/etip.h
/usr/include/ncursesw/etip.h
/usr/include/etip.h
/usr/include/expat_config.h
/usr/include/freetype2/freetype/config/ftconfig-64.h
/usr/include/tcl-private/unix/tclUnixPort.h

All macros:

Details 
vstinner@vstinner-thinkpadp1gen3$ grep 'define HAVE_' -R /usr/include/|grep -v /python3|grep -v /pypy3
/usr/include/ncurses/etip.h:#define HAVE_BUILTIN_H 0
/usr/include/ncurses/etip.h:#define HAVE_EXCEPTION 1
/usr/include/ncurses/etip.h:#define HAVE_GXX_BUILTIN_H 0
/usr/include/ncurses/etip.h:#define HAVE_GPP_BUILTIN_H 0
/usr/include/ncurses/etip.h:#define HAVE_IOSTREAM 1
/usr/include/ncurses/etip.h:#define HAVE_NEW 1
/usr/include/ncurses/etip.h:#define HAVE_TYPEINFO 1
/usr/include/ncurses/etip.h:#define HAVE_VALUES_H 0
/usr/include/ncursesw/etip.h:#define HAVE_BUILTIN_H 0
/usr/include/ncursesw/etip.h:#define HAVE_EXCEPTION 1
/usr/include/ncursesw/etip.h:#define HAVE_GXX_BUILTIN_H 0
/usr/include/ncursesw/etip.h:#define HAVE_GPP_BUILTIN_H 0
/usr/include/ncursesw/etip.h:#define HAVE_IOSTREAM 1
/usr/include/ncursesw/etip.h:#define HAVE_NEW 1
/usr/include/ncursesw/etip.h:#define HAVE_TYPEINFO 1
/usr/include/ncursesw/etip.h:#define HAVE_VALUES_H 0
/usr/include/etip.h:#define HAVE_BUILTIN_H 0
/usr/include/etip.h:#define HAVE_EXCEPTION 1
/usr/include/etip.h:#define HAVE_GXX_BUILTIN_H 0
/usr/include/etip.h:#define HAVE_GPP_BUILTIN_H 0
/usr/include/etip.h:#define HAVE_IOSTREAM 1
/usr/include/etip.h:#define HAVE_NEW 1
/usr/include/etip.h:#define HAVE_TYPEINFO 1
/usr/include/etip.h:#define HAVE_VALUES_H 0
/usr/include/expat_config.h:#define HAVE_ARC4RANDOM 1
/usr/include/expat_config.h:#define HAVE_ARC4RANDOM_BUF 1
/usr/include/expat_config.h:#define HAVE_CXX11 1
/usr/include/expat_config.h:#define HAVE_DLFCN_H 1
/usr/include/expat_config.h:#define HAVE_FCNTL_H 1
/usr/include/expat_config.h:#define HAVE_GETENTROPY 1
/usr/include/expat_config.h:#define HAVE_GETPAGESIZE 1
/usr/include/expat_config.h:#define HAVE_GETRANDOM 1
/usr/include/expat_config.h:#define HAVE_INTTYPES_H 1
/usr/include/expat_config.h:#define HAVE_MMAP 1
/usr/include/expat_config.h:#define HAVE_STDINT_H 1
/usr/include/expat_config.h:#define HAVE_STDIO_H 1
/usr/include/expat_config.h:#define HAVE_STDLIB_H 1
/usr/include/expat_config.h:#define HAVE_STRINGS_H 1
/usr/include/expat_config.h:#define HAVE_STRING_H 1
/usr/include/expat_config.h:#define HAVE_SYSCALL_GETRANDOM 1
/usr/include/expat_config.h:#define HAVE_SYS_PARAM_H 1
/usr/include/expat_config.h:#define HAVE_SYS_STAT_H 1
/usr/include/expat_config.h:#define HAVE_SYS_TYPES_H 1
/usr/include/expat_config.h:#define HAVE_UNISTD_H 1
/usr/include/freetype2/freetype/config/ftconfig-64.h:#define HAVE_UNISTD_H 1
/usr/include/freetype2/freetype/config/ftconfig-64.h:#define HAVE_FCNTL_H 1
/usr/include/tcl-private/unix/tclUnixPort.h:#	    define HAVE_PUTENV_THAT_COPIES	1

Projects built with <Python.h> should implement their own function and header checks, not rely on HAVE_xxx macros. For example, Python can built on a machine and installed on a different machine where HAVE_xxx macros are outdated.

serhiy-storchaka commented Sep 21, 2026

Copy link
Copy Markdown
Member

Then the problem is not in having HAVE_* names, but in exposing them in Python.h. What other libraries do to avoid this?

vstinner merged commit 315ed16 into python:main Sep 22, 2026
53 checks passed
vstinner deleted the rename_iconv_macro branch September 22, 2026 05:28

vstinner commented Sep 22, 2026

Copy link
Copy Markdown
Member Author

Then the problem is not in having HAVE_* names, but in exposing them in Python.h. What other libraries do to avoid this?

It seems like they do no include the "config.h" file in their public C API.

This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Show hidden characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

serhiy-storchaka serhiy-storchaka approved these changes
erlend-aasland Awaiting requested review from erlend-aasland erlend-aasland is a code owner
corona10 Awaiting requested review from corona10 corona10 is a code owner
AA-Turner Awaiting requested review from AA-Turner AA-Turner is a code owner
emmatyping Awaiting requested review from emmatyping emmatyping is a code owner
itamaro Awaiting requested review from itamaro itamaro is a code owner

Assignees

No one assigned

Labels

skip news

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

Back | FazBrowse Home | New Git URL