Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #52709 > unrolled thread

Is this PEP-able? (syntax for functools.partial-like functionality)

Back to article view | Back to comp.lang.python

Contents

  Is this PEP-able? (syntax for functools.partial-like functionality) Fábio Santos <fabiosantosart@gmail.com> - 2013-08-20 00:49 +0100
    Re: Is this PEP-able? (syntax for functools.partial-like functionality) Steven D'Aprano <steve@pearwood.info> - 2013-08-20 06:16 +0000
      Re: Is this PEP-able? (syntax for functools.partial-like functionality) Fábio Santos <fabiosantosart@gmail.com> - 2013-08-20 09:28 +0100
      Re: Is this PEP-able? (syntax for functools.partial-like functionality) Ian Kelly <ian.g.kelly@gmail.com> - 2013-08-20 03:11 -0600
      Re: Is this PEP-able? (syntax for functools.partial-like functionality) Fábio Santos <fabiosantosart@gmail.com> - 2013-08-20 10:25 +0100

#52709 — Is this PEP-able? (syntax for functools.partial-like functionality)

[Multipart message — attachments visible in raw view] — view raw

I had an idea for a handy syntax which I thought of while designing a
language for fun. This would be a syntax for creating, from a function, a
function which is just like it but with some parameters pre-filled. The
usage is much like functools.partials, and my proposed syntax is like this:

def spam(a, b, c):
    ...

spam_with_defaults = spam{1, 2}

Now calling spam_with_defaults is just like calling spam, but it only needs
one argument since a and b were set to 1 and 2, respectively.

spam_with_defaults(3)  # same as calling spam(1, 2, 3)

This would also work with keyword arguments, E.G. spam{c=3} would return a
callable which would only need the arguments a and b.

This is just the plain old functools.partial functionality, but of course I
won't stop here. Still on our spam function:

spam_require_b = spam{2, *, 3}
spam_require_ab = spam{*, 3}

spam_require_a(1)  # same as spam(1, 2, 3)
spam_require_ab(1, 2)  # same as above

The * sign means that the function takes positional arguments which will be
added in place of the star. This is how we would do spam_require_b in pure
python:

def spam_require_b(*args, **kwargs):
    return spam(*([1] + args + [2]), **kwargs)

Or, since we know it's only one argument,

spam_require_b = lambda b: spam(1, b, 3)

I also propose unpacking:

spam_unpacking = spam{1, (*, *)}
c = map(spam_unpacking, some_dict.items())

