Some thoughts on Python

I’ve never studied Python, but I’d quite like to at some point in the future.
It seems very much like Perl with a different set of design criteria. Yeah,
there are differences, but compare with C, Lisp, COBOL, and you can see why
Perl and Python are clustered together in the “P languages” (Perl/Python/P^HRuby etc.)

Actually, that’s one of the main reasons I’ve not expended signifant effort
into learning Python – I can hurt my brain far more by trying to learn C or
Haskell. But I’m sure it would be a good thing to do at some point. Here
are a few notes on first impressions: these are just that, impressions,
and may not be factually accurate: if you want to know full and correct
details about Python, there are many excellent blogs that will clarify.

2008-09-25 Thanks for the excellent comments, I’ll fold
in corrections below!

Whitespace

This is the one wart that Perl programmers fairly consistently bring up.
I’m coming around to the idea that it’s a good idea, but I do think that:

  1. it’s not entirely necessary, as most good code is indented anyway
  2. Haskell does it better, with some excellent whitespace inferencing rules, but
    the possibility to drop back to an explitly { braces; and; semicolons }
    style if you need it

Things that you miss out on include multiline strings (2008-09-25: Bill Mill points that “”"syntax”"” does indeed allow multiline strings, thanks), and multiline well, anything,
for example lambdas, but that’s OK because…

Functional Programming

Python has likened to an easy version of Lisp, and it has the same kind of
functional goodies as Perl. At some point Guido wanted to remove (I think)
reduce, grep, map from the core language, and there was much gnashing of
teeth. I think he backed down, but the idea that he suggested it is interesting.
He also wanted to get rid of lambdas, which seems utterly crazy, as even the
Java people are now thinking about adding them. But lambdas are still
deprecated, and are considered not the “pythonic” way of doing things.
Hence they are discouraged and restricted to single lines. Hmmmm.

(2008-09-25: Bill Mill points out that map remains; reduce got moved to Standard Lib, as comprehensions already do the right thing; and grep doesn’t exist. Is that called “filter” in Python? Of course comprehensions can already to map/grep too)

On the other hand, python has list comprehensions which work equally well
on lazy generators! Very nice indeed. It also has a much fuller destructuring
bind than Perl’s (which only works on single-level lists). So some good, some
bad, and some interesting syntax and features. I doubt there’s a clear
“winner”, some more discussion on Perl/Python (via Lisp of course) in Paul
Graham’s Revenge of the Nerds
post.

Oh, and Python has continuations! With a builtin yield command. Perl has
the Coro module, which is a fantastic piece of work, but rather
complicated with confusing documentation. The yield command itself is in
Coro::Generator but it has a number of limitations, like not
being able to clone a continuation. There was a lovely post on creating
monadic “do-notation” using continuations only, and I ported it to Perl
with much swearing only to find that though it worked great for simple
monads, it failed utterly for the List monad (important as it’s
what list comprehensions are built on) precisely because of this.
Apparently the Perl internals don’t really mesh with this, so it’s
unlikely that we’ll be getting it for Perl 5 any time soon. Point to
Python.

(2008-09-25: dolio points out I’m confusing generators and coroutines.
Yup, I do that, sorry! I think one can be implemented in terms of each other (and
vice-versa?), and that some literature does also blur the distinction, but could be wrong about that too? And yes, Ruby has callcc, but apparently the Monad example I was reading can’t be easily ported to Ruby because the continuations/coroutines/thingies generated by yield aren’t clonable)

OO

Python’s OO looks serviceable enough, and method prototypes and so on are nice.
Perl is really catching up here though with projects like Moose, which
truly does deliver on being a “postmodern object system”. Sure, the syntax
could do with some work in places, but the new buzz around
Devel::Declare and Method::Signatures means that this
is coming on well too.

Will on Geekup posted some nice examples of “declarators on attributes”,
which I think are similar to lvalue tied methods, but look rather better
designed. (From Damian Conway’s talk Contextual::Return may
fix the problems Perl has with this kind of nice syntax. I say may
as with Damian’s talks it’s hard to tell whether they truly are a massive
advance in usability and functionality or crack-fueled insanity).
Actually, declarators deserve their own section:

@Declarators

These are really nice syntax for modifying subroutine declarations.
Of course, there’s nothing you can’t do in Perl, but it’s prettier
than direct symbol table hacking. And less hackish than bloody :attributes.
Still, nothing a bit of Devel::Declare or similar sugar couldn’t
fix :-)

But talking about declarators, I have to ask:

Is Python really more readable?

One of the Python slogans is something like “executable pseudocode”,
as if you can just write out readable summaries of code which are readable
but compile. From the python examples I was looking at (admittedly, these
may have been complex, with features like @declarators) I couldn’t make
head or tail of it. Now I’m not trying to suggest that Python is naturally
unreadable, or that Perl is naturally readable. But I would say that

  1. If you know language X but not language Y, then you may find X more readable than Y.
  2. This may hold even if X happens to be Perl, or Y happens to Python :-)

