[unrev-II] Evaluation of Python

From: Eric Armstrong (eric.armstrong@eng.sun.com)
Date: Fri Mar 24 2000 - 14:47:37 PST

  • Next message: Jeff Miller: "Re: [unrev-II] Evaluation of Python"

    From: Eric Armstrong <eric.armstrong@eng.sun.com>

    I ran through about half the Python tutorial yesterday.
    I see some great things about the language, but also
    some major weaknesses. The features, with pluses (+)
    and minuses (-) are noted below.

    JPython vs Python:
      --Runs on Java virtual machine
         (+) runs everywhere
         (-) slower
      --Can use and/or extend Java classes (+)
      --Can be built into a Java app as a command
          interpreter (+)
      --Can't trap Ctrl-C. So Ctrl-C aborts the shell (-)
      --No command-line editing (-)

    Python (and JPython)
      --Indentation implies nesting
         (+) Eliminates tyranny of braces.
         (-) All subelements must have same indentation.
              It's hard on parsers if they don't, and hard on
              humans to meet the requirement. (XML can
              eliminate the problem nicely.)
      --Dynamic Typing
         (+) Great for quick coding
         (-) Means a lot of problems aren't detected at
              compile time that could be
      --Dispatch to named method (like C)
         [Note: I'm pretty sure I saw an example of this
         in the EasySAX code.]
         (+) This is a cool feature. You don't need it often,
               often, but when you do its irreplacable.
      --Any non-zero integer == true, like C
         (-) Ugh. Too many hours wasted on debugging to
              find that you coded a=b instead of a==b, like
              you intended. This one is a time-sink.
      --Intelligent for statement
         (+) It's "for x in aList". Yes!
      --Interesting "for-else" construct
         (+) A good control mechanism -- it's executed on
               normal loop completion, but not after a "break".
         (-) Horribly named. It's not executed *instead of*
              the for (as "else" relates to "if") but is executed
              *in addition* to the for. A better name might
              have been "ok", or "for-ok".
      --Can't modify list sequence while looping -- have to
         modify a copy.
         (+) The compile time error prevents runtime errors
               I used to run into in Java before the ListIterator
               came along.
          (-) Not being able to modify under any circumstances
               means you have to copy large lists, and use the
               arcane syntax "list[:]" which implies a copy, rather
               than the original. On the *other* hand, in JPython
               it would be possible to generate a ListIterator for
               a class...
      --No labeled break/continue
         (-) When you have nested loops, you absolutely need
               the ability to determine which one you are breaking,
               continuing.
      --The class can specify default argument values
         (+) Not all values need to be specified in the call.
         (+) Defines "overloading" of method names without
               having to manually craft each individual method. Since
               the most common use of overloading is to define default
               values, this feature saves a lot of time and simplifies
               APIs.
       --Multiple ways to call a function, with parameters specified by
          name or by position, as:
             foo(arg1="a", arg2=50),
             foo("a", 50), or
             foo(arg2=50, arg1="a")
          (+) Lets you make your own ordering if you don't like the
                original.
          (+) Lets you label the thing your passing. Especially valuable for
                numerics and true/false args. Instead of "new Document(true)",
                you can write "new Document(validating=true)". The only way
                to get that readability in Java is to define a whole new variable.
          (-) Reording the argument sequence has got to interfere with
               readability.
          (-) Overloading in any other way must be impossible, since
               specifying default values like foo(string="b", number=n)
               makes it impossible to define either foo(string) or foo(number),
               as separate methods. The lack of overloading raises problems
               for append() methods like append(string), append(number),
               append(float), append(double), etc. Of course, with dynamic
               typing you don't need overloading for that kind of behavior,
               so maybe between dynamic typing and default-value specifications,
               overloading is really a non-issue.
      --Lambda function [I have a weak grasp on this one, good enough to
         give an evaluation but not good enough to produce an example.]
         (+) Makes it easy to define small, anonymous functions
         (-) Reduces readability
      --Functional programming functions: filter, map, reduce
         (+) Really cool, fun to play with, and useful for building up
               complex tools from simple components, like Unix pipes
      --Data Structure: Lists, Strings/Characters, Tuples
         (+) Well chosen set, and characters are just strings of length 1,
               so you don't need two sets of tools to deal with them.
      --I/O functions:
         (+) pickle and unpickle make it easy to read
              and write any of the standard types for persistence.
      --Exception handing
         (+) try/except for catching them, raise for throwing them,
              try/finally for clean up.
      --Limited Multiple Inheritence
         (+) That's a useful feature that allows you to extend a class
               written by a third party. Saw an example in JBuilder where
               that was necessary -- a class's private constructor used
               a protected constructor in the super class. It was impossible
               to extend the leaf class -- you had to extend the super
               class, and then totally rewrite the leaf class. As always,
               modifying the design was the "right" solution. That makes
               multiple inheritance unnecessary. But with 3rd party code
               you don't have access to, multiple inheritance is sometimes
               needed.

    All in all, I would rate Python as WAY better than Perl for
    fast hacks, yet not up to Java's standards for production programs.

    Interestingly, Howard Golden writes that "Jim Hugunin, who
    developed JPython at CNRI, is now at Xerox PARC, where he
    is working on AspectJ." One wonders if AspectJ solves some
    of Python's more egregious miscarriages of developmental
    justice...

    AspectJ exists at http://aspectj.org/servlets/AJSite.
    It's one of 135 languages built on the Java Virtual Machine that
    is listed at http://grunge.cs.tu-berlin.de/~tolk/vmlanguages.html.
    (The "What is JPython?" page was nice enough to include a link
    to that one.)

    ------------------------------------------------------------------------
    MAXIMIZE YOUR CARD, MINIMIZE YOUR RATE!
    Get a NextCard Visa, in 30 seconds! Get rates as low as
    0.0% Intro or 9.9% Fixed APR and no hidden fees.
    Apply NOW!
    http://click.egroups.com/1/2122/3/_/444287/_/953938054/
    ------------------------------------------------------------------------

    Community email addresses:
      Post message: unrev-II@onelist.com
      Subscribe: unrev-II-subscribe@onelist.com
      Unsubscribe: unrev-II-unsubscribe@onelist.com
      List owner: unrev-II-owner@onelist.com

    Shortcut URL to this page:
      http://www.onelist.com/community/unrev-II



    This archive was generated by hypermail 2b29 : Fri Mar 24 2000 - 14:54:46 PST