Path: csiph.com!v102.xanadu-bbs.net!xanadu-bbs.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.xs4all.nl!newsfeed2.news.xs4all.nl!xs4all!post.news.xs4all.nl!not-for-mail Return-Path: X-Original-To: python-list@python.org Delivered-To: python-list@mail.python.org X-Spam-Status: OK 0.000 X-Spam-Evidence: '*H*': 1.00; '*S*': 0.00; 'syntax': 0.04; 'argument': 0.05; 'abuse': 0.07; 'subject:PEP': 0.07; 'string': 0.09; 'arguments': 0.09; 'function,': 0.09; 'happen.': 0.09; 'modifies': 0.09; 'pep': 0.09; 'prevents': 0.09; 'subject:skip:f 10': 0.09; 'cc:addr:python-list': 0.11; 'python': 0.11; 'suggest': 0.14; 'changes': 0.15; '*args': 0.16; '2:28': 0.16; 'added.': 0.16; 'intended.': 0.16; 'lambda': 0.16; 'positional': 0.16; 'specifying': 0.16; 'supplying': 0.16; 'tuple': 0.16; 'unlikely': 0.16; 'unpacking': 0.16; 'which,': 0.16; '\xa0you': 0.16; 'exception': 0.16; 'wrote:': 0.18; 'meant': 0.20; 'written': 0.21; 'seems': 0.21; '(the': 0.22; 'aug': 0.22; 'email addr:gmail.com>': 0.22; 'cc:addr:python.org': 0.22; 'mind.': 0.24; 'specify': 0.24; 'subject:like': 0.24; '\xa0if': 0.24; 'earlier': 0.24; 'cc:2**0': 0.24; "i've": 0.25; '>': 0.26; 'suggested': 0.26; 'second': 0.26; 'header:In-Reply-To:1': 0.27; 'function': 0.29; 'feature': 0.29; '(c)': 0.29; 'am,': 0.29; 'points': 0.29; 'besides': 0.30; 'specified': 0.30; 'message- id:@mail.gmail.com': 0.30; 'doc': 0.31; 'third': 0.33; 'no,': 0.35; 'but': 0.35; 'received:google.com': 0.35; 'combination': 0.36; 'functions.': 0.36; 'keyword': 0.36; 'doing': 0.36; 'should': 0.36; 'example,': 0.37; 'application': 0.37; 'too': 0.37; 'two': 0.37; 'easily': 0.37; 'being': 0.38; 'star': 0.38; 'skip:& 20': 0.39; 'does': 0.39; 'bad': 0.39; 'realize': 0.39; 'changed': 0.39; 'read': 0.60; 'most': 0.60; 'break': 0.61; 'new': 0.61; "you're": 0.61; 'kind': 0.63; 'to:addr:gmail.com': 0.65; '20,': 0.68; 'reads': 0.68; 'subject:this': 0.83; 'partial': 0.84; 'partially': 0.84; 'ugly,': 0.84; 'light.': 0.93; '2013': 0.98 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Imv/AwLS5nx49s9xM/jhTtyFj4fS15SH944U63k4aig=; b=pnTnKQlABSJUS2V42fZ6rf8CfSz80WLydJk2BlRybTezgjSmwLM7T8nXdbzcbAskTJ e9dxgnxBF6GoagWZpaT2frmwryK53ad1NplgI6rtxEoai5URZ2JXectw1MvVPc1TtI4J KQQupXoW+7gVEC1O1ccjCpRaHesImST0W06UticCGIqeZefcpnU2dlGDHT6jwrw1fIns r1QOS3C5NUwlQnPqScmfye3zKcXZze48NizatMGz+GV3Sll4jSkbXbH5+v+t4FIqEL7z wtn6E4+J36FjoHqTLhhjGo4ZgCADkVEOuLFVq1gLmDg1qomot2WAhxzZeR7npR9xzTxF 8vnQ== MIME-Version: 1.0 X-Received: by 10.224.147.141 with SMTP id l13mr317654qav.102.1376990739915; Tue, 20 Aug 2013 02:25:39 -0700 (PDT) In-Reply-To: References: <521309d0$0$29885$c3e8da3$5496439d@news.astraweb.com> Date: Tue, 20 Aug 2013 10:25:39 +0100 Subject: Re: Is this PEP-able? (syntax for functools.partial-like functionality) From: =?ISO-8859-1?Q?F=E1bio_Santos?= To: Ian Kelly Content-Type: multipart/alternative; boundary=089e0149cdb4e96a9004e45da3f8 Cc: Python X-BeenThere: python-list@python.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: General discussion list for the Python programming language List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Newsgroups: comp.lang.python Message-ID: Lines: 116 NNTP-Posting-Host: 2001:888:2000:d::a6 X-Trace: 1376990742 news.xs4all.nl 15875 [2001:888:2000:d::a6]:40102 X-Complaints-To: abuse@xs4all.nl Xref: csiph.com comp.lang.python:52733 --089e0149cdb4e96a9004e45da3f8 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable On 20 Aug 2013 10:14, "Ian Kelly" wrote: > > On Tue, Aug 20, 2013 at 2:28 AM, F=E1bio Santos 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 t= o > > 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 =3D 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. --089e0149cdb4e96a9004e45da3f8 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable


On 20 Aug 2013 10:14, "Ian Kelly" <ian.g.kelly@gmail.com> wrote:
>
> On Tue, Aug 20, 2013 at 2:28 AM, F=E1bio Santos <fabiosantosart@gmail.com> wrote:
> > I do realize that syntax in python is practically written in ston= e, 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 all= ow 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. =A0You 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. =A0If you want to specify an arbitrary combination of > arguments in your partial application, you can already do that using > keyword arguments. =A0The exception would be if the function being
> partially applied takes a *args argument and you want to specify some<= br> > of those arguments using partial without specifying earlier arguments.=
> =A0That seems like an abuse of partial application to me.
>
> Tuple unpacking in function signatures was a feature in Python 2, and<= br> > it was intentionally removed in Python 3, so this is very unlikely to<= br> > happen. =A0See PEP 3113. =A0Besides which, the syntax you suggest for = this
> is unintuitive.
>
> =A0 =A0spam_unpacking =3D 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. = =A0I
> 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&#= 39;ve changed my mind. This is a bad idea.

--089e0149cdb4e96a9004e45da3f8--