On such a system, sysconfig.get_config_var('MACOSX_DEPLOYMENT_TARGET') will return 11 as an int, not as a str.

Is it supposed to do this? This seems like an accidental breaking change in python that may need addressing upstream.

See python/cpython#23556 and https://bugs.python.org/issue42504
The intent of sysconfig.get_config_var() is pretty clear: see the code for parse_config_h at https://github.com/python/cpython/blob/master/Lib/sysconfig.py#L461

Just wanted to +1 this, as I've just run into this myself.

Although as you point out the intent may have been clear when reading the code, it was not clear to CPython devs (hence the need for a fix in other places in the code) nor to anyone else using sysconfig (like us), nor is it documented behaviour. This seems like one bad API choice following another.

nor is it documented behaviour

From the documentation you link:

>>> import sysconfig
>>> sysconfig.get_config_var('Py_ENABLE_SHARED')
0

It is clear that int-type values are returned as int.

I quickly tried it out on a 10.14.6 (Mojave) MBP and got the following results:

>>> sysconfig.get_config_var('Py_ENABLE_SHARED')
0
>>> sysconfig.get_config_var('MACOSX_DEPLOYMENT_TARGET')
'10.14'

So at some point it did return a string. I get 11 as an int on Big Sur.

So at some point it did return a string.

It returns an int when the value is exactly representable as an int, and a string otherwise.

@fxcoudert I would not call that documented behaviour. The documentation should clearly state that the function will try to return an int and if it fails, a str.

@luketaverne 10.14 cannot be converted to an int, so the value is returned as a str. But your comment points out how confusing this behaviour is.

@rgommers I see this didn't make it into the 1.19.5 version (Homebrew/homebrew-core#68346), shouldn't this simple patch be backported?

Argh yes, that is an oversight. I should have put on a label, then @charris would have seen it when deciding what to backport for 1.19.5. Done now; luckily 1.20.0 is also imminent, so the damage is very limited. I checked the fix is in the 1.20.x branch.

I should have put on a label

The milestone needed to be 1.19.5.

NumPy 1.20.0 is waiting for pyarrow to release. If they don't get a move on I'll release anyway.

I'm not planning on another 1.19 release.