Re: [pygame] squeezing a little fun out of java ... meh

[Jan Pobrislo <ccx@xxxxxxxxxxxxxx>]

On Tue, 3 Jan 2012 09:52:33 -0800
Ian Mallett <geometrian@xxxxxxxxx> wrote:

> On Tue, Jan 3, 2012 at 7:19 AM, Sean Wolfe <ether.joe@xxxxxxxxx>
> wrote:
> 
> > From my
> > deeply uneducated standpoint it seems to me like this wouldn't be a
> > horribly hard thing to do, to add static typing or enforced types to
> > python.

In py3k this has been thought of:

PEP 3107 -- Function Annotations
http://www.python.org/dev/peps/pep-3107/

> From a programmer's perspective, I *don't* see it as easy to add
> support for static typing to Python.  It really must be all there or
> all *not*. And having it *not* is one of the beauties of Python.  It
> also made it slower.  However, it's a tradeoff the language
> designer(s) always have to make; it can't really happen at the
> coders' level.

That is indeed true for one simple reason: names are resolved at runtime.
While this allows monkeypatching, it also makes you unable to tell whether
self.somemethod is really the piece of code 10 lines above the call or
something entirely different until you hit the actual call.

> I suppose you could do things like:
> def my_func(in):
>     if type(in) != type(""): raise ValueError()
> . . . which emulate static types, but is still not a compile-time

I just use bunch of assert statements usually. Not as nice, but works.

> error. In my early Python libraries, I found I was doing something of
> this sort because I wanted it to be robust, even at the cost of
> performance (this is a case where C++ wins: C++ is plenty fast, you
> don't have to do this particular kind of error checking, and you can
> put #ifdef/#endif around error-checking sections so that the code
> isn't even *there* when you don't want it).

There is a plenty of interface libraries that aid with implementing the type
checking you want and can do more funky stuff like adaptation (equivalent to
automatic type casting in static-world). One of the prominent ones is
zope.interface which I would recommend checking out. Don't worry, it's
independent of rest of zope and it's used by quite a few other projects
(eg. twisted).

The thing is you still need tests with full code coverage because as I said,
everything happens in runtime in Python, but this can make it easier.
Good testing framework can help a lot too, I've fallen in love with py.test's
functional style and seen it reduce size of test cases drastically compared to
original unittest style.

> On the flip side, it's actually surprisingly easy to add duck typing
> (of a sort, through polymorphism) to compile-time languages.  In
> Java, simply make everything type "Object".  E.g.:
> Object my_var = new String("Help!  Spiders!");
> my_var = new Integer(6);

That's actually because JRE and CLR runtimes implement typing internally and
would technically allow duck-typing if it wasn't the above language semantics
restricting it. See the language Boo (http://boo.codehaus.org/) which exploits
this on the .NET platform. (The manifesto is definitely worth reading.)

When it comes to C/C++ it's bit trickier. The way C++ implements virtual
methods and classes in general inspired quite amount of hate for it and I hear
that even Objective-C that does the type resolution in runtime is often
faster than C++ that does that compile-time.

By the way, if you are C++ programmer and haven't yet read Frequently
Questioned Answers, I suggest you find time to at least skim through it.

> I mean we could make cholices as we code as to what to use.
> > When it was better to use a strongly typed methodolgy we could
> > refactor our code. We could use the feature as needed, and continue
> > with duck typing for normal python ness.

The thing I dislike on the Java-style classful/interface based type checking
everyone seems to implement is it promotes complicated interfaces and
overengineered OO infrastructure.

The advantage of duck typing is you can write function which's only
requirements on it's arguments is that they can be added together via +
operator and the result must be representable as string. You can then call it
with numbers, strings or lists and it works each time. You can't sensibly
represent such constraint via interface classes.

If you ever done anything in Haskell, you've seen that such constraints can
not only be easily written out, but to much extent inferred and checked
automatically. If encountering Java made you think about type checking, you
really should read about Haskell's type system before bringing such things
into Python. We already owe it for list comprehension and probably lot
of other useful things too.

> > Just a little rant to start of 2012 in the right way.
> >
> > Happy new year!! And remember. press on, it's only a flesh wound!

Happy Sun-Earth revolution to you too.