>> 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 of a feature that determines the need for a formal process, but but whether the community considers a certain change "obviously" correct and desirable. >> def foo(data): >> return compose(a, b(data), c) >> > > Ok, here's my attempt without looking at the patch: > > def foo(data): > def bar(*args, **kwargs): > return a(b(data)(c(*args, **kwargs))) > return bar 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]) when it would really mean l.sort(key=lambda x:x[0][1]) > Whether or not it is easier to read to the "average Python programmer" > is not that important I think. I completely disagree. It is one of Python's strength that it is "executable pseudo-code", which originates from the code being easy to read, and meaning the obvious thing even to a reader not familiar with the language. The proposed compose function breaks this important property, in a way that allows misinterpretation (i.e. you think you know what it does, and it actually does something different). I, personally, was not able to understand the compose function correctly, so I remain opposed. > We have lots of things that certainly > aren't, and yet still exist (all of the functions in the operator > module, for example; or `partial` itself for that matter). They are > there for advanced programmers. It's quite ok if only advanced programmers know that they are there, and know how to write them. However, I still think it is desirable that "lesser" programmers are then able to read them, or atleast notice that they mean something that they will need to learn first (such as a keyword they had never seen before). Regards, Martin _______________________________________________ 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