This may be a good time to pimp my
Readable Perl
slides up, for those people that insist on joking that the phrase is oxymoronic.

Community

Both Perl and Python communities seem to be vibrant, productive (of modules, apps,
blogs, and conferences), and to have a mix of helpful and friendly, and snobbish and
trollish. So pretty much situation normal for perhaps underrated “scripting” languages :-)

Some differences I’ve heard mentioned include (with no figures or such to back them up…):

  • Python conferences are apparently full of people talking about cool projects they’ve done.
    At Perl conferences, people often talk about syntax and technical problems and… oh, yeah, I used this to do this project but I don’t have time to talk about it now…

  • I’ve very rarely heard Perl programmers talk badly about Python. Well OK, we always whine about the whitespace, but I know that jerakeen and
    Dean
    have said generally positive things about it.
    I’ve had Python people telling me bad things about Perl, despite not knowing anything about modern Perl, which I think is fairly silly, unless they are doing it only for postmodern ironic reasons
    (which is an excuse apparently).

  • Of course this may be because Perl programmers pick on PHP and Java instead. But that’s OK because we’re being postmodern and ironic.
  • I have an (utterly uninformed) hunch that Python conferences are better attended, but that this
    may be in part due to there being fewer of them.

  • Python has Guido. Perl has @Larry (in the plural). (I’m not sure that this isn’t overrated,
    $Larry probably gets the deciding vote).

There is a constant meme that href="http://greenokapi.net/blog/2008/09/24/italian-perl-workshop-2008/#comments">Python
is somehow more “modern” than Perl.

This is almost never qualified, I remember in this interesting book on programming language design that it was mentioned that the fact that
Python’s regular expressions lived in an external module was a more modern design that Perl’s,
which had them as builtins. Perhaps Perl not building in support for declarators and list
comprehensions is more modern too? I’m sure if I say this often enough, it’ll be a good
substitute for actually making sense :-)

But Python does seem to get more buzz, with things like Google’s AppEngine supporting
Python before Perl. Hey ho. I still think that there are many more Perl jobs going,
for what that’s worth.

Modules

CPAN is a big advantage for the Perl community, and I believe that Python’s module ecosystem
is somewhat less complete. But it looks very impressive nonetheless:

Off the top of my head, there’s Twisted, Python’s equivalent to POE; Django (Catalyst);
and PyGame (possibly comparable to SDL_Perl?) as fairly high-profile complex libraries
that show, to be honest, that both languages are pretty healthy with regards to module
support.

(2008-09-25: Bill Mill points out PyPI
link, and admits it’s “still no CPAN, but it’s coming along”, which is more or less what I
was trying to suggest ;-)

So…

Python looks like a great language, with many of the same strengths of Perl. If you’ve
looked at Perl and it didn’t really click, try Python. And vice-versa. If you’ve not used
a dynamic language and want to try, then use one. Honestly, you’ll love it. (And if you
don’t, try the other one. Or Ruby. Or go crazy and learn Haskell.)

