First of all, thank you for telling me this. I didn't even know that positional-only parameters existed at all until a few days ago when I discovered them while exploring this issue, let alone that they had been added to Python functions in 3.8.
Second, after poking around a bit in 3.8, it looks like the positional-only args don't actually impact the __defaults__ attribute (or the argdefs parameter). This is pretty much what I expected when I initially read your message, since the positional-only parameters are part of the same ordered set as the normal positional parameters. In a regular function signature, having a default positional followed by a non-default positional is still a SyntaxError, regardless of where the positional-only split is; this means all default positionals are still consecutive and it still only needs one tuple to specify their values. This was a good question to ask, though, since that feature definitely seemed like something that might be problematic; I'll be sure to rebase my changes from 3.7 onto 3.8 to make sure nothing else in the update breaks them. On Fri, Oct 18, 2019 at 9:34 AM Anders Hovmöller <[email protected]> wrote: > Just thinking aloud here but when you say "positional" parameters you mean > normal parameters and not positional only parameters as introduced in 3.8 > right? > > And how would those fit into this picture? > > > On 18 Oct 2019, at 15:31, Gus Wiedey <[email protected]> wrote: > > > > > > I was recently playing around with decorators and experimenting with > defining a function's signature dynamically at runtime, and came across the > builtins.function class constructor (more easily accessible through the > types.FunctionType alias). I quickly realized, however, that even though > the constructor has a parameter (argdefs) that is used to specify default > values for the resulting function's positional arguments, there is no > corresponding parameter for keyword-only argument defaults. This seems like > a glaring omission, especially considering the fact that argdefs takes a > tuple that is directly assigned (unmodified) to the __defaults__ attribute. > I can't find any obvious reason why there shouldn't be a similar "kwdefs" > parameter that takes a dict and assigns it to __kwdefaults__. I downloaded > the cpython repo, made this change myself as proof-of-concept, and compiled > it, and it appears to work fine. This brings me to two questions: > > > > 1. Is there a reason for this disparity that I'm not seeing (e.g. > breaking some other feature), or is it just an oversight? > > 2. If I wanted to submit this as an actual language change, would I need > to write a full PEP or is it small enough that it could go to the issue > tracker? (Note that the documentation says this constructor can vary > between implementations, so the change would only apply to cpython if that > matters.) > > > > Also, if this is the wrong place to ask this, please feel free to set me > straight; I'm completely new to this whole process, so any help on where to > start would be appreciated. > > _______________________________________________ > > Python-ideas mailing list -- [email protected] > > To unsubscribe send an email to [email protected] > > https://mail.python.org/mailman3/lists/python-ideas.python.org/ > > Message archived at > https://mail.python.org/archives/list/[email protected]/message/3ETG4HAKR2WQWAKAFCHU4UMC5X37OHKZ/ > > Code of Conduct: http://python.org/psf/codeofconduct/ >
_______________________________________________ Python-ideas mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3/lists/python-ideas.python.org/ Message archived at https://mail.python.org/archives/list/[email protected]/message/TCM6D6Y35GDS7R6SXEBZZ26XQMLOTYD6/ Code of Conduct: http://python.org/psf/codeofconduct/
