[Python-Dev] How to stay almost backwards compatible with all these new cool features

[Gregory Petrosyan]

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.