@vstinner @encukou @erlend-aasland @zooba @serhiy-storchaka In our discussion on the PyBytes_Join function, we discussed on the possibility of using macros for empty strings/bytes. Do you think this is worth the change? if so, I'll open an associated issue. I haven't changed the PyUnicode_FromString("") calls since they are "optimized" to returnt he singleton (though there are quite a lot of functions being called under the hood).

The C API WG deals with public API.

IMO the internal API is fine as it is; the rename doesn't bring much.

I'm quite happy to review internal C API designs as well - we all still have to live with them.

As a concept, this one looks fine to me. It'll help our contributors discover how best to access these singletons, as it isn't exactly obvious. If/when we make another way to get them it'll be easier to update.

As a PR, I think there are some generated files you've touched that will be undone when they regenerate (though I haven't checked for sure). Make sure you do a make regen to see if anything changes.

As a PR, I think there are some generated files you've touched that will be undone when they regenerate (though I haven't checked for sure).

I think there's already a CI job that checks whether the files are up-to-date or not and I locally did regenerate them so they should be part of the PR. It should be fine I think.

I'll create an issue soon (I think we can make a meta-issue to integrate the empty tuple case as well).

For now, I'm converting it into a draft until I've resolved my own interrogations on whether to replace PyUnicode_FromString("") and PyUnicode_New(0, 0) or not.

For now, I'm converting it into a draft until I've resolved my own interrogations on whether to replace PyUnicode_FromString("") and PyUnicode_New(0, 0) or not.

_Py_STR() and _Py_SINGLETON() are replaced with direct pointers at build time, whereas PyUnicode_FromString("") and PyUnicode_New(0, 0) are implemented as regular function calls at runtime: it's slower.

_Py_STR() and _Py_SINGLETON() are replaced with direct pointers at build time, whereas PyUnicode_FromString("") and PyUnicode_New(0, 0) are implemented as regular function calls at runtime: it's slower.

Yes, but is it safe to replace all occurrences? Actually, what I'd like to know whether there was a deeper meaning of not using the singleton (is it because when the code was written, this singleton did not yet exist? I think it was introduced in 2022).

Yes, but is it safe to replace all occurrences?

I don't think that it's useful to replace all occurrences.

Which is why I didn't do it and was interrogating myself on whether it's useful or not. Now that I have another opinion, I'll leave it as is. I don't want to have an immense diff so I kept it simple. Otherwise the number of occurrences to change is much larger and we'll have a lot of changed files (thereby creating conflicts in other PRs I think...)

I don't think that it's useful to replace all occurrences.

Are there some you know are not safe? Provided the reference counting works out (which may require additional changes), it should be fine to replace calls like PyUnicode_FromString("") with the empty str singleton, right?

The C API WG deals with public API.

I was extremely brief there, sorry. In the WG discussion, Marc-Andre asks for public API.

And I think that is what we need first. Perhaps something like:

• #define Py_NONE Py_GetConstantBorrowed(Py_CONSTANT_NONE)
• #define Py_FALSE Py_GetConstantBorrowed(Py_CONSTANT_FALSE)
• ... and so on

These should be documented. They're ”borrowed from the interpreter”, i.e they don't necessarily survive interpreter shutdown/reinitialization, and can't be shared between interpreters, although both will work in CPython.
Unlike Py_None, Py_NONE would be in the limited API, but it would not be an exported ABI symbol.

And when that's in place, these can get a faster implementation for non-limited API or for Py_BUILD_CORE.

I don't think it's helpful to only add new undocumented internal macros.

I didn't propose #define Py_EMPTY_STR Py_GetConstantBorrowed(Py_CONSTANT_EMPTY_STR) since Py_GetConstantBorrowed() is documented as:

This function is primarily intended for backwards compatibility: using Py_GetConstant() is recommended for new code.

It's strange to me to add a new macro relying on something only provided "for backward compatibility".

If we add such macro, I would prefer to see the function documentation rephrased.

Or maybe it's a bad idea to add a new macro which returns a borrowed reference, whereas the C API Guidelines is against adding new functions returning borrowed references. I don't know.

@encukou:

I don't think it's helpful to only add new undocumented internal macros.

I have mixed feelings about this change. I'm not convinced that it makes Python easier to maintain or easier to understand. I like using explicitly the complex _Py_STR() and _Py_SINGLETON() macros, but maybe it's just a personal taste :-)

If we add such macro, I would prefer to see the function documentation rephrased.

I agree with that.

C API Guidelines is against adding new functions returning borrowed references

Which guidelines? I guess we should clarify those first :)

I like using explicitly the complex _Py_STR() and _Py_SINGLETON() macros, but maybe it's just a personal taste :-)

I suspect this is personal taste, because you are highly familiar with how it works under the covers :-) For someone who isn't so aware, I think they're unlikely to guess to write the more complex version, and so if we have an obvious macros that does it then they're more likely to choose something efficient.

I'm closing this one since we didn't manage to find an answer to what we should replace at the end and whether this macro would be useful or not. We can revisit this question later (and there are anyway lots of conflicts now and I'm cleaning up my stale branches).