Comments

  1. dolio says:

    Are you sure Python has continuations? I was under the impression that it had generators (which your stuff about the ‘yield’ keyword seems to indicate you’re talking about), but those are not full first-class continuations (and Coro sounds like coroutines, which are also not continuations).

    It’s possible that things have changed without my hearing about it, though (I don’t watch Python very closely).

    Ruby, for instance, has continuations (see Kernel#callcc or something of that sort).

  2. Bill Mill says:

    > Things that you miss out on include multiline strings

    errmmm… no you don’t.

    def foobar():
    return “”"this is a long string that is triple-quoted
    therefore it is a
    multiline
    string”"”

  3. Bill Mill says:

    > Guido wanted to remove (I think) reduce, grep, map from the core language, and there was much gnashing of teeth.

    Nope, reduce got moved to the standard library instead of the builtin functions because list comprehensions are now the built-in way to perform reduces. map() is still in the builtins and there’s never been a grep() function, I’m not sure what you’re talking about there.

    > CPAN is a big advantage for the Perl community

    PyPI is still no CPAN, but it’s coming along.

  4. Pawel Murias says:

    lambda’s in python don’t really mix with the indentation oriented syntax, the none-deprecated equivalent is
    def some_name():
    pass
    foo(some_name)

    if you can make up enough meaningfull names, it’s better ;)

  5. GTof says:

    About Python, Ruby and the monads, i think it’s the opposite. Monads on Ruby are very simple thanks to http://github.com/aanand/ruby-do-notation/tree/master and the blocks of Ruby. The impementation in http://www.valuedlessons.com/2008/01/monads-in-python-with-nice-syntax.html have two problem :

    1 – he copies the generator by replaying it from the beginng, it’s not very efficient.
    2 – lambdas in python are restraint to only expression

    Furthermore when trying to implement monad in Python i noticed some more issues. Imagine you want a function :

    def foo(a):
    return do x >= (lamnda x : N(a))

    ‘a’ occrus in a lambda in an expression, that’s bad !

    I tried to use the same technique as in Ruby but cecause of the complexity of the Python bytecode i gaved up.

    If you want you can use the code i’ve done to simulate do-notation. It works but code need to be in strings which are parsed, transformed and interpreded. it’s not as beatiful as in Ruby.

     # THE DO NOTATION
    
     import re
     import compiler
    
     #  PARSE ASSIGNMENT "x < - m"
     doasgn = re.compile(r"^\s*(\w+)\s*> (" + dolist(l[1:]) + ")")
    
     # TRANSORM A DO BLOCK INTO A BIND EXPRESSION
     do    = lambda s : dolist(dostmt.findall(s))
     # COMPILE A DO BLOCK INTO A CODE EXPRESSION
     cdo   = lambda s : compiler.compile(do(s),'compiledo.py','eval')
    
     # PYTHON HAS PROBLEMS TO SEE LOCAL VARIABLES  WHEN EVALUATING :
     # def test(x) :
     #   return eval(do("""
     #       List.mreturn(x)
     #       """)
     #
     # print test(5).run()
     #
     # Will give the good result but :
     #
     # def test(x) :
     #   return eval(do("""
     #       y <- .....
     #       List.mreturn(x)
     #       """)
     #
     # print test(5).run()
     #
     # Will give the error : NameError: global name 'x' is not defined
     # To avoid that, we build a closure from the list of local variables
     # with (lambda x : ...)(locals()["x"])
     # So x is in the context of the expression with the good value in locals 
    
     def closure(v,m):
       l = v
       for x in m.keys() :
        l = "((lambda " + x + " : " + l + ")(m[\"" + x + "\"]))"
       return "(lambda m : " + l + ")"
    
     # JUST TO EVALUATE THE BLOCK
     def rundo(g,l,s):
       return eval(closure(do(s),l),g,l)(l)
    
     # MONADES #
    
     class Monad:
         value=None
         def __init__(self,val):
             self.value=val
    
         @staticmethod
         def mreturn(val):
             raise NotImplementedError
    
         @classmethod
         def sequence(self,l):
            if len(l) == 0:
               return self.mreturn([])
            else :
               return rundo(globals(),locals(),"""
                  x <- l[0]
                  q <- self.sequence(l[1:])
                  self.mreturn([x] + q)
                 """)
    
         @classmethod
         def foldM(self,f,i,l):
           if len(l) == 0 :
             return self.mreturn(i)
           else :
             return rundo(globals(),locals(),"""
                x <- f(i,l[0])
                self.foldM(f,x,l[1:])
               """)
    
         def bind(self, func):
             raise NotImplementedError
    
         def __ge__(self, bindee):
             return self.bind(bindee)
    
         def __rshift__(self, bindee_without_arg):
            return self.bind(lambda _ : bindee_without_arg)
    
     # MONADE LISTE #
    
     def concat(x) :
       res = []
       for y in x :
         res.extend(y)
       return res 
    
     class Liste(Monad):
         @staticmethod
         def mreturn(val) :
             return Liste([val])
    
         @staticmethod
         def mreturnL(val) :
             return Liste(val) 
    
         def bind(self,func):
             def fval(x):
                return func(x).value
    
             return Liste(concat(map(fval,self.value)))
    
         @staticmethod
         def zero():
             return Liste([])
    
     def guard(b):
         if b :
            return Liste.mreturn(())
         else :
            return Liste.zero()
    
     # EXEMPLES
    
     test = eval(do("""
                        x <- Liste(["1" , "2" ])
                        y  <- Liste(["3" , "4" ])
                        Liste.mreturn (x + " and " + y)
                      """))
    
     print test.value
    

    Another point. Continuation and may yield be différent on one other point i think. When you want to use delimited continuation, i wonder if it's possible to implement shift/reset with yield. Maybe yes.

    Good post anyway :)

  6. Bill Mill says:

    @dolio python 2.5 gained generators that can be sent values; this makes them isomorphic to coroutines.

    Are coroutines isomorphic to continuations?

  7. Bill Mill says:

    > Is that called “filter” in Python?

    ahha – yes. Guido likes filter when used with builtins, but thinks a list comp is clearer than filter with a lambda.

  8. dolio says:

    Bill Mill: I’m relatively sure that continuations are more powerful than coroutines, although I don’t have any specific examples.

  9. Brock says:

    Coroutines are “one-shot” continuations. That is, with full continuations you can re-activate the same bundle of state multiple times. With coroutines you can stop-and-bundle some state, but you can only resume it once.

    Perl’s Coro provides coroutines, not continuations.

    Interestingly enough, for one interesting use of continuations — inverting the control of web applications ala Seaside — it turns out that coroutines are Good Enough ™.

  10. Sal says:

    I think whitespace is most understood. It is usually seen as a *gross* feature when you start perusing the language. However once you are have some momentum and actually start using the language, you will come to realize that it is one of its strengths; Code just seems to flow and productivity increases. Long time Perl master Eric Raymond discovered this as well (http://www.linuxjournal.com/article/3882).

  1. [...] – "Osfameron": Some thoughts on Python saved by osoy232008-09-19 – Implementation Language saved by gaastra342008-09-19 – Making a [...]