Mailman 3 February 2006 - Python-Dev

Re: [Python-Dev] any support for a methodcaller HOF?
by Chris or Leslie Smith 05 Feb '06

05 Feb '06

| making the implied return statment visible might also be a good idea, | e.g. | | lambda x, y: return x + y | | or even | | def (x, y): return x + y | Although I don't understand the implications of making such a change, the 2nd alternative above looks very nice. Whenever I write a lambda I feel like I am doing something non-pythonic. I think the 2nd proposal increases the readability of the lambda, something that is often touted as being part of what makes python beautiful. /c

1 0

any support for a methodcaller HOF?
by Alex Martelli 05 Feb '06

05 Feb '06

I was recently reviewing a lot of the Python 2.4 code I have written, and I've noticed one thing: thanks to the attrgetter and itemgetter functions in module operator, I've been using (or been tempted to use) far fewer lambdas, particularly but not exclusively in key= arguments to sort and sorted. Most of those "lambda temptations" will be removed by PEP 309 (functional.partial), and most remaining ones are of the form: lambda x: x.amethod(zip, zop) So I was thinking -- wouldn't it be nice to have (possibly in module functional, like partial; possibly in module operator, like itemgetter and attrgetter -- I'm partial to functional;-) a methodcaller entry akin to (...possibly with a better name...): def methodcaller(methodname, *a, **k): def caller(self): getattr(self, methodname)(*a, **k) caller.__name__ = methodname return caller ...? This would allow removal of even more lambdas. I'll be glad to write a PEP, but I first want to check whether the Python-Dev crowd would just blast it out of the waters, in which case I may save writing it... Alex

14 31

[PATCH] Fix dictionary subclass semantics when used as global dictionaries
by Crutcher Dunnavant 05 Feb '06

05 Feb '06

There is an inconsistancy in the way that dictionary subclasses behave when they are used as as namespaces in execs. Basically, while python 2.4 permits the usage of dictionary subclasses for local environments, it still bypasses the subclass functions and uses the C API for global environments. The attached patch (and unittest!) addresses this issue. I'm pretty sure we keep the fast path in this. -- Crutcher Dunnavant <crutcher(a)gmail.com> monket.samedi-studios.com

5 11

math.areclose ...?
by Alex Martelli 05 Feb '06

05 Feb '06

When teaching some programming to total newbies, a common frustration is how to explain why a==b is False when a and b are floats computed by different routes which ``should'' give the same results (if arithmetic had infinite precision). Decimals can help, but another approach I've found useful is embodied in Numeric.allclose(a,b) -- which returns True if all items of the arrays are ``close'' (equal to within certain absolute and relative tolerances): >>> (1.0/3.0)==(0.1/0.3) False >>> Numeric.allclose(1.0/3.0, 0.1/0.3) 1 But pulling in the whole of Numeric just to have that one handy function is often overkill. So I was wondering if module math (and perhaps by symmetry module cmath, too) shouldn't grow a function 'areclose' (calling it just 'close' seems likely to engender confusion, since 'close' is more often used as a verb than as an adjective; maybe some other name would work better, e.g. 'almost_equal') taking two float arguments and optional tolerances and using roughly the same specs as Numeric, e.g.: def areclose(x,y,rtol=1.e-5,atol=1.e-8): return abs(x-y)<atol+rtol*abs(y) What do y'all think...? Alex

7 8

Path PEP and the division operator
by Nick Coghlan 05 Feb '06

05 Feb '06

