> -----Original Message-----
 
> Amen. As I keep saying, it's a matter of interface. If you 
> allow implicit keyword arguments, you're suddenly mixing 
> interface and implementation, and that is *wrong* (in the 
> sense that it is difficult to maintain, and it breaks the 
> promise of encapsulation). However, if you explicitly decide 
> that some argument is a keyword argument, you have 
> *consciously* made it part of the interface (I'd rather say 
> part of the very *name* of the method), so you can still 
> maintain the separation between interface and implementation 
> to the level you want as a developer.

The separation between implementation and behavior you make here is lost
the moment you commit to supporting a keyword argument for any given
method, regardless of the fact that it was an explicit, conscious
choice.  Once chosen, you're still beholden to that keyword name forever
unless you want to break backwards compatability.  I think the perceived
freedom is an illusion.

There seems to be this fear of using an argument name, and then later
changing your mind about what the argument name should be called.  To
that I reply that, even with the explicit syntax, this issue does not go
away.  I would also say that all the implicit syntax does is force you
to think more up front about your API and naming conventions.  With
Sydney, at least you can resort to positional parameters in the unlikely
event that the argument name did change, something you can't do with
Matz's current proposal afaik.

Regards,

Dan