[Python-Dev] Expected stability of PyCode_New() and types.CodeType() signatures

Pablo Galindo Salgado pablogsal at gmail.com
Sat Jun 1 09:09:34 EDT 2019


>
> I propose to make co_argcount meaning the number of positional
> parameters (i.e. positional-only + positional-or-keyword). This would
> remove the need of changing the code that uses co_argcount.
>

I like the proposal, it will certainly make handling normal cases
downstream much easier because
if you do not care about positional-only arguments you can keep
inspecting co_argcount
and that
will give you what you expect. Note that if we choose to do this, it has to
be done now-ish IMHO to
avoid making the change painful because it will change the semantics of
co_argcount.


> As for the code object constructor, I propose to make posonlyargcount an
> optional parameter (default 0) added after existing parameters.
> PyCode_New() can be kept unchanged, but we can add new PyCode_New2() or
> PyCode_NewEx() with different signature.


I am not convinced about having a default argument in the code constructor.
The code constructor
is kept with all arguments positional for efficiency and adding defaults
will make it slower or having
a more confusing an asymmetrical interface. Also, this will be misaligned
on how keyword-only
parameters are provided. This is by far not the first time this constructor
has changed.

On the Python side, the new code.replace should cover most of the
Python-side use cases regarding
creating code objects from the Python side.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190601/8b1827fb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: license.dash-license
Type: application/octet-stream
Size: 693 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-dev/attachments/20190601/8b1827fb/attachment.obj>


More information about the Python-Dev mailing list