On 2/21/06, Marko Mikulicic <[EMAIL PROTECTED]> wrote:

so, I repeat, the problem is not internally in the framework where
you know what you are doing but the external api stability.
Source compatiblity from release to release is important because it
impacts the freedom of refactoring.

Honestly, this is a silly objection.  Think about it: you're complaining that changing something from a module-level function into a classmethod impacts the API.  Why is this silly?  Simply that you can break API compatibility in plenty of ways even if you restrict yourself to classmethods to begin with!  Say, by moving a method from class A to class B.  And you have similar workarounds if that matters to you: you can leave a stub in class A; you can leave a stub module-level function.

Forcing the developers to
postpone important refactoring just to preserve source compatibility
between minor releases make development less fun and when developing
free software fun is important :-)

As I said, the burden of backwards compatibility in Python is not suddenly greater just because you now have more constructs to work with than just classes.
 
Python object oriented features were slowly added during many years
and it's easy to see completely different styles between standard
python modules and language features (for example compare the perfix
"len" function to the infix "has_key" method for dictionaries) and
this thing about modules "freedom" is reminiscent of procedural
programming style.

It's true that Python has evolved, and the style of early libraries now looks outdated.  Everyone acknowledges this.  But so has any non-dead language evolved.  Compare libraries from JDK 1.1 with modern ones, for instance.  Does this mean that the 1.1 designers were idiots, or that Java was poorly designed?  No.

--
Jonathan Ellis
http://spyced.blogspot.com

Reply via email to