New for Python 2.5

"What's New in Python 2.5"

Of interest are:

If the Python crew is adding partial application to the language, I'm curious why they wouldn't have gone the whole hog and added in partial evaulation.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

P.E. is pretty tricky to do properly* ...

... but I think its time as a mainstream technology will be soon (I am admittedly biased). You even have it a bit in some of the advanced C++ template work.

* By properly I mean that it makes the resulting code faster in at least the majority of cases.

Psyco

The "What's new" document is incomplete. Python will ( finally ) get a conditional expression.

For the matter of PE: doesn't Psyco count? Psyco for CPython is quite a few years around and will become PyPys mandatory JIT in the pure Python version. Here is a conference paper describing Psyco. According to the taxonomy of the PE site it holds as an "offline specializer". An "online specializer" that goes far beyond the partial application class and is dedicated for symbolic computations is not yet in sight.

Kay

Psycho is for types

The conditional syntax looks ugly to me. Interesting that he's adding another way to do things despite his philosophy of only-one-good-way-to-do-it.

From what I've read, Psycho will optimize based on generating several versions of a function specialised by type. What I was thinking was partial evaluation based on values.

I'm not sure what you are for

I'm not sure what you are for? Psyco operates on Python bytecodes and translates/compiles code-blocks at runtime. For better reusibility it "widens" the concrete values using runtime type information. This is an effective strategy for not letting increase the number of code-block versions arbitrarily.



Psyco does not perform eager evaluations with "holes" like e.g. Maple does. This is likely the most intuitive application of PE. If one defines a Maple function

h := proc(x,y)
    sin(x/3)*cos(x*y)
end proc;

one can specialize it on a certain value and receive an other function as value.

> g:= h(x,2);
                              /1  \         
                     g := sin| - x | cos(2 x)
                              \3  /         
> eval(g,x=9);
                         sin(3) cos(18)

Here g can be considered as a specialized version of h. That's of course far more advanced than partial() that just stores the arguments and the function for later use.

Yes, what Maple does, please.

From how you've described it, I am talking about what Maple does.

advanced?

All that does is substitute the value 2 for y and the global name x for the local name x. Then it returns the last evaluated expression in the function, not another specialized function as you suggest. This is evident in the fact that in your example you can't do g(9) but must do eval(g, x=9). The fact that Maple has a built-in auto-simplifier sometimes makes it look like some PE is going on. But generally I think of PE as being far more advanced that what you can do in Maple.

with:

I believe PEP 343 is also going to be in Python 2.5. That adds a with: block that ensures finalization. E.g.:

with f = opening(filename):
    do stuff with f...

Which closes the file after the block.

partial() is just a function

Partial function application is being added to the library, not the language. Inasmuch as library design is language design, it's a slightly bad change. One more thing for functional programmers to grab for instinctively instead of thinking for a moment and writing good procedural code. (Hah!)

On the other hand any() and all() are excellent.

partial()

At least they got the terminology right. In Maple and Groovy this function is called curry(). And I have to say that I do find it very useful in day-to-day Maple programming.

Handy syntax for use with operators

My version of partial application is a little easier on the eyes when using operators, I think:

>>> from partial import _
>>> addWorld = _ + " world!"
>>> addWorld("Hello,")

"Hello, world"

>>> mapcall(_.upper, ["list", "of", "strings"])

["LIST", "OF", "STRINGS"]

>>> 

Should have submitted a PEP, I guess!

The underscore has special me

The underscore has special meaning (albeit not used often) as 'result of previous evaluation', e.g.

>>> 2+2
4
>>> _
4
>>> 

That's what I would've done,

That's what I would've done, too, though. It seems like a very intuitive leap from the existing syntax.

My experience with Dylan/Scheme, which also have a "curry" function (yeah, they get the name wrong), is that brevity is very important for partial application. Haskell and Ocaml get a big win from just leaving off the last argument, though at the expense of a lack of flexibility (those damn 'flip's get very annoying in Haskell). An underscore gets all their brevity points while still being intuitive and allowing one to partially apply arguments other than the leftmost.

'My experience with Dylan/Sch

'My experience with Dylan/Scheme, which also have a "curry" function (yeah, they get the name wrong)'

I'm not sure which Scheme has a "curry" function, but I like the SRFI for specialized parameters:

SRFI 26

re: partial function application

I wonder, is this partial syntax meant to wean people away from using lambdas?

// (dons tinfoil hat)
/// (thinks def should be an expression)

probably

I think you are probably right. Guido has said before that he wants to eliminate lambdas in a future version.

That's a real shame, unless i

That's a real shame, unless it's replaced by a lightweight syntax for anonymous functions that matches the built-in control flow statements. The lambda ... syntax is pretty ugly in comparison to if, while, def etc.

I agree. If his complaint is

I agree. If his complaint is with the word "lambda" then just give it a better syntax. The concept of lambda expressions is still a good concept. But regardless, it isn't that big of a loss, after all, it will still be possible to define closures, and that's really what makes lambdas so great in the first place, right?

Partial function application

Wow, Python is really improving by leaps and bounds these days! I can't remember being this excited since the day I learned to go potty all by myself. Kudos to Guido! What's next on the innovation agenda? Let-expressions? I can't wait...

It's easy to be sarcastic whe

It's easy to be sarcastic when you don't have a community of programmers relying on your work and nobody cares about the design decisions you make.

It's even easier

When people get excited over the mundane. Or rather, the mundane, done wrong.

Innovation

It is useful to distinguish between the dynamics of language innovation and of language evolution.

Language evolution poses a different set of problems (back compatibility, community support for changes, cohesion etc.) That's not to say, of course, that all changes are of equal quality. Language evolution should be analyzed with the same care given to truly innovative features.

Both these aspects are discussed here often. It might be helpful to be explicit about what is interesting in the developments we cover. If someone claims that X is an innovative language feature, it is quite natural to object, if in fact it isn't new. If the interest stems from the way new features are added to an existing language, that's not a valid objection.