> > 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>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4