Python is wierd!

[Mark Baker]

In article <8ljrvu09t6 at news1.newsguy.com>, "Alex Martelli"
<alex at magenta.com> wrote:

>> 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.

Er....sort of.

class A:
	a = 200

	def __init__(self, x, y):
		self.x = x
		self.y = y

	def sum(self):
		return self.x + self.y + self.a # Scope within class, but accessible via self 

a = A(10, 20)
a.sum() => 230

An instance does a lookup inside of its class if something isn't found
within itself.


 
>> 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++).

friend is simply an evil way of violating encapsulation. It's not analogous to
modules, packages, or anything else. It simply provides a means of violating
C++'s encapsulation (usually for speed purposes, since you should be able
to use the accessor/mutator pattern to work with object properties)

packages and modules are more akin to categories or namespaces than the 
main unit of encapsulation, in an object sense.

Static functions aren't overly useful in Python because of the existance of
these categories, and the lack of enforced encapsulation. Mostly the latter,
but they're made more practical with the former.

>> 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!-)

Oh, there're a few. Just 99.9% of the time it probably is irrelevant to
the average Joe. Cyclic references, meta-class magic, some other minor stuff.

 
> 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.

Many first year CS students are subjected to Scheme, and most of the ones
I've been in contact with have considered switching majors because of it.

I'd stick with one of the first two, for beginners.
Smalltalk with its uniformity and snapshot nature, and Python with its
expected mathematical operator precedance and non-class enforced view
of programming.
 
> (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).

This is all especially true if you want to subject children to programming
early on, which is probably the best idea. At this point they aren't going
to need machine-oriented (C, C++, ...) or bloated languages 
(Common LISP, Ada, Perl, C++, ...).
In the long run any software engineer or computer scientist will need to learn
how the machines function, and how to make them do specific things.

For everyone else, there're practical languages. =)