Python questions from C/Perl/Java programmer

[David Bolen]

"ye, wei" <yw at alabanza.net> writes:

> I have been using 'emacs',  it's a nice editor, however I still concern if
> add or remove a new block within a complex logic it may mess up
> the old application. However if {} is applied, I'm pretty sure it doesn't
> happen.

There isn't really that much difference with Python code (and Emacs
has a nice Python mode).

Typically, if you're inserting a new block, it's going to be scoped
beneath some existing block, and indentation is still easy to handle
(just as you'd likely indent your braced block anyway).

If you need to reallocate a block, certainly within Emacs it is easy
to shift any portion of your current block in or out a level as
necessary.

I'm sure like many people here I felt sort of "naked" without my
braces when I first started with Python - but when it comes down to
it, I was already indenting my code logically (or letting Emacs do it
for me) within the braced blocks, so as it turns out, removing the
braces didn't really change the way I wrote or indented code and it's
just as readable and easy to work with.

I still occasionally miss the trailing braces at the bottom of heavily
indented blocks, if only as a place to "hang" my comments about what
block they are closing - of course that very construct was because
even in C/C++ it was far from clear in some cases from just looking at the
brace :-)

> I can bear the {} issue, however I couldn't bear with variable
> without declaration.  I wrote many applications, I couldn't live
> without declaration. For big project, there are so many scripts,
> everyone may be misspell variable name.  It's very timeconsume and
> hard to find out such problem, which should be easy checked out by
> compiler.

Ah, but it's not at all easy to check in a fixed way with a dynamic
language like Python, as I think you'll see as you work with it a
little more, and run into items like __getattr__ or exec().  And if
you do get it wrong, an exception is thrown for you and the traceback
makes it easy to find.

I think this is sort of one of these "Trust the Force, Luke" things.
One of the very first things I worried about and tried to find a
resolution to with Python was the issue of typos leading to NameErrors
that I couldn't find because I didn't have compile time checking.  I
was surprised that there weren't a ton of syntax checkers out there
(but there are definitely a few).  I religiously tracked them down and
downloaded them.

You know what - I still haven't used them to any large extent, because
surprisingly (to me at least) it hasn't been a big problem of mine at
all in the code I'm working on.  I think it's a mixture of a number of
things.  For example, Python's module system is terrific and really
encourages small modular design with individual namespaces.  The
standard idiom of embedding tests into scripts themselves when run
standalone means you think more about matching tests with your work as
you go.  And the exception handling is clean, ubiquitous and
consistent.  Heck, wrap your entire application in a top level
try/except worst case if you want as a master safety net - you just
re-initialize and keep running :-)

So if this is the only thing really causing you heartache, the best I
can suggest is to just get in there and try.  You may surprise
yourself in the same way as I have.

> Yes, it is if you define a function expect a base class, its derived
> class object should have no problem to be passed in. Both Java/C++
> have this feature.

And if you give Python a chance I think you'll start to wonder why
Java/C++ is so limited :-)  How many times has a well designed class
system gotten "re-designed" or just crufty because of molding things
into the hierarchy to fit the requirements of libraries or other
routines expecting a particular type of class.  I've had enough
experience with growing poorly designed class systems to think that
there just has to be a better way.  I felt that Java's interface
approach felt more natural but its still quite strongly typed.

The whole notion that you must have a formal class inheritance
hierarchy in order to be able to use one object in place of another
(e.g., a derived class), while valid, is hardly the only way to go.

In Python, what matters is not the formal class hierarchy - in Python
it's more common to inherit to obtain functionality than to impose an
"is one of" classification.  For Python, it's the actual dynamic
run-time interface provided by an object that is of utmost importance.
This is more similar to 'interfaces' in Java, but even there Java is
more strict than Python.

If a function requires that the supplied object support a "write"
method, then all Python requires is that be the case.  And it only
cares when the function actually tries to make the call, not at
compile time or function declaration.  It doesn't where the object
fits in a class hierarchy, nor if the object provides all sorts of
unrelated methods.  It only wants that "write" method to be present.

Until you've worked this way you can't imagine how clean, natural and
"fun" this is - at least IMO.  It makes design much cleaner and
simpler, and means that you can evolve things more simply.  No, it's
not perfect and has its own warts, but I'm sold on it.

> If don't specify the variable type:
> 1. When you read code, it's not easy for you to understand how to invoke that
> function.
>    For example, compare
> def f(x, y, z): ...  with def f(int x, complex b, Employ c): ...
> which declaration give you more information without read further code?
> You know how to invoke the latter one without read its code and comments in
> most cases.

Why is reading the declaration for a function (which Python supports
via docstrings) to understand that any better or worse than reading
documentation?  Or to phrase it another way, why bother with the
syntactic sugar (and limitations) of the static typing when you can
just as easily place the interface requirements in the developer
documentation and have a function that can literally work on any
object without ever needing changing or massaging of the class
hierarchy, as long as it conforms to the interface?

> 2.  it leads the function is mis-called by passing not correct type.

Ah, but now we get to the rub of what makes a type "not correct" - in
Python, that would mean that it's got the wrong interface, and if
that's the case it's easy for the function in question to just raise
an exception, either by explicitly checking for the interface, or just
attempting to use it and letting Python itself raise the proper
exception when it isn't present.  The amount of control over the
process and its error recovery is completely in the application's
control.

But if the object in question does have the right interface, Python
doesn't care what class it is part of or really anything about the
class hierarchy - it just cares that it conforms to the required
interface that the function desires for its argument.


Don't get me wrong - if your background is more biased towards heavily
typed languages (mine was, although I did have some decent experience
in others) it's sort of a paradigm shift and takes some thinking to
get over.  The best I can suggest is to jump in there and write some
code.  You may be pleasantly surprised and start reconsidering some of
these points - not so much their usefuless as points - but more how
important they really are (or aren't) in the Python world.

Then again, maybe not, in which case there are lots of other languages
out there - and as another poster said, some improvements in these
areas (but not, I expect, quite as far as you're advocating here) are
likely to show up in future Python releases as well.

--
-- David
-- 
/-----------------------------------------------------------------------\
 \               David Bolen            \   E-mail: db3l at fitlinxx.com  /
  |             FitLinxx, Inc.            \  Phone: (203) 708-5192    |
 /  860 Canal Street, Stamford, CT  06902   \  Fax: (203) 316-5150     \
\-----------------------------------------------------------------------/