Python discussion, anybody?

["Stephen J. Turnbull" <turnbull@example.com>]

>>>>> "Fredric" == Fredric Fredricson <fredric.fredriksson@example.com> writes:

    Fredric> Some things seems very good, others I can live with but
    Fredric> there is one issue that keeps bugging me.

Or one bug you keep issuing?  Are you sure it's not just the typo?

    Fredric> Consider: 

    >> class C:
    >> def __init__(self):
    >> self.member = 17
    >>
    >> cobj=C()
    >> cobj.memmber = 18
               A
               +-- This can't work as intended!

    >> print cobj.member

    Fredric> What will be printed? If you think "18", read again.

On my system with a now-obsolete flying circus:

bash-2.04$ python
Python 1.5.2 (#0, Apr  3 2000, 14:46:48)  [GCC 2.95.2 20000313 (Debian GNU/Linux)] on linux2
Copyright 1991-1995 Stichting Mathematisch Centrum, Amsterdam
>>> class C:
...  def __init__(self):
...   self.member = 17
... 
>>> c = C()
>>> print c.member
17
>>> c.member = 18
>>> print c.member
18
>>> 

The fact that the same syntax works for instance members, class
definitions, modules, and packages without confusion always amazes
me.  It can be a pain in the ass (Debian distributes packages all over
the place, making it quite hard to track down the actual code when
packages get deeply nested), but it is elegant.

    Fredric> From browsing around www.python.org I realize that
    Fredric> variable declarations are not popular in the python
    Fredric> community but I fail to see why.

Because they clutter the code to no particular purpose.  Putting them
in the language itself is inappropriate for what is basically a
scripting language.

Strong typing is appropriate where representations are exposed; I see
no need for it when objects are basically opaque and self-typing, and
the syntax itself is open and readable.

As Simon will undoubtedly point out if I don't, it is possible to use
nested class references in Python to achieve the impenetrability of
intentionally obfuscated K&R C preprocessor.  But that's not good
style in Python.  The point is that (1) well-styled Python programs
are easier FOR ME to read than similarly excellent Perl programs, and
I have a lot more Perl experience than I do Python, and (2) it's much
easier for the walking wounded (== ex- and current VB programmers) to
write clear Python than it is to write clear Perl.

And what was it you were saying about the new book, Simon?

    Fredric> Do I always use "use strict;" in perl? 

Well, I if it works for you, great.  It does _not_ prevent most of the
Debian support code from being uglier than a Basic program printed in
an Orcish font, and having correspondingly ugly bugs, thinkos, and
out-and-out braindeadness.

    Fredric> Do I like type safe computer languages? 

Python _is_ type safe.  Polymorphic != type unsafe.  I guess you mean
"strongly typed"?

To my mind, strong typing is about allowing the compiler to catch
design errors, something compilers are not good at.  If you've written
your interfaces correctly, you will not try to poke nantoka& pegs into
struct _kantoka locations.  And if you do, unlike C and C++ which
allow you to cast away the error, Python will bark at runtime.

The advantage of Python (and LISP, for that matter) is that it makes
writing such interfaces natural.

    Fredric> "consistency is the mark of a small mind"[1] ;-)

    Fredric> [1] Think it's Mark Twain, but I'm not sure...

"A foolish consistency is the hobgoblin of little minds." -- Emerson


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."