syntax philosophy

Tuang tuanglen at hotmail.com
Wed Nov 19 00:56:50 CET 2003


"Andrew Dalke" <adalke at mindspring.com> wrote in message news:<hvjub.4572$sb4.1007 at newsread2.news.pas.earthlink.net>...
> Tuang:
> > But I'm surprised at what you apparently have to go through to do
> > something as common as counting the frequency of elements in a
> > collection. For example, counting word frequency in a file in Perl
> > means looping over all the words with the following line:
>  ...
> > This seems sort of unPythonesque to me, given the relative cleanliness
> > and obviousness (after seeing it once) of other common Python
> > constructs.
> >
> > But I guess I'm making assumptions about what Python's philosophy
> > really is.
> 
> I see several replies already, but they don't seem to address your
> question about the philosophical reasons for this choice.

Thanks for a spot-on answer to my exact question. ;-)

> 
> A Python philosophy is that "Errors should never pass silently."
> (To see some of the other points, 'import this' from the Python
> prompt.)
> 
> When you reference '$histogram{$word}++' in Perl it automatically
> creates the hash 'histogram' and creates an entry for $word with
> the value of 0 (I think; it may set it to undef or "").  This is great,
> as long as you don't make mistakes.
> 
> But people do make mistakes and misspell variables.  Had you
> written '$histrogram{$word}' then Perl would have simply
> created a new hash for you with that name.  This is enough of
> a problem in Perl that it's recommended you 'use strict'
> and declare the hash beforehand, as 'my %histogram'.

Very true. Other respondants made this point as well, which I think is
a good one. It sort of points out that my favorite use of Perl is for
quick one-liners that let me do exactly what I want on the spur of the
moment, as opposed to writing bigger "programs" for repeated use. I've
done both in Perl, but I think it's better suited to the former than
the latter. Python appears to scale up much more gracefully.

That use of Perl for one-liners, though, is why having them be easy,
automatic, and memorable matters. That's why I would prefer the same
convenience in anything I use to replace Perl for "Swiss Army knife"
use. I would apparently have to give up a bit of the convenience at
the one-liner level to buy the superior scaling (and other relative
benefits) of Python.

> ...Python is strongly
> typed, so "2"+1 will raise an exception, unlike Perl where it
> yields the number 3.  If Python used a 0 for the default then
> what if you really wanted to concatenate strings?  If it used
> "" then what if you wanted to add numbers?  Whatever choice
> you make, it will be wrong for most cases.

I find Perl's defaults to be right almost *all* of the time. Increment
a counter? Fine, $counter++ creates the counter if it needs to be
created, initializes it if it was just created, and then increments
it. On the rare occasions when I want it initialized to something
other than 0, I just initialize it myself, but the default
initialization of zero is right almost all the time for numbers, so
why not take advantage of that fact?

And how often would you want to initialize a string to anything other
than an empty string? So in Perl, you just start concatenating, and if
the string doesn't already exist, it's automatically created for you
and your first concatenation concatenates to an empty string. Again,
Perl's default is almost always what you want, and in those rare cases
where it's not what you want, you're free to do what you have to do in
Python every single time.

Your point about the typing, though, may be a reason why such a thing
couldn't be done in Python, and your point about "use strict"
indicates to me that such convenience may have proven to be a
liability as soon as your program starts to grow.

I do know that there have been a few occasions when I've been stumped
by Perl's guessing incorrectly at what data type I meant and my not
having any way to explicitly tell it.


> Your reply is that you're looking for the philosophy behind
> Python, using the histogram as an example.  That actually
> is part of the philosophy -- in Python it's much easier to
> make a class and instantiate an object with the appropriate
> behaviours than it is in Perl, what with Perl's "bless" and
> shift and @ISA.  

This is very true. It's starting to appear as though Python's
built-ins are often less convenient than Perl's, but in every case
that I've seen so far it has been easier to combine those built-ins
into higher-level abstractions in Python than in Perl.


The above 'Histogram' is simply
> 
> class Histogram:
>   def __init__(self):
>     self.histogram = {}
>   def count(self, word):
>     self.histogram[word] = self.histogram.get(word, 0) + 1
> 
> In Perl the equivalent would be something like (and only
> roughly like -- I never did fully figure out how do to Perl
> OO correctly)

LOL! Neither have I. It's not that we're retarded -- well, you be the 
judge ;-) -- but it's just more trouble than it's worth in Perl. There
are so many useful Perl modules that I try to remember just enough to
be able to use other peoples', but it's just not worth the bother
remembering how to make them myself. After a few hours with Python, I
was already better at object-oriented Python than I ever was at
object-oriented Perl.


> 
> package Histogram;
> sub new {
>   my ($class, $obj) = @_;
>   bless $class, $obj;
>   $obj -> {'histogram'} = {};
>   return $obj;
> }
> sub count {
>   my ($class, $obj, $word) = @_;
>   $obj -> {'histogram'}{$word}++;
> }
> 
> However, for a one-off histogram this level of abstraction isn't
> worthwhile.

Amen. But $hist{$word++} works beautifully.

> 
> To summarize, Python's philosophical differences from Perl
> for your example are:
>   - variables must be declared before use (reduces errors)
>   - dict entries must be declared before use (reduces errors)
>   - dict entries cannot have a default value (strong typing)
>   - classes are easy to create (letting you create objects which
>         better fit your domain)

Thanks. That perfectly explained the philosophy behind my example.




More information about the Python-list mailing list