I was tinkering with something today, and wondered whether it would cause fewer objections if the PEP used the floor division operator (//) to combine path fragments, instead of the true division operator? The parallel to directory separators is still there, but the syntax isn't tied quite so strongly to the Unix path separator. Cheers, Nick. -- Nick Coghlan | ncoghlan(a)gmail.com | Brisbane, Australia --------------------------------------------------------------- http://www.boredomandlaziness.org

5 6

Path PEP -- a couple of typos.
by Scott David Daniels 04 Feb '06

04 Feb '06

Here are a couple of simple-minded fixes for the PEP. Near the bottom of "Replacing older functions with the Path class": > fname = Path("Python2.4.tar.gz") > base, ext = fname.namebase, fname.extx Surely this should be: base, ext = fname.namebase, fname.ext > lib_dir = "/lib" > libs = glob.glob(os.path.join(lib_dir, "*s.o")) > ==> > lib_dir = Path("/lib") > libs = lib_dir.files("*.so") Probably that should be: ... libs = glob.glob(os.path.join(lib_dir, "*.so")) ... --Scott David Daniels Scott.Daniels(a)Acm.Org

1 0

Re: [Python-Dev] any support for a methodcaller HOF?
by Robert Brewer 03 Feb '06

03 Feb '06

Giovanni Bajo wrote: > Alex Martelli <aleaxit(a)gmail.com> wrote: > > I understand your worry re the syntax issue. So what about Michael > > Hudson's "placeholder class" idea, where X[1] returns the callable > > that will do x[1] when called, etc? Looks elegant to me... > > Depends on how the final API looks like. "deffered(x)[1]" > isn't that bad, but "def x: x[1]" still looks clearer as > the 'def' keyword immediatly makes clear you're DEFining > a DEFerred function <g> :) Of course we can paint our > bikeshed of whatever color we like, but I'm happy enough if > we agree with the general idea of keeping the same syntax > in both deferred and immediate execution. I don't agree with that "general idea" at all. Sorry. ;) I think the semantic emphasis should not be on "execution", but rather on "expression". The word "execution" to me implies "statements", and although some functions somewhere are called behind the scenes to evaluate any expression, the lambda (and its potential successors) differ from "def" by not allowing statements. They may be used to "defer execution" but to me, their value lies in being static expressions--object instances which are portable and introspectable. This is where LINQ [1] is taking off: expressions are declared with "var" (in C#). I used Expression() in Dejavu [2] for the same reasons (before LINQ came along ;), and am using it to build SQL from Python lambdas. I had to use lambda because that's Python's only builtin support for expressions-as-objects at the moment, but I'd like to see Python grow a syntax like: e = expr(x: x + 1) ...where expr() does early binding like dejavu.logic does. [Looking back over my logic module, I'm noticing it requires boolean return values, but it would not be difficult to extend to return abitrary values--even easier if it were rewritten as builtin functionality. Guess I need to write myself another ticket. ;)] Robert Brewer System Architect Amor Ministries fumanchu(a)amor.org [1] http://msdn.microsoft.com/netframework/future/linq/ [2] http://projects.amor.org/dejavu/browser/trunk/logic.py

3 2

Re: [Python-Dev] Octal literals
by Delaney, Timothy (Tim) 03 Feb '06

03 Feb '06

Andrew Koenig wrote: >> I definately agree with the 0c664 octal literal. Seems rather more >> intuitive. > > I still prefer 8r664. The more I look at this, the worse it gets. Something beginning with zero (like 0xFF, 0c664) immediately stands out as "unusual". Something beginning with any other digit doesn't. This just looks like noise to me. I found the suffix version even worse, but they're blown out of the water anyway by the fact that FFr16 is a valid identifier. Tim Delaney

5 5

Re: [Python-Dev] Octal literals
by M J Fleming 03 Feb '06

03 Feb '06

On Wed, Feb 01, 2006 at 01:35:14PM -0500, Barry Warsaw wrote: > The proposal for something like 0xff, 0o664, and 0b1001001 seems like > the right direction, although 'o' for octal literal looks kind of funky. > Maybe 'c' for oCtal? (remember it's 'x' for heXadecimal). > > -Barry > +1 I definately agree with the 0c664 octal literal. Seems rather more intuitive. Matt

4 3

Re: [Python-Dev] Octal literals
by Delaney, Timothy (Tim) 02 Feb '06

02 Feb '06

M J Fleming wrote: > +1 > > I definately agree with the 0c664 octal literal. Seems rather more > intuitive. And importantly, sounds like "Oc" 664 ;) Tim Delaney

1 0