[Python-Dev] Partial function application 'from the right'
Hi, As suggested, I've created http://bugs.python.org/issue5191 to hold the patches for this feature, and the relation to the 'partial.skip' feature request. Could somebody with appropriate privileges close the issue as rejected, if indeed that is the decision? Thanks, Ben. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Ben North wrote: Hi, My reading of the most recent set of emails on this topic is that the balance of opinion is against adding a 'partial_right' or 'partial.skip' feature. I still think such a feature would be of real use, although I can see the arguments against adding it. Is the conclusion 'no thanks', then? There's a partial.skip patch on the tracker already: http://bugs.python.org/issue1706256 While it has been rejected, chiming in still wouldn't hurt (in case we ever decide to revisit the idea). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On 5 Feb 2009, at 23:54 , Steven D'Aprano wrote: Raymond Hettinger wrote: The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. Quite so, but that doesn't justify adding more capabilities to partial(). I concur with Collin. Lever arguments are a road to bloat. One person's bloat is another person's rich and complete toolbox. In for a penny, in for a pound is not a language design principle. Neither are slippery slope arguments. One of the real problems with partial() and its variants is that they provide almost no advantage over an equivalent lambda. How about speed? I don't have a recent version of Python here to test, but my recollection is that partial is significantly faster than lambda. And even if it currently isn't, there could be (is?) more opportunity to optimize partial. I guess that the voting on this is going to be fall along functional lines: those who like functional languages will vote +1 on partial and co, and those who don't will vote -1. While I don't dislike partial(), I'd rather see one good use-case for partial_right() to be removed: built-ins that don't accept keywords. From Ben North's post starting this thread: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. E.g., to create a function which splits a string on commas, you can't say # Won't work when called: split_comma = partial(str.split, sep = ',') and to create a 'log to base 10' function, you can't say # Won't work when called: log_10 = partial(math.log, base = 10.0) because str.split and math.log don't take keyword arguments. Wouldn't a `flip` function (reverse the order of the function's arguments) be more flexible and general than a `partial_right` one? Your first case would become # we're not ignoring any argument, so we have to provide `maxsplit` split_comma = partial(flip(str.split), None, ',') and the second one would yield log_10 = partial(flip(math.log), 10.0) and if we only want to fill-in the rightmost argument, we can flip the result to get the original order back: split_5 = flip(partial(flip(str.split), 5)) While better kwargs support would be even better, there probably always will be kwarg-less functions/methods, so the ability to partially apply from the right stays interesting. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Partial function application 'from the right'
Hi, My reading of the most recent set of emails on this topic is that the balance of opinion is against adding a 'partial_right' or 'partial.skip' feature. I still think such a feature would be of real use, although I can see the arguments against adding it. Is the conclusion 'no thanks', then? (I still have not had time to create an issue in the tracker and attach the patch, but will do so for completeness.) Thanks for the discussions, Ben. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Raymond Hettinger wrote: The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. Quite so, but that doesn't justify adding more capabilities to partial(). I concur with Collin. Lever arguments are a road to bloat. One person's bloat is another person's rich and complete toolbox. In for a penny, in for a pound is not a language design principle. Neither are slippery slope arguments. One of the real problems with partial() and its variants is that they provide almost no advantage over an equivalent lambda. How about speed? I don't have a recent version of Python here to test, but my recollection is that partial is significantly faster than lambda. And even if it currently isn't, there could be (is?) more opportunity to optimize partial. I guess that the voting on this is going to be fall along functional lines: those who like functional languages will vote +1 on partial and co, and those who don't will vote -1. While I don't dislike partial(), I'd rather see one good use-case for partial_right() to be removed: built-ins that don't accept keywords. From Ben North's post starting this thread: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. E.g., to create a function which splits a string on commas, you can't say # Won't work when called: split_comma = partial(str.split, sep = ',') and to create a 'log to base 10' function, you can't say # Won't work when called: log_10 = partial(math.log, base = 10.0) because str.split and math.log don't take keyword arguments. I'd argue that it is better to add support for keyword arguments than to add partial_right. -- Steven ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Partial function application 'from the right'
Hi,
Thanks for the further responses. Again, I'll try to summarise:
Scott David Daniels pointed out an awkward interaction when chaining
partial applications, such that it could become very unclear what was
going to happen when the final function is called:
If you have:
def button(root, position, action=None, text='*', color=None):
...
...
blue_button = partial(button, my_root, color=(0,0,1))
Should partial_right(blue_button, 'red') change the color or the text?
Calvin Spealman mentioned a previous patch of his which took the 'hole'
approach, i.e.:
[...] my partial.skip patch, which allows the following usage:
split_one = partial(str.split, partial.skip, 1)
This would solve my original problems, and, continuing Scott's example,
def on_clicked(...): ...
_ = partial.skip
clickable_blue_button = partial(blue_button, _, on_clicked)
has a clear enough meaning I think:
clickable_blue_button('top-left corner')
= blue_button('top-left corner', on_clicked)
= button(my_root, 'top-left corner', on_clicked, color=(0,0,1))
Calvin's idea/patch sounds good to me, then. Others also liked it.
Could it be re-considered, instead of the partial_right idea?
Ben.
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Tue, Feb 3, 2009 at 5:44 AM, Ben North b...@redfrontdoor.org wrote:
Hi,
Thanks for the further responses. Again, I'll try to summarise:
Scott David Daniels pointed out an awkward interaction when chaining
partial applications, such that it could become very unclear what was
going to happen when the final function is called:
If you have:
def button(root, position, action=None, text='*', color=None):
...
...
blue_button = partial(button, my_root, color=(0,0,1))
Should partial_right(blue_button, 'red') change the color or the text?
Calvin Spealman mentioned a previous patch of his which took the 'hole'
approach, i.e.:
[...] my partial.skip patch, which allows the following usage:
split_one = partial(str.split, partial.skip, 1)
This would solve my original problems, and, continuing Scott's example,
def on_clicked(...): ...
_ = partial.skip
clickable_blue_button = partial(blue_button, _, on_clicked)
has a clear enough meaning I think:
clickable_blue_button('top-left corner')
= blue_button('top-left corner', on_clicked)
= button(my_root, 'top-left corner', on_clicked, color=(0,0,1))
Calvin's idea/patch sounds good to me, then. Others also liked it.
Could it be re-considered, instead of the partial_right idea?
Have any of the original objections to Calvin's patch
(http://bugs.python.org/issue1706256) been addressed? If not, I don't
see anything in these threads that justify resurrecting it.
I still haven't seen any real code presented that would benefit from
partial.skip or partial_right.
Collin Winter
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
http://bugs.python.org/issue1706256 Took me a couple days to catch up on this thread so here is the link for any interested. Could it be possible to reevaluate this? On Sat, Jan 31, 2009 at 2:40 PM, Leif Walsh leif.wa...@gmail.com wrote: On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman ironfro...@gmail.com wrote: I am just replying to the end of this thread to throw in a reminder about my partial.skip patch, which allows the following usage: split_one = partial(str.split, partial.skip, 1) Not looking to say mine is better, but if the idea is being given merit, I like the skipping arguments method better than just the right partial, which I think is confusing combined with keyword and optional arguments. And, this patch already exists. Could it be re-evaluated? +1 but I don't know where the patch is. -- Cheers, Leif -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Tue, Feb 3, 2009 at 11:53 AM, Antoine Pitrou solip...@pitrou.net wrote: Collin Winter collinw at gmail.com writes: Have any of the original objections to Calvin's patch (http://bugs.python.org/issue1706256) been addressed? If not, I don't see anything in these threads that justify resurrecting it. I still haven't seen any real code presented that would benefit from partial.skip or partial_right. The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. Quite so, but that doesn't justify adding more capabilities to partial(). Collin Winter ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
I still haven't seen any real code presented that would benefit from partial.skip or partial_right. # some Articles have timestamp attributes and some don't stamp = partial_right(getattr, 'timestamp', 0) lastupdate = max(map(stamp, articles)) # some beautiful soup nodes have a name attribute and some don't name = partial_right(getattr, 'name', '') alltags = set(map(name, soup)) The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. Quite so, but that doesn't justify adding more capabilities to partial(). I concur with Collin. Lever arguments are a road to bloat. In for a penny, in for a pound is not a language design principle. One of the real problems with partial() and its variants is that they provide almost no advantage over an equivalent lambda. IMO, lambda has an advantage over partial.skip() because the lambda is easier to read: modcubes = lambda base, mod: pow(base, 3, mod) Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Collin Winter collinw at gmail.com writes: Have any of the original objections to Calvin's patch (http://bugs.python.org/issue1706256) been addressed? If not, I don't see anything in these threads that justify resurrecting it. I still haven't seen any real code presented that would benefit from partial.skip or partial_right. The arguments for and against the patch could be brought against partial() itself, so I don't understand the -1's at all. I know I hardly every use partial() (apart from the performance aspect, it looks like a completely useless addition to me), but from a performance standpoint, partial.skip has as much usefulness as partial() itself. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman ironfro...@gmail.com wrote: I am just replying to the end of this thread to throw in a reminder about my partial.skip patch, which allows the following usage: split_one = partial(str.split, partial.skip, 1) Not looking to say mine is better, but if the idea is being given merit, I like the skipping arguments method better than just the right partial, which I think is confusing combined with keyword and optional arguments. And, this patch already exists. Could it be re-evaluated? +1 but I don't know where the patch is. -- Cheers, Leif ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org wrote: Hi, I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. -1 For me, the main objection to a partial that places its stored positional arguments from the right is that you don't know which positions those arguments will actually occupy until the partial is called. Who *really* thinks that would be a neat feature? There's probably a reason why Haskell doesn't do this... Peter Harris ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
s...@blueyonder.co.uk wrote: Hi all, On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org wrote: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. -1 For me, the main objection to a partial that places its stored positional arguments from the right is that you don't know which positions those arguments will actually occupy until the partial is called. Certainly this interacts in a magical way with keyword args. That definitional problem is the reason there was no curry_right in the original recipe that was the basis of the first partial. If you have: def button(root, position, action=None, text='*', color=None): ... ... blue_button = partial(button, my_root, color=(0,0,1)) Should partial_right(blue_button, 'red') change the color or the text? It is computationally hard to do that (may have to chase chains of **kwarg-passing functions), but even hard to document. So, I'd avoid it. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Partial function application 'from the right'
Hi, [ Potential new functools.partial_right, e.g., split_comma = partial_right(str.split, '.') ] Thanks for the feedback. Apologies if (as was suggested) this should have gone to python-ideas; I thought as a fairly small extension to existing functionality it would be OK here. I'll try to summarise the responses. There was some very luke-warm support. Terry Reedy suggested it would be worth posting a patch to the tracker, for the record, even if it turns out to be rejected. Nick Coghlan made more clear than I did the main reason a 'partial_right' would be useful: [...] some functions and methods written in C (such as string methods) *don't* [support keyword args], so partial's keyword support doesn't help. A functools.rpartial would go some way towards addressing that. On the other hand, Collin Winter asked for more evidence that real benefit (beyond mere 'completeness' of the functools module) would result. I don't really have to hand anything more than the three cases mentioned in my original email (str.split, math.log, itertools.islice), but since the change is so small, I thought the feature worth raising. Leif Walsh pointed out that you could achieve the same effect by defining your own function. This is true, but functools.partial exists because it's sometimes useful to create such functions either more concisely, or anonymously. A 'partial_right' would allow more such functions to be so created. Peter Harris was negative on the idea, pointing out that after g = partial_right(f, 7) you don't know which argument of 'f' the '7' is going to end up as, because it depends on how many are supplied in the eventual call to 'g'. This is true, and would require some care in partial_right's use. Peter also wondered There's probably a reason why Haskell doesn't do this... I have only written about five lines of Haskell in my life, so take this with a hefty pinch of salt, but: Haskell does have a 'flip' function which reverses the order of a function's arguments, so it looks like you can very easily build a 'partial_right' in Haskell, especially since standard functions are in curried form. There was some discussion (started by Antoine Pitrou) of an idea to generalise 'partial' further, potentially using the Ellipsis object, to allow arbitrarily-placed 'holes' in the argument list. E.g., split_comma = partial(str.split, ..., ',') In some ways I quite like the even-more-completeness of this idea, but think that it might be the wrong side of the complexity/benefit trade-off. Scott David Daniels pointed out that using Ellipsis would have the downside of [...] preventing any use of partial when an argument could be an the Ellipsis instance. This could be fixed by making the general form be something with the meaning partial_explicit(f, hole_sentinel, *args, **kwargs) where appearances of the exact object 'hole_sentinel' in 'args' would indicate a hole, to be filled in at the time of the future call. A user wanting to have '...' passed in as a true argument could then do g = partial_explicit(f, None, 3, ..., 4, axis = 2) or hole = object() g = partial_explicit(f, hole, 3, ..., hole, 4, axis = 2) if they wanted a true '...' argument and a hole. (I might have the syntax for this wrong, having not played with Python 3.0, but I hope the idea is clear.) There was some concern expressed (by Daniel Stutzbach, Alexander Belopolsky) that the meaning of '...' would be confusing --- 'one hole' or 'arbitrary many holes'? I think the extra complexity vs extra functionality trade-off is worth considering for 'partial_right', but my personal opinion is that a 'partial_explicit' has that trade-off the wrong way. I'll try to find time to create the patch in the tracker in the next few days, by which time perhaps it'll have become clearer whether the idea is a good one or not. Thanks, Ben. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
I am just replying to the end of this thread to throw in a reminder about my partial.skip patch, which allows the following usage: split_one = partial(str.split, partial.skip, 1) Not looking to say mine is better, but if the idea is being given merit, I like the skipping arguments method better than just the right partial, which I think is confusing combined with keyword and optional arguments. And, this patch already exists. Could it be re-evaluated? On Fri, Jan 30, 2009 at 4:20 PM, Mike Klaas mike.kl...@gmail.com wrote: On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote: On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas mike.kl...@gmail.com wrote: And yet, python isn't confined to mathematical notation. *, ** are both overloaded for use in argument lists to no-one's peril, AFAICT. Certainly, but there is no danger of confusion them for multiplication in context, whereas: split_comma = partial(str.split, ..., ',') to me looks like make ',' the last argument rather than make ',' the second argument. Yes, I agree. I mistakenly thought that that was the proposal under discussion (that partial(f, ..., 2) == right_curry(f, 2)) -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ironfroggy%40gmail.com -- Read my blog! I depend on your acceptance of my opinion! I am interesting! http://techblog.ironfroggy.com/ Follow me if you're into that sort of thing: http://www.twitter.com/ironfroggy ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Calvin Spealman ironfroggy at gmail.com writes: I am just replying to the end of this thread to throw in a reminder about my partial.skip patch, which allows the following usage: split_one = partial(str.split, partial.skip, 1) Not looking to say mine is better, but if the idea is being given merit, I like the skipping arguments method better than just the right partial, which I think is confusing combined with keyword and optional arguments. And, this patch already exists. Could it be re-evaluated? Sorry, where is the patch? If one writes X = partial.skip, it looks quite nice: split_one = partial(str.split, X, 1) Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou solip...@pitrou.net wrote: .. If one writes X = partial.skip, it looks quite nice: split_one = partial(str.split, X, 1) Or even _ = partial.skip split_one = partial(str.split, _, 1) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Ben North wrote: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. ... Would there be any interest in this? I think so. Post your patch to the tracker. Even if eventually rejected, it will be there for people to use. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Hello, Ben North ben at redfrontdoor.org writes: I find 'functools.partial' useful, but occasionally I'm unable to use it because it lacks a 'from the right' version. E.g., to create a function which splits a string on commas, you can't say # Won't work when called: split_comma = partial(str.split, sep = ',') In py3k, we could also use ... (the Ellipsis object) to denote places where an argument is missing, so that: split_comma = partial(str.split, ..., ',') would do what you want. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Antoine Pitrou wrote: ... In py3k, we could also use ... (the Ellipsis object) to denote places where an argument is missing, so that: split_comma = partial(str.split, ..., ',') would do what you want. Thus preventing any use of partial when an argument could be an the Ellipsis instance. --Scott David Daniels scott.dani...@acm.org ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Scott David Daniels Scott.Daniels at Acm.Org writes: Antoine Pitrou wrote: ... In py3k, we could also use ... (the Ellipsis object) to denote places where an argument is missing, so that: split_comma = partial(str.split, ..., ',') would do what you want. Thus preventing any use of partial when an argument could be an the Ellipsis instance. Obviously, it is the drawback :) But Ellipsis is hardly used anywhere, and it reads good in this very use case. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
This discussion probably belongs to python-ideas, but since we already have this thread, I'll reply here instead of opening a new thread there. Ellipsis was introduced into python to serve needs of the numeric python community. If you think of numpy multiarrays as functions taking ndim number of arguments, then ellipsis is used to denote any number of missing arguments and : is used to denote a single missing argument. By this analogy, partial(f, ..., *args) is right_partial with '...' standing for any number of missing arguments. I you want to specify exactly one missing argument, you would want to write partial(f, :, *args), which is not a valid syntax even in Py3. If one is willing to use [] instead of () with partial, it is possible to implement partial[f, ..., *args] and partial[f, x, :, z] already in Py2, but I would rather see : allowed in the argument lists or some other short syntax for missing arguments. If such syntax is introduced, the need for partial may even go away with partial(str.split, :, ',') spelled simply as str.split(:, ','). On Thu, Jan 29, 2009 at 3:04 PM, Antoine Pitrou solip...@pitrou.net wrote: Scott David Daniels Scott.Daniels at Acm.Org writes: Antoine Pitrou wrote: ... In py3k, we could also use ... (the Ellipsis object) to denote places where an argument is missing, so that: split_comma = partial(str.split, ..., ',') would do what you want. Thus preventing any use of partial when an argument could be an the Ellipsis instance. Obviously, it is the drawback :) But Ellipsis is hardly used anywhere, and it reads good in this very use case. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/alexander.belopolsky%40gmail.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Thu, Jan 29, 2009 at 9:12 AM, Ben North b...@redfrontdoor.org wrote:
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
First of all, many functions like this are easy to handle yourself. Example:
def split_comma(s):
return str.split(s, ',')
That said, it seems to me that if we're going to add to
functools.partial, we should go all the way and allow keyword
arguments (or a dict of them, if it's otherwise too hard to
implement). Otherwise, in another few {days, weeks, months} we'll see
another thread like this clamoring for a keyword-sensitive
functools.partial.
Come to think of it, I would imagine the next iteration would ask for
a way to curry arbitrary positional arguments, and I can't come up
with a simple and beautiful way to do that off the top of my head.
Maybe this is an argument for keeping functools.partial the way it is
and forcing developers to write their own currying functions.
--
Cheers,
Leif
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Alexander Belopolsky alexander.belopolsky at gmail.com writes: By this analogy, partial(f, ..., *args) is right_partial with '...' standing for any number of missing arguments. I you want to specify exactly one missing argument, you would want to write partial(f, :, *args), which is not a valid syntax even in Py3. Yes, of course, but... the meaning which numpy attributes to Ellipsis does not have to be the same in other libraries. Otherwise this meaning would have been embedded in the interpreter itself, while it hasn't. The point of using Ellipsis in this case is not to be numpy-friendly, but rather to exploit the fact that it is a very rarely used object, and that it has an alternate spelling which suits very well (visually speaking) the purpose being discussed. Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Leif Walsh wrote:
That said, it seems to me that if we're going to add to
functools.partial, we should go all the way and allow keyword
arguments (or a dict of them, if it's otherwise too hard to
implement). Otherwise, in another few {days, weeks, months} we'll see
another thread like this clamoring for a keyword-sensitive
functools.partial.
functools.partial *does* support keyword arguments - it's just that some
functions and methods written in C (such as string methods) *don't*, so
partial's keyword support doesn't help.
A functools.rpartial would go some way towards addressing that.
Using the standalone Ellipsis to denote missing arguments would probably
start to miss the whole point of functools.partial: the only reason for
its existence is that it is *faster than the equivalent Python function*.
If partial starts messing about looking for missing arguments and then
slotting them in, then it is likely to slow down to the point where you
would be better off skipping it and writing a dedicated function that
adds the extra arguments.
Cheers,
Nick.
--
Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia
---
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Nick Coghlan ncoghlan at gmail.com writes: If partial starts messing about looking for missing arguments and then slotting them in, then it is likely to slow down to the point where you would be better off skipping it and writing a dedicated function that adds the extra arguments. Looking for missing arguments is very cheap, just raw pointer compares (Ellipsis is a singleton). In comparison, the cost of executing a dedicated Python function would be overwhelming. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou solip...@pitrou.net wrote: Alexander Belopolsky alexander.belopolsky at gmail.com writes: By this analogy, partial(f, ..., *args) is right_partial with '...' standing for any number of missing arguments. I you want to specify exactly one missing argument, you would want to write partial(f, :, *args), which is not a valid syntax even in Py3. Yes, of course, but... the meaning which numpy attributes to Ellipsis does not have to be the same in other libraries. Otherwise this meaning would have been embedded in the interpreter itself, while it hasn't. The meaning which numpy attributes to Ellipsis is also the meaning that mathematical notation has attached to Ellipsis for a very long time. See: http://en.wikipedia.org/wiki/Ellipsis#In_mathematical_notation -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote: On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou solip...@pitrou.net wrote: Alexander Belopolsky alexander.belopolsky at gmail.com writes: By this analogy, partial(f, ..., *args) is right_partial with '...' standing for any number of missing arguments. I you want to specify exactly one missing argument, you would want to write partial(f, :, *args), which is not a valid syntax even in Py3. Yes, of course, but... the meaning which numpy attributes to Ellipsis does not have to be the same in other libraries. Otherwise this meaning would have been embedded in the interpreter itself, while it hasn't. The meaning which numpy attributes to Ellipsis is also the meaning that mathematical notation has attached to Ellipsis for a very long time. And yet, python isn't confined to mathematical notation. *, ** are both overloaded for use in argument lists to no-one's peril, AFAICT. -Mike ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Thu, Jan 29, 2009 at 6:12 AM, Ben North b...@redfrontdoor.org wrote:
Hi,
I find 'functools.partial' useful, but occasionally I'm unable to use it
because it lacks a 'from the right' version. E.g., to create a function
which splits a string on commas, you can't say
# Won't work when called:
split_comma = partial(str.split, sep = ',')
[snip]
I've created a patch which adds a 'partial_right' function. The two
examples above:
import functools, math
split_comma = functools.partial_right(str.split, ',')
split_comma('a,b,c')
['a', 'b', 'c']
log_10 = functools.partial_right(math.log, 10.0)
log_10(100.0)
2.0
Can you point to real code that this makes more readable?
Collin
___
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas mike.kl...@gmail.com wrote: And yet, python isn't confined to mathematical notation. *, ** are both overloaded for use in argument lists to no-one's peril, AFAICT. Certainly, but there is no danger of confusion them for multiplication in context, whereas: split_comma = partial(str.split, ..., ',') to me looks like make ',' the last argument rather than make ',' the second argument. -- Daniel Stutzbach, Ph.D. President, Stutzbach Enterprises, LLC http://stutzbachenterprises.com ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Partial function application 'from the right'
Mike Klaas wrote: On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote: [...] The meaning which numpy attributes to Ellipsis is also the meaning that mathematical notation has attached to Ellipsis for a very long time. And yet, python isn't confined to mathematical notation. *, ** are both overloaded for use in argument lists to no-one's peril, AFAICT. With the crucial difference that * and ** are purely syntax, but Ellipsis is an object. -Andrew. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
