I am personally indifferent to this, even though I had in mind in
PEP309, that compose would probably end up in there too.
On the one hand, some people will keep on expecting it to be there. The
ones that care about it will not be confused: they'll expect
compose(f,g)(x) to be f(g(x)) as is pr
On Mon, 17 Aug 2009 07:14:05 pm Stefan Behnel wrote:
> Antoine Pitrou wrote:
> > Raymond Hettinger rcn.com> writes:
> >> IMO, its only virtue is that people coming from functional
> >> languages are used to having compose. Otherwise, it's a YAGNI.
> >
> > Then I wonder how partial() ended up in t
> I have never found these arguments compelling. They are obviously not
> true (e.g., itertools.compress()[1] added in 2.7/3.1), and so what I
> really hear is: "I don't like it and I outrank you."
That certainly contributes to it - if you are not a committer, you have
to find a committer that fin
> and I don't see any reason why a compose() function shouldn't do the
> same.
I was tricked into reading it different when used with getters, i.e.
l.sort(key=compose(attrgetter('name'),attrgetter('age')))
is too easy (IMO) to read as applying foo.name.age on all elements of
the list.
> (Asi
On 17 Aug 2009, at 09:43 , Steven D'Aprano wrote:
On Mon, 17 Aug 2009 08:10:16 am Martin v. Löwis wrote:
I don't think he did. Comparing it to the one obvious solution (use
a lambda expression), his only reasoning was "it is much easier to
read". I truly cannot believe that a compose function w
Le lundi 17 août 2009 à 20:53 +1000, Nick Coghlan a écrit :
> P.S. PEP 309 is wrong when it says a C version probably isn't worthwhile
> - between the time the PEP was first implemented and the time 2.5 was
> actually released, enough investigation was done to show that the speed
> gain from Hye-Sh
Le lundi 17 août 2009 à 09:07 +0200, "Martin v. Löwis" a écrit :
> Ok, that's also what the patch has proposed. I was puzzled when I read
>
>l.sort(key=compose(itemgetter(1), itemgetter(0
>
> because I expected it to mean
>
>l.sort(key=lambda x:x[1][0])
But that's itemgetter's fault
Antoine Pitrou wrote:
>> PEP 309 was written, discussed, approved, and implemented - that's how
>> partial ended up in the stdlib.
>
> Ok, I'm surprised that a single addition to a module needed a PEP in
> order to be approved.
It makes a little more sense once you realise that there was no
funct
Antoine Pitrou wrote:
> Raymond Hettinger rcn.com> writes:
>> IMO, its only virtue is that people coming from functional languages
>> are used to having compose. Otherwise, it's a YAGNI.
>
> Then I wonder how partial() ended up in the stdlib. It seems hardly more
> useful than compose().
I woul
On Mon, 17 Aug 2009 08:10:16 am Martin v. Löwis wrote:
> I don't think he did. Comparing it to the one obvious solution (use
> a lambda expression), his only reasoning was "it is much easier to
> read". I truly cannot believe that a compose function would be
> easier to read to the average Python
Greg Ewing wrote:
> Jason R. Coombs wrote:
>> I had a use case that was compelling enough that I thought there
>> should be something in functools to do what I wanted.
>
> I think this is one of those things that a small minority of
> people would use frequently, but everyone else would use
> very
>> PEP 309 was written, discussed, approved, and implemented - that's how
>> partial ended up in the stdlib.
>
> Ok, I'm surprised that a single addition to a module needed a PEP in
> order to be approved.
A PEP is generally needed if there is no easy consent achievable. It's
not (primarily) the
Jason R. Coombs wrote:
I had a use case that was compelling enough that I thought there
> should be something in functools to do what I wanted.
I think this is one of those things that a small minority of
people would use frequently, but everyone else would use
very rarely or never. The decisi
> PEP 309 was written, discussed, approved, and implemented - that's how
> partial ended up in the stdlib.
Ok, I'm surprised that a single addition to a module needed a PEP in
order to be approved.
Interestingly, here's what the summary section in PEP 309 says:
« A standard library module funct
Martin v. Löwis wrote:
>> The reason I came across the old patch was because I was searching
>> for something that did exactly what compose does. That is to say, I
>> had a use case that was compelling enough that I thought there should
>> be something in functools to do what I wanted. I've encoun
> Then I wonder how partial() ended up in the stdlib.
PEP 309 was written, discussed, approved, and implemented - that's how
partial ended up in the stdlib. The feature itself might be debatable,
that's what we have the PEP process for.
> Either we decide it is useful to have a set of basic "fun
> The reason I came across the old patch was because I was searching
> for something that did exactly what compose does. That is to say, I
> had a use case that was compelling enough that I thought there should
> be something in functools to do what I wanted. I've encountered this
> pattern often
Raymond Hettinger rcn.com> writes:
>
> IMO, its only virtue is that people coming from functional languages
> are used to having compose. Otherwise, it's a YAGNI.
Then I wonder how partial() ended up in the stdlib. It seems hardly more
useful than compose().
Either we decide it is useful to hav
> Raymond Hettinger wrote:
> Sent: Sunday, 16 August, 2009 12:42
>
> [Antoine Pitrou]
> > I also think it would be a nice addition.
> > (but someone has to propose a patch :-))
The patch was proposed and rejected here: http://bugs.python.org/issue1660179;
my reason for mentioning it here is bec
[Antoine Pitrou]
I also think it would be a nice addition.
(but someone has to propose a patch :-))
I agree with Martin's reasons for rejecting the feature request
(see the bug report for his full explanation). IIRC, the compose()
idea had come-up and been rejected in previous discussions as
Jason R. Coombs jaraco.com> writes:
>
> I'm certain there are other, more obscure examples, but I feel these two use
cases demonstrate some fairly
> common potential use cases for something like a composition function.
I also think it would be a nice addition.
(but someone has to propose a patch
Steven D'Aprano wrote:
> Sent: Sunday, 16 August, 2009 08:15
>
> On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote:
>
> >
> > def meta_decorator(data):
> > return compose(dec_register_function_for_x, dec_alter_docstring,
> > dec_inject_some_data(data))
>
> Surely that's better written a
On Sat, 15 Aug 2009 04:39:03 am Jason R. Coombs wrote:
> I'd like to express additional interest in python patch 1660179,
> discussed here:
>
> http://mail.python.org/pipermail/patches/2007-February/021687.html
[...]
> But to me, a compose function is much easier to read and much more
> consistent
It would be best to discuss this on comp.lang.python or python-ideas to get
general support for the idea before trying to bring this to python-dev in
hopes of changing people's minds.
On Fri, Aug 14, 2009 at 11:39, Jason R. Coombs wrote:
> I’d like to express additional interest in python patch
On 14 Aug 2009, at 20:39 , Jason R. Coombs wrote:
I've heard it said that Python is not a functional language, but if
that
were really the case, then functools would not exist. In addition to
the
example described above, I've had multiple occasions where having a
general
purpose function co
I'd like to express additional interest in python patch 1660179, discussed
here:
http://mail.python.org/pipermail/patches/2007-February/021687.html
On several occasions, I've had the desire for something like this. I've
made due with lambda functions, but as was mentioned, the lambda is cl
26 matches
Mail list logo
