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.
___
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 Coll
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 c
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 pers
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 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 an
On Tue, Feb 3, 2009 at 11:53 AM, Antoine Pitrou wrote:
> Collin Winter 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 sti
Collin Winter 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 fro
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 wrote:
> On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman wrote:
>> I am just replyin
On Tue, Feb 3, 2009 at 5:44 AM, Ben North 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 fi
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,
On Fri, Jan 30, 2009 at 7:38 PM, Calvin Spealman 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 ide
On Fri, Jan 30, 2009 at 7:42 PM, Antoine Pitrou 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-D
Calvin Spealman 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
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
On 29-Jan-09, at 3:38 PM, Daniel Stutzbach wrote:
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas
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
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'l
s...@blueyonder.co.uk wrote:
Hi all,
On Thu, Jan 29, 2009 at 6:12 AM, Ben North 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
Hi all,
> On Thu, Jan 29, 2009 at 6:12 AM, Ben North 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 rig
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. *, ** a
On Thu, Jan 29, 2009 at 5:24 PM, Mike Klaas 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_com
On Thu, Jan 29, 2009 at 6:12 AM, Ben North 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
On 29-Jan-09, at 3:21 PM, Daniel Stutzbach wrote:
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou
wrote:
Alexander Belopolsky 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
> exac
On Thu, Jan 29, 2009 at 4:04 PM, Antoine Pitrou wrote:
> Alexander Belopolsky 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 wr
Nick Coghlan 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 mis
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 th
Alexander Belopolsky 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 i
On Thu, Jan 29, 2009 at 9:12 AM, Ben North 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
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
Scott David Daniels 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 us
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
Hello,
Ben North 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
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.
_
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 = ',')
and to create a 'log to
34 matches
Mail list logo
