Python is wierd!

[Alex Martelli]

"Jonathan" <theebh at yahoo.com> wrote in message
news:8lj7kr$ttc$1 at nnrp1.deja.com...
> Hi, just finished going through the 'Learning Python' book, and the
> feeling that i get is that Python is really wierd(compared to other
> conventional languages like C++, Java, etc). For e.g.(correct me if i'm

Funny.  With my background being 20+ years of (Fortran, Pascal,
APL, C, C++, Java, Perl, &c), I picked up Python a few months ago
and found myself *immediately* productive with it.  No weirdness
that I could perceive...


> 1. There are no keywords to declare static or instance variables; it
> all depends where they are placed(whether it's right after the <class>
> statement, or inside a <def>). Isn't it harder for other programmers to
> know at one glance what type of attributes the class define?

I see a "self.something=23", I know "self" is an instance variable; no
muss, no fuss.  MUCH clearer than the implicit-this convention of
C++ and Java.  Explicit self -> less weirdness, not more.


> 2. No *formal* declaration of static class methods, e.g. no 'static'
> keyword (though i'm not sure how useful static methods are in OOP
> design). I read somewhere in this newsgroup that the workaround way is
> to define the method outside of the class - doesn't it break
> the 'encapsulation' a class suppose to have?

Encapsulation in Python is a matter of convention (as it actually
ends up being in all languages, but most strive hard to make it
appear they enforce it:-).  Static methods are not particularly
useful when you can have free-standing functions in their stead,
and grouping by-module is more productive than by-class (the
class is not the natural unit of encapsulation, an issue that is also
acknowledged by the package concept of Java and the friend
keyword in C++).


> 3. No keywords to differentiate between passing arguments by reference
> or value! An integer is passed by value(reference to a new copy), while
> a mutable object is by reference. To pass a list by 'value', i know you
> just need to insert one more line(list = [:]), but it seems
> so 'inconsistent' compared to Java or even PHP.

*Blink* what IS the difference supposed to be, in the above paragraph,
between the situation in Java and in Python, again?  You pass an int,
it's by-value (notionally, reference-to-immutable-value); you pass an
object reference, it's by value *of the reference*, i.e., by reference *on
the object*.   What "keywords to differentiate between passing
arguments by reference or value" is Java supposed to have acquired
since I studied and used it...?

The ByVal/ByRef keywords are in Visual Basic, and I don't really miss
them at all in Python just as I didn't use to miss them in Java.


> (Not to mention the number of 'gotchas' listed in the book that are
> bound to trap beginners - *shudder*)

Such as...?  I breezed through "Learning Python" several months
ago, and I don't recall such "gotchas".  Any gotcha-risk I can imagine
Python having, would have to be towards programmers experienced
in a very modest variety of other languages; beginners, using Python
as their first language, and old-hands like me, having already survived
the wide variety of semantics and syntax of a dozen other languages,
should be reasonably immune.

The three-scopes-and-no-more rule, where each name can only be
local, global, or built-in (no other possibilities, no nesting of scopes),
for example, is extremely simple; somebody used to nested-scopes
exclusively will find it unfamiliar at first, I guess -- is this sort of
thing
the one you consider a "gotcha"?


> The reason i'm picking up python is that i got sick of PERL:), and

That was my key motivation at first, too.  I've now moved to Python
basically everything that I used to do in Perl -- and I've been quite
surprised that Python becomes my language of choice for many
other things that I'd never have considered Perl for.

> don't really like the inflexible typing of Java. Furthermore, some ppl
> claim that Python is easier to learn, enables you to write much cleaner

With my limited experience, I'd underwrite this.

> codes... However, after reading the python book, my head is still
> spinning, trying to catch all the 'intricacies' of this language. No

But there aren't any.  That's why it's so powerful!-)

> doubt it will be a powerful and useful 'tool' to me once i get used to
> it; but i don't think it's suitable to be a first programming language
> for non-programmers(i read somewhere about this project going on).

CP4E, I guess.  I believe it's probably the best for most people.

> Pascal(for procedural) and Java(for OOP) is still the better choice to
> start off, IMHO.

There are two main schools about the kind of features a beginners'
language should provide.  The bondage-and-discipline school holds
that such a language should strictly confine the beginner to "what is
good for him/her", *forcing* him/her to do things "the one true way".
The flowers'-children school holds that a tool's role is to get OUT of
the way, being as simple and obvious as feasible, to let the learner
concentrate efforts on the REAL difficulties of learning to think like
a programmer.  Of course, there are sub-schools of each, which
depend on secondary considerations such as syntax.  But the main
split, as I see it, is between these two key world-views.

If you subscribe to B&D, of course Python would not be appropriate,
since it *avoids* binding the user's hands in such wise.  It does try
to offer "one clearly correct way to do things", but never goes out of
its way to _constrain_ users to that one way.  Pascal, Sather, Java,
Oberon, would be outstanding candidates for a first language on the
B&D lines.

Python, together with Smalltalk, Scheme, or Rexx, is an outstanding
candidate for the _second_ way to look at the world.  Of these, Python
would be my favourite were I to pick such a language today.

(Other languages such as Perl, C++, Ada, Common Lisp, and so
on, I view for different reasons as too complex and obtrusive to be
good first-programming-languages, and similarly for lower-level
languages such as C, machine language of any ilk, or Forth).


Alex