[Python-Dev] bugs.python.org down?
Apparently the tracker has been unresponding for some time now, although port 80 still accepts connections. Regards Antoine. ___ 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 7 updated
Nor did it break any of our ActivePython 2.7 (Python trunk) builds ... though I had to hand-edit the patches to use 4 spaces now. Will this untabification change be made to the `release2.6-maint` branch too? -srid On 2010-05-09, at 11:33 AM, Antoine Pitrou wrote: > > Hello, > > The untabification of C files didn't produce any noticeable problem on > the buildbots. I've updated PEP 7 with the mention that all C files > should be 4-space indented, and removed the obsolete wording about > some files being indented with tabs. > > Regards > > Antoine. > > > ___ > 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/sridharr%40activestate.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
Re: [Python-Dev] PEP 7 updated
Le mardi 11 mai 2010 à 16:44 -0700, Sridhar Ratnakumar a écrit : > Nor did it break any of our ActivePython 2.7 (Python trunk) builds ... > though I had to hand-edit the patches to use 4 spaces now. Will this > untabification change be made to the `release2.6-maint` branch too? It has already been made to the 2.6 branch. By the way, you don't have to untabify patches by hand, you can just use "untabify.py -p". Regards Antoine. ___ 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] Possible patch for functools partial - Interested?
On 07May2010 14:53, VanL wrote: | On 5/7/2010 12:41 PM, Steven D'Aprano wrote: | >> Now, if I write | >> | >> def f1(x,y): return x+y | >> def f2(x,y): return x+y | >> | >> I don't expect f1==f2 to be True, even though f1 and f2 behave in | >> exactly the same way, and indeed it is not. | | This is not what I am getting after; these (IMO) should compare unequal. | I took a fairly conservative line, testing for identity of functions and | equality of arguments when converted to a normal form: | | def __eq__(self, other): | try: | return ((self.func == other.func) and | (self.args == other.args) and | (self.keywords == other.keywords)) [...] I think that if you're going to say "identity" above you should have: self.func is other.func in your code. If you want "==" in your code (and I think you do, since you're implementing __eq__) you should say "equality" instead of "identity". I know for functions "==" and "is" currently are equivalent, but we should be really finicky here about intent, especially since a few messages in the thread is contemplate testing function for equivalence to one degree or other. At which point "==" and "is" aren't the same any more. Cheers, -- Cameron Simpson DoD#743 http://www.cskk.ezoshosting.com/cs/ Careful and correct use of language is a powerful aid to straight thinking, for putting into words precisely what we mean necessitates getting our own minds quite clear on what we mean. - W.I.B. Beveridge ___ 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
