Here's some of my ideas about subject. Maybe some of them are rather foolish, others -- rather simple and common... I just want to add my 2 cents to Python development. 1) What is the reason for making Python backwards incompatible (let it be just 'BIC', and let 'BC' stands for 'backwards compatible')? The reason is revolution. But how much can we get just from intensive evolution? 2) Is there any way both for staying (almost) BC and intense evolving? Yes. General rule is rather simple: make old way of doing something *deprecated* (but *not* remove it entirely) and *add* the new way of doing this. But how to _force_ users to use new way instead of old? My proposal: Python should raise DeprecationError after old way is used: old_way() should be equivalent to old_way() raise DeprecationError('description') So people who want to use old way should write something like try: old_way() except DeprecationError: pass I think they soon will migrate to new style :-) [Manual/semi-automatic migration] Another benefit is that apps that were written for old-way Python version could be run under new-way Python after this simple modification (there might be standard script for making old apps compatible with new versions of Python!). [Automatic migration] 3) Staying BC means no revolutions in syntax. But there are problems with some of new-style features: a) 'raise' statement. I dislike idea about inheriting all exceptions from the base class and about removing 'raise' in favor of '.raise()'. Reasons: we can think about 'raise' as about more powerful variant of 'return'. Classic example is recursive search in binary tree: raising the result there seems to be very elegant and agile. Exception != Error is true IMHO. b) Interfaces. I like them. But isn't it ugly to write: interface SuperInterface: ... Note: 'interface' is repeated there two times! And this is *not* BC solution at all. Remember exception classes: class MyCommonError(Exception): ... but not exception MyCommonError(...): ... and it seems to be OK! And I have great agility with it: as mentioned, I can raise just 'some_object', but not only 'exception'. So, my proposal is syntax class SuperInterface(Interface): ... or maybe class SuperInterface: ... but not interface SuperInterface: ... Note: first two variants are BC solutions! And *yes*, you should be able to implement *any* class. Example: class Fish(object): def swim(): do_swim() # else ... class Dog(object): def bark(): do_bark() # else ... class SharkLikeDog(Fish) implements Dog Isn't it very good-looking? Note: IMHO Type == Implemented interface. So that's why every type/class can be used as interface. (Sorry for type/class mess). Could we find some benefits of it? c) I like Optional TypeChecking. But I think it could be improved with implementing some sort of Optional InterfaceChecking. Maybe like this: def f(a implements B, c: D = 'HELLO') implements E: # ?function implements interface? well, maybe it can be some type check interface? # some code here or def f(a implements B, c: D = 'HELLO') -> implements E: # some code here Summary -------------- Well, I think the main idea is (2): - Don't remove; make it strongly deprecated Then: - Some changes to interfaces implementation - etc ('raise' statement, InterfaceCheck -- see (3) ) Sorry for my English and for mess. -- Regards, Gregory.