Re: [Python-Dev] functools.compose to chain functions together
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 the stdlib. It seems > > hardly more useful than compose(). > > I would certainly consider it more useful, but that aside, it's > also a lot simpler to understand and use than the proposed > compose() function. I think the main difference is that compose() > requires functional/math skills to be used and read correctly (and > might still be surprising in some corner cases), whereas partial() > only requires you to understand how to set a function argument. > Totally different level of mental complexity, IMHO. I find the opposite -- compose() seems completely simple and straight-forward to me, while partial() is still a mystery no matter how many times I use it. I always have to look it up to see which way it binds. Putting that aside, partial() too is easy enough to implement with lambda: partial(f, 2) is the same as lambda *args: f(2, *args). To my mind, there are two important reasons for preferring named functions like partial() and compose() over lambda solutions: * performance: a good C implementation should be better than a pure-Python lambda; and * specificity: there's only one thing compose() or partial() could do, whereas a lambda is so general it could do anything. Contrast: compose(f, g, h) lambda x: f(g(h(x))) You need to read virtually the entire lambda before you can distinguish it from some other arbitrary lambda: lambda x: f(g(h))(x) lambda x: f(g(x) or h(x)) lambda x: f(g(x)) + h(x) etc. -- Steven D'Aprano ___ 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] Mercurial migration: help needed
This is a repost from two weeks ago. It didn't get much feedback last time. I still keep trying, reposting to python-list also this time. In this thread, I'd like to collect things that ought to be done but where Dirkjan has indicated that he would prefer if somebody else did it. Item 1 -- The first item is build identification. If you want to work on this, please either provide a patch (for trunk and/or py3k), or (if you are a committer) create a subversion branch. It seems that Barry and I agree that for the maintenance branches, sys.subversion should be frozen, so we need actually two sets of patches: one that removes sys.subversion entirely, and the other that freezes the branch to the respective one, and freezes the subversion revision to None. The patch should consider what Dirkjan proposes as the branching strategy: clones to separate 2.x and 3.x, as well as for features, and branches with the clones for releases and maintenance (see the PEP for details). Anybody working on this should have good knowledge of the Python source code, Mercurial, and either autoconf or Visual Studio (preferably both). Item 2 -- The second item is line conversion hooks. Dj Gilcrease has posted a solution which he considers a hack himself. Mark Hammond has also volunteered, but it seems some volunteer needs to be "in charge", keeping track of a proposed solution until everybody agrees that it is a good solution. It may be that two solutions are necessary: a short-term one, that operates as a hook and has limitations, and a long-term one, that improves the hook system of Mercurial to implement the proper functionality (which then might get shipped with Mercurial in a cross-platform manner). 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
Re: [Python-Dev] Mercurial migration: help needed
On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote: > In this thread, I'd like to collect things that ought to be done > but where Dirkjan has indicated that he would prefer if somebody else > did it. I think the most important item here is currently the win32text stuff. Mark Hammond said he would work on this; Mark, when do you have time for this? Then I could set apart some time for it as well. Have stalled a bit on the fine-grained branch processing, hope to move that forward tomorrow. Cheers, Dirkjan ___ 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] VC++ versions to match python versions?
On Mon, Aug 17, 2009 at 2:01 PM, David Bolen wrote: > Chris Withers writes: > >> Is the Express Edition of Visual C++ 2008 suitable for compiling >> packages for Python 2.6 on Windows? >> (And Python 2.6 itself for that matter...) > > Yes - it's currently being used on my buildbot, for example, to build > Python itself. Works for 2.6 and later. > >> Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) > > 2.5 needs VS 2003. The 64 bits version of 2.5 is built with VS 2005, though. cheers, David ___ 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] Mercurial migration: help needed
On 18/08/2009 6:20 PM, Dirkjan Ochtman wrote: On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote: In this thread, I'd like to collect things that ought to be done but where Dirkjan has indicated that he would prefer if somebody else did it. I think the most important item here is currently the win32text stuff. Mark Hammond said he would work on this; Mark, when do you have time for this? Then I could set apart some time for it as well. I can make time, somewhat spasmodically, starting fairly soon. Might I suggest that as a first task I can resurrect my old stale patch, and you can arrange to install win32text locally and start experimenting with how mixed line-endings can work for you. Once we are all playing in the same ballpark I think we should be able to make good progress. I-said-ballpark-yet-I-call-myself-an-aussie? ly, Mark ___ 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] Mercurial migration: help needed
On Tue, Aug 18, 2009 at 13:32, Mark Hammond wrote: > I can make time, somewhat spasmodically, starting fairly soon. Might I > suggest that as a first task I can resurrect my old stale patch, and you can > arrange to install win32text locally and start experimenting with how mixed > line-endings can work for you. Once we are all playing in the same ballpark > I think we should be able to make good progress. Sounds good to me. Cheers, Dirkjan ___ 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] Mercurial migration: help needed
[stripping out python-list and Mark from the CC] On Tue, Aug 18, 2009 at 01:20, Dirkjan Ochtman wrote: > On Tue, Aug 18, 2009 at 10:12, "Martin v. Löwis" wrote: >> In this thread, I'd like to collect things that ought to be done >> but where Dirkjan has indicated that he would prefer if somebody else >> did it. > > I think the most important item here is currently the win32text stuff. > Mark Hammond said he would work on this; Mark, when do you have time > for this? Then I could set apart some time for it as well. > > Have stalled a bit on the fine-grained branch processing, hope to move > that forward tomorrow. > Can we possibly get these todo items in the PEP? I keep looking at the PEP out of habit to see what the blockers are and they are not there, at which point I have to dig up Martin's email. -Brett > Cheers, > > Dirkjan > ___ > 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/brett%40python.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] Mercurial migration: help needed
On Tue, Aug 18, 2009 at 21:46, Brett Cannon wrote: > Can we possibly get these todo items in the PEP? I keep looking at the > PEP out of habit to see what the blockers are and they are not there, > at which point I have to dig up Martin's email. Will do. Cheers, Dirkjan ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
Howdy folks, I have a first draft of a PEP for including an IP address manipulation library in the python stdlib. It seems like there are a lot of really smart folks with some, ahem, strong ideas about what an IP address module should and shouldn't be so I wanted to solicit your input on this pep. the pep can be found here: http://www.python.org/dev/peps/pep-3144/ the code can be found here: http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ Please let me know if you have any comments (some already coming :) Cheers, /peter ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py : > def IP(address, host=False, version=None): > """Take an IP string/int and return an object of the correct type. > > Args: > ip_str: ... The arg is 'address', not 'ip_str'. There are two classes, IPv4 and IPv6 whose __new__ never create an instance of its class, instead they create instances of other classes. Why IPv4 and IPv6 are classes and not (factory) functions (like function IP)? Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] VC++ versions to match python versions?
>>> Ditto for 2.5, 3.1 and the trunk (which I guess becomes 3.2?) >> 2.5 needs VS 2003. > > The 64 bits version of 2.5 is built with VS 2005, though. Not really - it is built with the compiler in the platform SDK. 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
Re: [Python-Dev] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Tue, Aug 18, 2009 at 01:53:36PM -0700, Peter Moody wrote: > hold over from when I was trying to be too fancy. fixed as well. Thank you. The PEP and the code is Ok for me. Something like this should be in the stdlib. Currently I'm using IPy. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/p...@phd.pp.ru Programmers don't die, they just GOSUB without RETURN. ___ 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] Mercurial migration: help needed
On Tue, Aug 18, 2009 at 2:12 AM, "Martin v. Löwis" wrote: > The second item is line conversion hooks. Dj Gilcrease has posted a > solution which he considers a hack himself. Mark Hammond has also > volunteered, but it seems some volunteer needs to be "in charge", > keeping track of a proposed solution until everybody agrees that it > is a good solution. It may be that two solutions are necessary: a > short-term one, that operates as a hook and has limitations, and > a long-term one, that improves the hook system of Mercurial to > implement the proper functionality (which then might get shipped > with Mercurial in a cross-platform manner). My solution is a hack because the hooks in Mercurial need to be modified to support it properly, I would be happy to help work on this as it is a situation I run into all the time in my own projects. I can never seem to get all the developers to enable the hooks, and one of them always commits with improper line endings =P ___ 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] PEP 3144: IP Address Manipulation Library for the Python Standard Library
On Tue, Aug 18, 2009 at 1:34 PM, Oleg Broytmann wrote: >> http://ipaddr-py.googlecode.com/svn/branches/2.0.x/ipaddr.py : > >> def IP(address, host=False, version=None): >> """Take an IP string/int and return an object of the correct type. >> >> Args: >> ip_str: ... > > The arg is 'address', not 'ip_str'. d'oh, fixed. > There are two classes, IPv4 and IPv6 whose __new__ never create an > instance of its class, instead they create instances of other classes. Why > IPv4 and IPv6 are classes and not (factory) functions (like function IP)? hold over from when I was trying to be too fancy. fixed as well. Cheers, /peter > Oleg. > -- > Oleg Broytmann http://phd.pp.ru/ ...@phd.pp.ru > Programmers don't die, they just GOSUB without RETURN. > ___ > 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/python-dev%40hda3.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
