Thanks all for the responses. I read thought them carefully and address
each below.
I don't think any fully address the core problem - The "Argument" - the
tuple of (type, default, documentation) - is currently not a first-class
entity. Because there is no way to reference an Argument, there is much
copypasta and dangerous-default-duplication. The idea of this proposal is
that it should be possible to define an argument in one place, and simply
bind a different name to it in each function signature.
To recap - the points to the proposal are:
- Allow documentation to be bound to an argument: "func(arg_a: int = 3 ?
'doc about arg', ...)" or "func(arg_a: int = 3 # 'doc about arg', ...)"
- Allow reference to argument: "outer_func(new_arg_a_name:
func.args.arg_a.type = func.args.arg_a.default ? 'new doc for arg a', ...)"
- (optionally) a shorthand syntax for reusing type/doc/default of argument:
"def outer_func(new_arg_a_name :=? func.args.arg_a, ...):"
Below I have responded to each comment - please let me know if I missed
something:
----------
On Thu, Apr 25, 2019 at 3:59 PM Robert Vanden Eynde <robertv...@gmail.com>
wrote:
> Looks like a more complicated way to say :
> def f(x:'int : which does stuff' = 5, y:'int : which does more stuffs')
>
I hadn't though of incorporating documentation into the type, that's a nice
idea. I think it's an ok "for now" solution but:
- doing it this way loses the benefits of type inspection (built in to most
IDEs now),
- does not allow you do for instance keep the type definition in the
wrapper while changing the documentation.
- Provides no easy way to reference (f.args.x.documentation) which is a
main point to the proposal.
----------
On Thu, Apr 25, 2019 at 3:58 PM Chris Angelico <ros...@gmail.com> wrote:
> @functools.passes_args(f)
> def wrapper(spam, ham, *a, **kw):
> f(*a, **kw)
> ....
If that were implemented, would it remove the need for this new syntax
> you propose?
>
This does indeed allow defaults and types to be passed on, but I find a
this approach still has the basic flaw of using **kwargs:
- It only really applies to "wrappers" - functions that wrap another
function. The goal here is to address the common case of a function
passing args to a number of functions within it.
- It is assumed that the wrapper should use the same argument names as the
wrapped function. A name should bind a function to an argument - but here
the name is packaged with the argument.
- It remains difficult to determine the arguments of "wrapper" by simple
inspection - added syntax for removal of certain arguments only complicates
the task and seems fragile (lest the wrapped functions argument names
change).
- Renaming an argument to "f" will change the change the arguments of
wrapper - but in a way that's not easy to inspect (so for instance if you
have a call "y = wrapper(arg_1=4)", and you change "f(arg1=....)" to
"f(arg_one=...)" no IDE will catch that and make the appropriate change to
"y=wrapper(arg_one=4)".
- What happens if you're not simply wrapping one sub-function but calling
several? What about when those subfunctions have arguments with the same
name?
----------
On Thu, Apr 25, 2019 at 5:50 PM David Mertz <me...@gnosis.cx> wrote:
> Why not just this in existing Python:
> def func_1(
> a: int = 1 # 'Something about param a',
> b: float = 2.5 # 'Something else about param b',
> ) -> float:
> """Something about func_1
>
> a and b interact in this interesting way.
> a should be in range 0 < a < 125
> floor(b) should be a prime number
>
> Something about return value of func_1
> returns a multiplication
> """
> return a*b
>
- This would currently be a syntax error (because "#" is before the comma),
but sure we could put it after the comma.
- It does not address the fact that we cannot reference "func_1.a.default"
- which is one of the main points of this proposal.
- I'm fine with "#" being the documentation operator instead of "?", but
figured people would not like it because it breaks the precedent of
anything after "#" being ignored by the compiler
---------------
On Thu, Apr 25, 2019 at 9:04 PM Anders Hovmöller <bo...@killingar.net>
wrote:
> Maybe something like...
> def foo(**kwargs):
> “””
> @signature_by:
> full.module.path.to.a.signature_function(pass_kwargs_to=bar,
> hardcoded=[‘quux’])
> “””
> return bar(**kwargs, quux=3)
>
This makes it difficult to see what the names of arguments to "foo" are, at
a glance. And what happens if (as in the example) "foo" does not simply
wrap a function, but distributes arguments to multiple subfunctions? (this
is a common case)
----------------------------
On Fri, Apr 26, 2019 at 2:18 AM Stephen J. Turnbull <
turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> What I would rather see is
>
> (1) Comment syntax "inside" (fvo "inside" including any comment after
> the colon but before docstring or other code) .....
>
> (2) asserts involving parameters lexically are available to help().....
>
(1) I'm fine with "#" being used instead of "?" as the "documentation
operator", but I figured it would be rejected for breaking the president
that everything after "#" is ignored by the compiler.
(2) This would be a nice addition ... if this proposal were actually
implemented, you'd have a built in "Argument" object, and in that case you
could do e.g.:
RGB_IMAGE = Argument(type=np.ndarray, doc = 'An RGB image', check =
lambda img: (img.ndim==3 and img.shape[2]==3))
def brighten_image(image :=? RGB_IMAGE, ...):
...
_______________________________________________
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct: http://python.org/psf/codeofconduct/
