(sung to the opening refrain of ‘Money for Nothing‘)
If you have not read Guido’s Python 3000 status update, do so now (I will wait.) Done? Do you have that ‘night before your birthday’ feeling? There wasn’t anything mentioned that I was not aware of, being an avid mailing list lurker, but seeing it all put together puts things into perspective. and the whole is much greater than the parts. It sparked a number of discussions at work. Even the usually reserved and conservative core researchers are excited (translation: even those who hate external change because it disrupts their work). Some of the code I am currently working on will have to be removed when we go to Py3K. Not rewritten, just removed. I did a quick back-of-the-guardian-crossword calculation and almost 70% of our framework utility code will no longer need to be maintained. The remaining code will need to be replaced with __format__, __instancecheck__, and annotations. I am still not sold on ABC’s. I personally prefer a mix-in approach to interfaces, but they will make some of the strong type stuff much much easier (medium typed really).
It’s times like this where I wish I had more time. I promise to do a proper strong typed interface Py3K post next month, I just don’t have the time right now and ‘pygmentor’ (a secure XSS pygments code syntax highlighting service) is not even in alpha yet.
class MyClass(metaclass=StrongTypedType):
attr1 = attribute(int)
attr2 = attribute(Sequence)
attr3 = attribute(tuple)
attr4 = attribute(SequenceOf(Integer, Float))
attr5 = attribute(float, Integer, String,
doc="some doc string", default=4.0)
def method(self, arg1: (Integer, Float) = 3,
arg2: SequenceOf(String, empty=false) = ('hello',)):
pass
@StrongTyped
def func(arg1, arg2: (Integer, NoneType) = None):
pass
>>> foo = MyClass()
>>> foo.attr5
4.0
>>> foo.bar = 5
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'MyClass' object has no attribute 'bar'
>>> foo.attr1 = "hello"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'MyClass' object attribute 'attr1' must implement 'int', not <t
ype 'str'>.
>>> foo.attr4 = [1, 3.2, "hello", 5]
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'MyClass' object attribute 'attr4' must implement 'Sequence' fo
r which all elements implement one of: ['Integer', 'Float']. The element at inde
x 2 ('hello') fails this test.
I think you get the idea. I toyed with having ‘Integer or Float’ annotations is with a monkey patch on the ABC’s for the __or__ operator. This makes the annotation processing much easier, but causes problems when you want to use non ABC’s in the typing like ‘int’. Currently NoneType must be used instead of None because I hate that special case exception. A __instancecheck__ monkey patch to None to make None an instance of its self could resolve this issue, but I am scared of potential side effects on the greater system.
I know many people are asking ‘Why? Why make a beautiful language like python look like C++?” Well those who are not gouging out their eyes or grabbing pitchforks and torches. The anwser is not simple and is long, and I am tired. The short answer is ‘because it makes embedding python in other programs and communicating across the boundary much easier and automateable(sp?).’

Re: ABCs: there’s no reason why you can’t write ABCs that are mixins.
@Guido,
Sorry, I should have been more specific. I am still not 100% sold on the inherent inheritance model ABC’s have verses some other models I saw discussed on the dev list which better fit my mental representation of mix-ins.
In other words, I need to use ABC’s to solve some actual problems before I make up my mind. Nothing I have seen so far is a perfect fit, but then nothing ever is.
BTW: arn’t you supposed to be drunk by now???