[issue20360] inspect.Signature could provide readable expressions for default values for builtins

[Brett Cannon]

Change by Brett Cannon :


--
nosy:  -brett.cannon

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20360] inspect.Signature could provide readable expressions for default values for builtins

[Larry Hastings]

New submission from Larry Hastings:

The signatures for builtins are stored as text and interpreted at runtime on 
demand.  inspect.Signature gets the default value for a parameter as a text 
string, which it evaluates (by hand, in a highly constrained way) to produce 
the parameter's value member.

Serhiy cleverly suggested that it'd be nice if Signature objects could also 
make this string available, as it's often more readable than the value.  For 
example, there's a parameter in zlib with the default MAX_DECOMPRESSION - 1; 
that turns into 7 I think.  Which would you prefer?

Right now there's no place to store this in the parameter object, so it can't 
happen for 3.4.  But perhaps in 3.5 we could add it, and figure out how to 
present it to the user.  For example __str__ could use it.


Thinking a little laterally: we *could* hide it in a *private* member on the 
Parameter object, then only use it for calculating __str__.  That would look so 
fancy!  Should we consider doing that for 3.4?

--
messages: 208892
nosy: brett.cannon, larry, ncoghlan, serhiy.storchaka, yselivanov
priority: normal
severity: normal
stage: needs patch
status: open
title: inspect.Signature could provide readable expressions for default values 
for builtins
type: enhancement
versions: Python 3.5

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20360
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue20360] inspect.Signature could provide readable expressions for default values for builtins

[Nick Coghlan]

Nick Coghlan added the comment:

It wouldn't be the first time I've used a private variable to fix a
problem while still abiding by the no-new-features rule, but I think
in this particular case we're better off waiting :)

--

___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue20360
___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com