Python is wierd!

[Adam Ruth]

I learned dynamic languages when one day I decided to learn Smalltalk.  I
had the same problems you did at first.  No types, classes that can change
at run time, no "proper" encapsulation.  How could anyone build anything
that works in such a language.  But the thing that kept coming back to me
was that just prior to my picking up Smalltalk I read that a stock trading
system was just rolled-out in Smalltalk that handled 50% of all stock trades
in North America.  So it must work somehow.

Here's the main point that I learned that finally got me over the hump:

There is no compile cycle, only a testing cycle, at which point you're sure
that everything works.  With compile-time checking you can easily fall into
the trap that 'it compiled--it must work'.  Especially for small changes.
With dynamic languages, you can never assume that so you always test.  You
should always test all your changes with a static language too, but the
incentive to do so is less.  Once you get the mindset that 'it's okay
because I tested it and it worked', your dynamic code will have a quality
that intuitively must not be there.

--
Adam Ruth
InterCation, Inc.
www.intercation.com


"Richard Jones" <Richard.Jones at fulcrum.com.au> wrote in message
news:200007250541.PAA25542 at envy.fulcrum.com.au...
>
> [Jonathan]
> > 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 thought it was perfectly clear - much clearer than some other
languages :)
>
>    Static attributes are assigned at class definition. Instance attributes
are
> assigned to an instance once it's created. That's pretty straightforward.
If
> there's a confusion at a later stage about whether an attribute is
instance- or
> class- then you've probably got a fundamental design problem in your
class...
>
>
> > 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?
>
>    The generally accepted method is to put these utility functions where
they
> logically belong: in the module that defines the class, but not in the
class
> itself. If it doesn't operate on an instance, what business does it have
in the
> class definition. I use static methods in Java for one thing only: utility
> functions. That's because Java won't let me have stand-alone functions.
(That's
> not a dig at Java!)
>
>
> > 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.
>
>    Nope, everything is pass-by-reference in Python. Even your integer is
> pass-by-reference, but since it's an immutable object, it might _seem_
like
> you're passing the value of the object.
>
>
> > (Not to mention the number of 'gotchas' listed in the book that are
> > bound to trap beginners - *shudder*)
>
>    Gotchas? I've not read the book - are these actually stated in the book
as
> gotchas? I'll personally beat on the head of the author if they are :)
>
>
>       Richard
>
>
>