What is Python's answer to Perl 6?

[Jeremy Bowers]

On Sat, 30 Oct 2004 11:18:30 +0200, Reinhold Birkenfeld wrote:
> What is Python's answer to Perl 6?

"Hi, welcome to the party.

Wow, you sure have an awful lot of cruft attached to you, considering you
can't do much more, if any, than me."

Perl 6 may be the best thing that happened to Python. Esp. if both run on
Parrot and people suddenly have a per-object choice about which language
to use. Ob-believe-it-when-I-see-it.

Perl 6, IMNSHO, represents the ultimate failure of the philosophy of Perl.
When you are a small language, a handful of exceptions for the common
cases might make sense. Even Python has its little exceptions, like the
"print" statement-not-a-function, and the resulting "print >>" syntax.

In the Python philosophy, those were warts. In the Perl philosophy, those
would be something to be embraced, and indeed they are:

       print FILEHANDLE LIST
       print LIST
       print   Prints a string or a list of strings.  Returns true if success-
               ful.  FILEHANDLE may be a scalar variable name, in which case
               the variable contains the name of or a reference to the file-
               handle, thus introducing one level of indirection.  (NOTE: If
               FILEHANDLE is a variable and the next token is a term, it may
               be misinterpreted as an operator unless you interpose a "+" or
               put parentheses around the arguments.)  If FILEHANDLE is omit-
               ted, prints by default to standard output (or to the last
               selected output channel--see "select").  If LIST is also omit-
               ted, prints $_ to the currently selected output channel.  To
               set the default output channel to something other than STDOUT
               use the select operation.  The current value of $, (if any) is
               printed between each LIST item.  The current value of "$\" (if
               any) is printed after the entire LIST has been printed.
               Because print takes a LIST, anything in the LIST is evaluated
               in list context, and any subroutine that you call will have one
               or more of its expressions evaluated in list context.  Also be
               careful not to follow the print keyword with a left parenthesis
               unless you want the corresponding right parenthesis to termi-
               nate the arguments to the print--interpose a "+" or put paren-
               theses around all the arguments.

               Note that if you're storing FILEHANDLES in an array or other
               expression, you will have to use a block returning its value
               instead:

                   print { $files[$i] } "stuff\n";
                   print { $OK ? STDOUT : STDERR } "stuff\n";

Just the docs for the print statement have to tell you about the call
context of the calls in a list, there's a special case that requires a
block. Python's print doc is longer by word count, but is actually simpler.

http://docs.python.org/ref/print.html

plus the last paragraph is a wart.

The problem is the little exceptions start interacting exponentially, and
ultimately, exponentially beats anything that a human can produce. Perl 6
may be great to use, but it will be a long time before I trust it, and I
strongly expect that despite how rosy everything is presented in the
Exegeses and such, that if you try to combine two or three of the nifty
features you'll be pulling out your hair in nothing flat. I don't and
can't know this, this is just my intuition, based on experience, speaking. 

And what on Earth does Perl 6 say about Perl 7?

As a user of both Perl and Python, I am not concerned about Python being
"wiped out" by Perl 6, nor do I see a strong need to change Python as a
result. So far, the Python implementation of the good ideas I see in the
Perl 6 docs have been trivial, and so far, despite having implementations
on hand I've never needed them. ("any" and related keywords come to mind.) 

(I have a similar rant about software reverse compatibility, and why it is
a trap: http://www.jerf.org/iri/2004/06/20.html

I think the way Python does it is just about optimal; try hard, but
reverse compatibility is not job #1 and if we *have* to break it, do so.
By dealing with the problem head on, everything actually works out much
better than if you sweep the problem under the rug until you can't
possibly do it anymore, and your platform is bulging at the seams with
reverse compatibility code.

In terms of the essay above, Perl is headed for exponential pain, only
instead of it coming about because of reverse compatibility fixes/hacks,
it is coming about because of the interactions of all of the More Than One
Ways To Do It, and those Ways ultimately have the same effect as reverse
compatibility patches/hacks.)