I want to learn a new language...

Hans Fugal hans at fugal.net
Wed Feb 14 16:46:45 MST 2007


On Wed, 14 Feb 2007 at 16:29 -0700, Michael L Torrie wrote:
> On Wed, 2007-02-14 at 15:48 -0700, Andrew McNabb wrote:
> > Sure, Python isn't perfect.  But it's so simple that I always feel like
> > I know where the imperfections are, and I write code without worrying
> > about them.
> 
> Thought I'd interject with a few of my favorite things to hate about
> python.
> 
> Most of my issues with python surround the "duck" typing system.  This
> works very well for lots of things.  Basically the type of an object
> doesn't matter so long as it supports the protocol you want.  Thus you
> can use the "for x in " operation on any object that is iter-able.  The
> problem is that there's no easy way to discern ahead of time what is
> expected when you pass an object to a function.  You can use
> introspection to get the built-in docs, ask the function how many
> parameters it's expecting, true.  But if the docs don't say, you have no
> idea what methods the function is expecting to call on the object until
> you try it and get an exception.  This often makes working with
> third-party libraries very painful.  I had to run several python twisted
> networking apps in a debugger until I figured out just what the
> different methods and functions in twisted are expecting, the good docs
> notwithstanding.  The source code is essential in finding out some of
> these things.  So while I find dynamic typing extremely powerful, it
> does have warts.

I disagree that duck typing (which is a feature of ruby also) is a
problem. I find it much more useful than not. I do agree however that it
is important to document what is accepted and expected for your methods. 

> The other major architectural limitation in python is the GIL, a giant
> lock that synchronizes calls to the interpreters core.  Thus
> multithreaded programs can not utilize multiple processing units.  In
> practice this usually isn't a huge deal.  I'd say much of the time a
> multithreaded app is best done with an asynchronous library anyway, like
> twisted.  But threads have their place.  Just be aware of this
> limitation when doing heavy computations with python.

Incidentally, Ruby has similar (perhaps worse) limitations in threading.
These are on the table for repair with the virtual machine work being
done. The story is long, but basically you can do threads but they're
not real threads, and I say that in the pragmatic sense not the academic
sense.

-- 
Hans Fugal ; http://hans.fugal.net
 
There's nothing remarkable about it. All one has to do is hit the 
right keys at the right time and the instrument plays itself.
    -- Johann Sebastian Bach
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://plug.org/pipermail/plug/attachments/20070214/876e0e54/attachment.bin 


More information about the PLUG mailing list