(Although this syntax isn't final), and receiving specific keyword
arguments.

spam_kw = spam{a, b, c=*}

The use cases this is intended to serve are mostly iteration related. There
is the case for being good plumbing for functions such as map, sorted,
filter and itertools.takewhile.

lines = filter(str.startswith{*, '#'}, open('file.cfg'))
lines = filter(bool, map(str.strip, lines))
config = dict(map(str.split{*, '=', 1}, lines))

A secondary use case is the creation of aliases.

def baz(self, callback):
    respond = callback{instance=self}
    ...

What do you think?

PS: yes, I realized that I am proposing the addition of braces to the
language syntax.

[toc] | [next] | [standalone]

#52716

On Tue, 20 Aug 2013 00:49:16 +0100, Fábio Santos wrote:

> I had an idea for a handy syntax which I thought of while designing a
> language for fun. This would be a syntax for creating, from a function,
> a function which is just like it but with some parameters pre-filled.
> The usage is much like functools.partials, and my proposed syntax is
> like this:
> 
> def spam(a, b, c):
>     ...
> 
> spam_with_defaults = spam{1, 2}


Handy it may be, but why is this usage important enough to deserve new 
syntax? The barrier to entry for new syntax is very high. For example, 
Enums are a common, and standard, feature in many programming languages. 
Enums will be introduced to Python in 3.4, but even they don't get 
special syntax.



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#52726

[Multipart message — attachments visible in raw view] — view raw

On 20 Aug 2013 07:22, "Steven D'Aprano" <steve@pearwood.info> wrote:
>
> On Tue, 20 Aug 2013 00:49:16 +0100, Fábio Santos wrote:
>
> > I had an idea for a handy syntax which I thought of while designing a
> > language for fun. This would be a syntax for creating, from a function,
> > a function which is just like it but with some parameters pre-filled.
> > The usage is much like functools.partials, and my proposed syntax is
> > like this:
> >
> > def spam(a, b, c):
> >     ...
> >
> > spam_with_defaults = spam{1, 2}
>
>
> Handy it may be, but why is this usage important enough to deserve new
> syntax? The barrier to entry for new syntax is very high. For example,
> Enums are a common, and standard, feature in many programming languages.
> Enums will be introduced to Python in 3.4, but even they don't get
> special syntax.
>
>
>
> --
> Steven

I do realize that syntax in python is practically written in stone, but I
have seen changes come by if they have good reasons. For example,
keyword-only argument syntax was added.

I suggested this because I thought it would be the most practical way to
create partial functions. Lambda is too verbose and kind of ugly, and its
purpose is not to create partials, functools.partial does not allow
argument "insertion" (the star thing) nor unpacking.

Maybe I saw this as common usage but it is really a special case. I see
myself needing this kind of advanced partials _very_ often.

[toc] | [prev] | [next] | [standalone]

#52729

On Tue, Aug 20, 2013 at 2:28 AM, Fábio Santos <fabiosantosart@gmail.com> wrote:
> I do realize that syntax in python is practically written in stone, but I
> have seen changes come by if they have good reasons. For example,
> keyword-only argument syntax was added.
>
> I suggested this because I thought it would be the most practical way to
> create partial functions. Lambda is too verbose and kind of ugly, and its
> purpose is not to create partials, functools.partial does not allow argument
> "insertion" (the star thing) nor unpacking.

I think that if you're doing argument insertion, then your partial
application is overly complex in the way that it modifies the original
argspec.  You should be looking at it as a new function, not as a
partial application that prevents you from easily supplying a doc
string for it.  If you want to specify an arbitrary combination of
arguments in your partial application, you can already do that using
keyword arguments.  The exception would be if the function being
partially applied takes a *args argument and you want to specify some
of those arguments using partial without specifying earlier arguments.
 That seems like an abuse of partial application to me.

Tuple unpacking in function signatures was a feature in Python 2, and
it was intentionally removed in Python 3, so this is very unlikely to
happen.  See PEP 3113.  Besides which, the syntax you suggest for this
is unintuitive.

   spam_unpacking = spam{1, (*, *)}

To me, this reads that spam_unpacking will take two positional
arguments that will be packed into the second argument sent to spam
(b), and that the third argument to spam (c) is not specified here.  I
don't think that's what you intended.

[toc] | [prev] | [next] | [standalone]

#52733

[Multipart message — attachments visible in raw view] — view raw

On 20 Aug 2013 10:14, "Ian Kelly" <ian.g.kelly@gmail.com> wrote:
>
> On Tue, Aug 20, 2013 at 2:28 AM, Fábio Santos <fabiosantosart@gmail.com>
wrote:
> > I do realize that syntax in python is practically written in stone, but
I
> > have seen changes come by if they have good reasons. For example,
> > keyword-only argument syntax was added.
> >
> > I suggested this because I thought it would be the most practical way to
> > create partial functions. Lambda is too verbose and kind of ugly, and
its
> > purpose is not to create partials, functools.partial does not allow
argument
> > "insertion" (the star thing) nor unpacking.
>
> I think that if you're doing argument insertion, then your partial
> application is overly complex in the way that it modifies the original
> argspec.  You should be looking at it as a new function, not as a
> partial application that prevents you from easily supplying a doc
> string for it.  If you want to specify an arbitrary combination of
> arguments in your partial application, you can already do that using
> keyword arguments.  The exception would be if the function being
> partially applied takes a *args argument and you want to specify some
> of those arguments using partial without specifying earlier arguments.
>  That seems like an abuse of partial application to me.
>
> Tuple unpacking in function signatures was a feature in Python 2, and
> it was intentionally removed in Python 3, so this is very unlikely to
> happen.  See PEP 3113.  Besides which, the syntax you suggest for this
> is unintuitive.
>
>    spam_unpacking = spam{1, (*, *)}
>
> To me, this reads that spam_unpacking will take two positional
> arguments that will be packed into the second argument sent to spam
> (b), and that the third argument to spam (c) is not specified here.  I
> don't think that's what you intended.

No, that syntax was meant to take a tuple and break it into two arguments.
It does read terribly.

Anyway, good points were made and I have seen the light. I've changed my
mind. This is a bad idea.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web