Python rocks

[Mark Carter]

Well, I know I'm preaching to the converted - but Python rocks.

I've been enchanted by the siren calls of Scheme, Lisp and Forth, but in
the end, I find Python much easier. I even tried a little bit of Tcl.

To give a bit of context ... I have recently switched from Windows to OS
X and Linux. I missed MS Money, but couldn't get on with GnuCash. So I
decided to write my own little home-brew money management program that
includes things like downloading share price info from Yahoo Finance.

I picked Chicken Scheme for OS X. Things started well, and even the web
download and regex stuff worked fairly painlessly. I wanted to work with
dates, and decided that I needed the SRFI-19 library. Chicken has
"eggs", which you can download and install. The problem is that it
needed further dependencies. Well, no need to panic just because of
that; but I found that it ultimately depended on gmp, which turned out a
pain to compile.

Other languages seem to have neat ideas; like closures or macros in
Scheme, or ultra-simple syntax like Forth. But what I have generally
found is that other languages seem to require too much pain for too
little return. I just seem to be way more productive in Python than in
any other language.

 

[George Sakkis]

Well, I know I'm preaching to the converted - but
Python rocks.
[...]

A few questions from the choir:

As a recent newcomer to the language, did you
encounter any traps or pitfalls while you were
learning?

I had probably stumbled on many/most of the common pitfalls usually
mentioned (e.g. http://www.ferg.org/projects/python_gotchas.html,
http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
picked them up easily after the first or second time. Off the top of
my head, two errors that keep coming back even years after are:
- Comparing instances of (semantically) incomparable types (http://
www.ibm.com/developerworks/library/l-python-elegance-1.html).
Thankfully this will be fixed in Py3k.
- Strings being iterable; unfortunately this will stay in Py3K.

Also, could you single out anything in
particular about Python that started making you more
productive, or was it just the overall design?

If I were to pick a single feature, this would be the triplet
iterators-generators-itertools, not only for the productivity gains
but perhaps even more for changing the way of thinking about
programming, making Python worth learning [1]. But in general it's the
overall design, making the right tradeoffs in most cases.

George


[1] "A language that doesn't affect the way you think about
programming, is not worth knowing." - Alan Perlis

 

[Aahz]

I had probably stumbled on many/most of the common pitfalls usually
mentioned (e.g. http://www.ferg.org/projects/python_gotchas.html,
http://zephyrfalcon.org/labs/python_pitfalls.html) while learning, but
picked them up easily after the first or second time. Off the top of
my head, two errors that keep coming back even years after are:
- Comparing instances of (semantically) incomparable types (http://
www.ibm.com/developerworks/library/l-python-elegance-1.html).
Thankfully this will be fixed in Py3k.
- Strings being iterable; unfortunately this will stay in Py3K.

I'll repeat the comment I made on python-3000:

"...string iteration isn't about treating strings as sequences of
strings, it's about treating strings as sequences of characters. The
fact that characters are also strings is the reason we have problems,
but characters are strings for other good reasons."

Thing is, the fact that you can e.g. slice strings just like other
sequence types creates the consequence that you can also iterate over
strings -- moreover, some of us actually do iterate over strings (though
of course we could if necessary create lists/tuples of characters). In
the grand scheme of things, I rarely see people running into problems
with iterating over strings.

 

[Alex Martelli]

I picked Chicken Scheme for OS X. Things started well, and even the web ...
that; but I found that it ultimately depended on gmp, which turned out a
pain to compile.

Yes, GMP is a pain to compile (especially on Mac OS X), but I believe
that the Universal Binary library version I've put among the gmpy
downloads (see http://code.google.com/p/gmpy/downloads/list) works fine
(at least it seems to work fine for gmpy, which is my Python extension
that wraps GMP, and gmpy exposes and copiously unit-tests essentially
all of GMP's functionality).

Just mentioning this in case you want to give Scheme another chance
(which it may well deserve, although closures are hardly unique to it; I
wonder if you meant continuations). Python may enjoy better tools and
libraries than Scheme, but then Java enjoys better ones yet, yet I
prefer to stick with Python because I like it better *as a language*...


Alex

 

[Alex Martelli]

If it returns None, it probably changes the content of an object.

A reasonable heuristic, but with lots of exceptions, alas:
somedict.get(somekey)
will often return None without performing any change, while
somelist.pop()
does modify somelist but typically returns non-None.

The use of trailing-exclamation-point (by convention) to indicate
"mutating methods" is a nice plus in languages that allow it.


Alex

 

[Mark Carter]

Mark Carter <[email protected]> wrote:

Yes, GMP is a pain to compile (especially on Mac OS X), but I believe

Just mentioning this in case you want to give Scheme another chance

Thanks. I'll take a look at it.

I think I've decided to finish off my little in project in Python first,
though. I'd like to actually get it done (!). I may well decide to
reimplement bits in either Scheme, or I might try my hand at Forth. My
app will be small enough to permit re-writes.

I had actually done a small 3-month Java project professionally about 7
years ago. Can't say I was too impressed. IMO, it was too verbose, I'm
not an OO fanatic, and some immutable strings turned out to be not quite
as immutable as I expected.

I had a brief toy around with Java using Xcode very recently, and I was
able to figure out how to download webpages easy enough (I do this to
scrape stock quotes). I felt fairly confident that I could achieve what
I wanted in Java, even though I'm fairly raw with it. I started from a
default project using Xcode, and it seemed to generate a lot of base
code. I quickly abandoned the Java idea, as I'm not gunning to be a Java
developer, and Python seems to do what I want without fuss.

I think that's the key to Python. You can do what you want without fuss,
and it's copiously documented.

 

[Mark Carter]

A reasonable heuristic, but with lots of exceptions, alas:
somedict.get(somekey)
will often return None without performing any change, while
somelist.pop()
does modify somelist but typically returns non-None.

The use of trailing-exclamation-point (by convention) to indicate
"mutating methods" is a nice plus in languages that allow it.

Actually, that'd be nice to have in Python. And whilst we're about it,
might as well go the whole hog and allow hyphens in names, too.

 

[Alex Martelli]

Actually, that'd be nice to have in Python. And whilst we're about it,
might as well go the whole hog and allow hyphens in names, too.

Hyphens look the same as minus signs, so that allowing them in names in
a language with infix operator syntax is far from a clear win. Right
now, in Python and all cognate languages, a-b means a minus b; the
tectonic shift to having it be a 3-character identifier instead, in
addition to breaking millions of lines of existing code, would rightly
produce extreme resistance in anybody whose main programming experience
comes from Basic, C, Java, Fortran, C++, PL/I, Perl, C#, and Python
itself (and dozens of other languages, too, of course).

I noticed this effect when I was playing with Dylan (never did anything
"serious" with it, but I did like many aspects of the language): I kept
writing a-b (and for that matter a+b, etc) and getting weird syntax
errors because I had not interposed all needed spaces. (If a-b is not
allowed as an expression, it makes sense that a+b isn't either).

Despite substantial previous experience with Lisp, Scheme, and Forth, in
all of which a-b would "of course" be an identifier, that experience
just didn't guide my fingers -- in those languages operator are prefix
(Lisp, Scheme) or suffix (Forth), so it's "natural" that sticking an
operator sign "between" sequences of letters means nothing special...
but moving to an infix language just shifts my brain in a different
gear. Cobol has preferably-prefix notation too, i.e., the natural way
to express the difference would be "SUBTRACT C FROM B", and the
alternative "algebraic" (infix) notation is and feels very "bolted-on",
so it's kind of an intermediate case, where hyphens are still OK.

Not only is the cost of making a-b an identifier extremely high, but the
gains are tiny: what conventional difference is there supposed to be
between a-b and a_b? Looks like nothing but one more category of easily
confusable identifiers. Big pain, little gain == not so great an idea.

Allowing a trailing ! in method names has no such cost, because in no
language I know is ! used as a "postfix unary operator"; the gain in the
convention "mutators end with !" is not huge, but substantial. So, the
tradeoffs are different: small pain, substantial gain == not a bad idea.

However, this is all quite theoretical, because no more PEPs will be
accepted for Python 3000, so any language change like this would have to
wait for Python 4000, which is no doubt quite a distant prospect.


Alex

 

[Alex Martelli]

Thanks. I'll take a look at it.

You're welcome.

I think I've decided to finish off my little in project in Python first,
though. I'd like to actually get it done (!). I may well decide to
reimplement bits in either Scheme, or I might try my hand at Forth. My
app will be small enough to permit re-writes.

Excellent situation to play around with many languages, then. If your
app can run on dotNET or Mono, you might also want to try Boo, a
language somewhat inspired by Python but with a different approach to
typing (based on type-inferencing, with an explicit 'duck' type for
those rare cases in which you really _want_ a single variable to take on
values of heterogeneous types during execution).

I had actually done a small 3-month Java project professionally about 7
years ago. Can't say I was too impressed. IMO, it was too verbose, I'm
not an OO fanatic, and some immutable strings turned out to be not quite
as immutable as I expected.

Nolo contendere on the verbosity and the need to stuff _every_thing into
a class, but the non-immutable-strings looks like a serious bug in
whatever JVM you were using at the time. Anyway, what's impressive with
Java today is not the language (maybe a bit better than it was 7 years
ago but still substantially Java, it's the array of excellent tools,
libraries and frameworks grown around it; Java's standard library has
arguably surpassed Python's, and third-party offerings for Java are
really great.

I had a brief toy around with Java using Xcode very recently, and I was

Not the best IDE for Java, btw -- Apple doesn't seem to like Java all
that much any more, and it looks to me like it's backpedaling on Java's
integration in MacOSX (in favor of Python, Ruby, etc). BTW, ObjectiveC
is another language worth trying (though its non-Apple implementations
lag far, far behind, alas). Eclipse is probably "the" Java IDE nowadays
(and it's free, cross-platform, and all).

able to figure out how to download webpages easy enough (I do this to
scrape stock quotes). I felt fairly confident that I could achieve what
I wanted in Java, even though I'm fairly raw with it. I started from a
default project using Xcode, and it seemed to generate a lot of base
code. I quickly abandoned the Java idea, as I'm not gunning to be a Java
developer, and Python seems to do what I want without fuss.

I think that's the key to Python. You can do what you want without fuss,
and it's copiously documented.

Yes, excellent points. Although I have a long-time fascination with
many programming languages, Python does still stand out from the crowd
in enabling me to get any given app done "without fuss"!-)


Alex

 

[George Sakkis]

I'll repeat the comment I made on python-3000:

"...string iteration isn't about treating strings as sequences of
strings, it's about treating strings as sequences of characters. The
fact that characters are also strings is the reason we have problems,
but characters are strings for other good reasons."

No, the reason we have problems is that far more often than not
strings are treated as atomic values, not sequences of smaller strings
or characters. A classic example is flatten(), where most people are
surprised if flatten([1, (3.14, 'hello')]) returns [1, 3.14, 'h', 'e',
'l', 'l', 'o'].

Thing is, the fact that you can e.g. slice strings just like other
sequence types creates the consequence that you can also iterate over
strings -- moreover, some of us actually do iterate over strings (though
of course we could if necessary create lists/tuples of characters). In
the grand scheme of things, I rarely see people running into problems
with iterating over strings.

One class of problems is functions such as flatten() that expect "a
collection or an atom", with strings being typically considered
atomic. A second common pitfall are functions that expect file-like
objects but are given file names instead:

def process_file(input_file):
for line in input_file:
do_stuff(line)


process_file('/home/george/.bashrc') # oops

I now try to remember to write such functions as:

def process_file(input_file):
if isinstance(input_file, basestring):
input_file = open(input_file)
for line in input_file:
...

It's not a huge impediment by any means but it's certainly a gotcha.

George

 

[Klaas]

Allowing a trailing ! in method names has no such cost, because in no
language I know is ! used as a "postfix unary operator"; the gain in the
convention "mutators end with !" is not huge, but substantial. So, the
tradeoffs are different: small pain, substantial gain == not a bad idea.

However, this is all quite theoretical, because no more PEPs will be
accepted for Python 3000, so any language change like this would have to
wait for Python 4000, which is no doubt quite a distant prospect.

Would it? If it isn't backwards-incompatible, it could even go in 2.6

-Mike

 

[Aahz]

I'll repeat the comment I made on python-3000:

"...string iteration isn't about treating strings as sequences of
strings, it's about treating strings as sequences of characters. The
fact that characters are also strings is the reason we have problems,
but characters are strings for other good reasons."

No, the reason we have problems is that far more often than not
strings are treated as atomic values, not sequences of smaller strings
or characters. A classic example is flatten(), where most people are
surprised if flatten([1, (3.14, 'hello')]) returns [1, 3.14, 'h', 'e',
'l', 'l', 'o'].

Enh. That's not my experience -- the ability to slice, dice, and
concatenate strings is intrinsic to their usefulness.

One class of problems is functions such as flatten() that expect "a
collection or an atom", with strings being typically considered
atomic. A second common pitfall are functions that expect file-like
objects but are given file names instead:

def process_file(input_file):
for line in input_file:
do_stuff(line)

process_file('/home/george/.bashrc') # oops

That's a problem, yes, and it has oddly enough gotten worse since
iterators were introduced into Python. Nevertheless, I have yet to see
anyone suggest a mechanism for fixing this particular gotcha without
creating more problems. Strings are just too useful as sequences.

Moreover, my experience is that these kinds of problems don't show up
all that frequently in practice.

 

[Carl Banks]

Allowing a trailing ! in method names has no such cost, because in no
language I know is ! used as a "postfix unary operator";

Some math oriented languages use it as the factorial function. E.g.,
Mathematica:

In[1] := 10!

Out[1]= 3628800


(The more you know....)

Carl Banks