[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-04 Thread Nick Coghlan
Nick Coghlan added the comment: Fix committed for 3.6 - this is obscure enough that I'm not going to worry about fixing it on maintenance branches. -- resolution: -> fixed stage: -> resolved status: open -> closed type: -> behavior versions: -Python 2.7

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-04 Thread Roundup Robot
Roundup Robot added the comment: New changeset 6247dd0f230e by Nick Coghlan in branch 'default': Issue #19611: handle implicit parameters in inspect.signature https://hg.python.org/cpython/rev/6247dd0f230e -- nosy: +python-dev ___ Python tracker

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-03 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: Patch adding @cpython_only decorators to the tests. -- Added file: http://bugs.python.org/file43172/issue19611-decorators.patch ___ Python tracker

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-03 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: This new patch makes the inspect module treat .0-type names as positional-only and renames them to implicit0. Includes a documentation patch too. I'm not too happy with the wording in the documentation, so suggestions for better naming are appreciated.

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Serhiy Storchaka
Serhiy Storchaka added the comment: I have no idea what relations Argument Clinic have with this issue. -- ___ Python tracker ___

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Nick Coghlan
Nick Coghlan added the comment: Oh, I see what you mean, now - we can special case the compiler-generated ".N" names when extracting the signature. I like it - make the claimed parameter something like "implicit0" instead of ".0", mention that in the note on the docs, and folks may have some

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: > We definitely can't use a valid identifier in the code generator, since any > valid identifier we used might shadow a nonlocal, global or builtin name (and > the latter two cases aren't visible to the compiler at compile time). I wasn't proposing to fix

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Nick Coghlan
Nick Coghlan added the comment: We definitely can't use a valid identifier in the code generator, since any valid identifier we used might shadow a nonlocal, global or builtin name (and the latter two cases aren't visible to the compiler at compile time). They're also genuinely not positional

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: > I chatted to Brett Cannon about it, and we agree inspect should handle the > implicit functions generated by the compiler, even if those signatures can't > be expressed in normal Python code. Can we make ".0" parameters positional-only then? And rename

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Nick Coghlan
Nick Coghlan added the comment: The origin of the ".0" parameter name is the compiler's implicit symbol definition - we use the "." prefix for those to ensure we don't accidentally collide with actual identifiers used in the code. We can see that via dis.dis: >>> def make_set(): ...

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Nick Coghlan
Changes by Nick Coghlan : -- assignee: -> ncoghlan nosy: +ncoghlan ___ Python tracker ___

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: Since this only comes up with manually created functions (through calling types.FunctionType), I think it wouldn't be unreasonable to just not handle this case in the inspect module and close this as wontfix. Ned, is there a use case for converting

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: > Yes, it feels ugly. I'd rather "fix" the source of the problem (the weird > positional attribute name). +1. > I have no idea if argument clinic would be of any help here, I haven't looked > at how these things come to be. Me neither. Serhiy, what do you

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread R. David Murray
R. David Murray added the comment: Yes, it feels ugly. I'd rather "fix" the source of the problem (the weird positional attribute name). I have no idea if argument clinic would be of any help here, I haven't looked at how these things come to be. --

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Yury Selivanov
Yury Selivanov added the comment: Jelle, regarding your patch: it would probably be a good idea to only accept ".0"-like names for POSITIONAL_ONLY parameters. Since functions with positional-only parameters can only be created in C, that should make inspect.Parameter less error prone.

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread R. David Murray
R. David Murray added the comment: I wonder if we should do the mention of .0 as a footnote, since it won't matter to most users. What do you think, Yuri? -- ___ Python tracker

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: Fixed patch, added documentation -- Added file: http://bugs.python.org/file43111/issue19611.patch ___ Python tracker

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: Thanks for the comment! It is fragile in the sense that I think there is a good chance that a fix (which is going to rely on details of generated bytecode) will have bugs and break someone's working 2.7 code. The patch's tests have a bug, which I'll fix

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread R. David Murray
R. David Murray added the comment: The patch looks reasonable to me. I've added Yuri to nosy since he's responsible for the signature code in inspect, and he might have an opinion on the appriateness of the fix. I think this special case needs to be documented, since currently the name is

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2016-06-02 Thread Jelle Zijlstra
Jelle Zijlstra added the comment: This doesn't work in Python 3.6 (current dev version) either. Using Ned's example, I get (snipping some of the ipython stack trace): /home/jelle/cpython-dev/cpython/Lib/inspect.py in __init__(self, name, kind, default, annotation) 2399 if not

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2013-11-15 Thread Ned Batchelder
New submission from Ned Batchelder: In 2.7, set comprehensions are compiled to code objects expecting an argument named .0. This convention is also used for the unnamed arguments needed by tuple arguments. inspect.getcallargs understands the tuple argument case, but not the set

[issue19611] inspect.getcallargs doesn't properly interpret set comprehension code objects.

2013-11-15 Thread Ned Batchelder
Ned Batchelder added the comment: BTW: I don't hold any illusions that this bug is important enough to fix, but I would be interested in hearing ideas about how I could work around it... -- ___ Python tracker rep...@bugs.python.org