GeezerVison

I agree that we should add a non-API function for creating code objects and _PyCodeNew seems like a sensible name for it.
But surely that should be a 10 line diff, not a 1000 line diff?

Passing a struct as a single parameter to a function means that you have to ensure that all future versions can handling trailing zeroes.
E.g.

PyObject *make_thing(struct thing *t);

Version 1:

struct thing {
    some data;
};

Version 2:

struct thing {
   some data;
   int super_important_must_never_be_zero;

Any client code written for version 1 will compile for version 2 and then crash mysteriously when run.

I see your point but consider it less of an issue for an internal-only API like this. For the most part this PR is about addressing the pain points I ran into while making changes around PyCodeObject:

• changes to the public "constructor" API to accommodate changes to internal details are frustrating for everyone (hence the new internal function)
• much of the public API for PyCodeObject probably shouldn't be public in the first place
• the signature of 2 of the "constructor" functions are particularly large, so adding, removing, or re-arranging parameters is annoying (hence the args struct, which we also do for frames)
• for folks not already familiar with PyCodeObject, the nature of the various fields isn't obvious at first (hence grouping the fields)
• more than a couple modules are fairly tightly coupled to the internal details of PyCodeObject, which may make sense for ceval.c as the confluence of functions, code, and frames, but that coupling (even in ceval,c) means changes to PyCodeObject internals result in touches to a variety of other modules (and the number of modules touched for a change correlates to bug count)

I'm okay with dialing back the changes if you think they aren't worth it, but the definitely are based in my experience thus far with PyCodeObject.

I think we all agree that the API for making PyCodeObjects shouldn't have been public in the first place. But it is 😞
I'm in favour of removing it, but that would need a proper discussion of python-dev.

The accessor macros, _PyCode_GET_INSTRUCTION etc, seem useful, but could you make them inline functions.

Ultimately we want something like https://github.com/markshannon/peps/blob/pep-mappable-pyc-file/pep-066x.rst#runtime-objects
It is going to take a while to get there, but let's try and minimize the changes along the way.

Please remove construction of a CodeObject using a structure. As I explained earlier it isn't safe.
Nor does it do anything for clarity, IMO, it just adds bulk.

Please remove construction of a CodeObject using a structure. As I explained earlier it isn't safe.

That only applies for public APIs. This is a purely internal API. The compiler will catch the case you worry about in that explanation.

Nor does it do anything for clarity, IMO, it just adds bulk.

It allows us something not entirely unlike keyword arguments in C, which I find a big gain to readability.

No, the compiler won't catch it. It is legal to leave trailing fields off a struct assignment.
It only works if NULL or 0 is a sensible value for all the fields. For this struct, that is not the case. Even if it were, we would have laid a trap for future developers adding new fields.

@markshannon, calling check_code() will catch the problem you described. That said, I don't see this as a problem for this internal API. As to readability. It's what Guido said. To elaborate,: the order doesn't matter and you can leave "args" off if you want to use the default.

Regardless, there isn't a lot of value to a long discussion about this. If you feel strongly about this then I'll change it to a function with many parameters.

When you're done making the requested changes, leave the comment: I have made the requested changes; please review again.

If this PR is too big to review well enough then I'll split it up.

I'm closing this in favor of #26364 and #26375. There are more changes than those cover, but the rest can be dealt with (or abandoned) later.