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
On Mon, 17 Aug 2009 07:14:05 pm Stefan Behnel wrote:
Antoine Pitrou wrote:
Raymond Hettinger python at 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
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 size
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 rarely
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
Antoine Pitrou wrote:
Raymond Hettinger python at 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
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
functools
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, not
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-Shik
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
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.
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 finds
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 with
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 as:
Jason R. Coombs jaraco at 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
[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
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 because
Raymond Hettinger python at 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
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
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
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 encountered
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
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
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
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
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 jar...@jaraco.com wrote:
I’d like to express additional
26 matches
Mail list logo
