Conventions and static typing

[Steve Holden]

WARNING: contains sarcasm not really intended as anything other than
humorous. I wouldn't mention it, except there's evidence that my sarcasm has
inadvertently and unintentionally offended people in the past.

"ulkis" <ulkis_blaffa at hotmail.com> wrote in message
news:ace7b0c2.0305030226.1fe91fd6 at posting.google.com...
> I've been using Python for about a year, and I really like it.
> However, there are a few of issues that bother me, and I'd like to
> hear how other people look at, solve or work around them. I may not be
> all that good at analyzing things, but here goes:
>
> I think it all boils down to the dynamic typing of Python. Until a
> couple of weeks ago I had never written a unit test, and believed that
> static typing was a good help for reducing errors. After writing and
> executing a couple of tests, that idea was crushed, as I realized that
> static typing is as marginally useful and incomplete for error
> removal, as DTD:s are for validating the contents of an XML doc (an
> old pet peeve of mine).
>
Good: coming to Python without static typing prejudice, or losing it
early on in your Python programming experience, will make your
program structures more dynamic and therefore easier to adapt for
related purposes.

> But I know of at least one area where static typing is of great help,
> and that is development tools. Anyone who has used Visual Studio,
> JBuilder, Forte for Java, or any other reasonably modern Java or C++
> IDE, knows how comfortable it is to have a list of available
> parameters, members or other symbols, as well as documentation,
> popping up automatically or at a keypress when typing source code. For
> someone like me, with an almost diseasely bad memory, this is a great
> aid. Due to the nature of Python (afaik), it would be very difficult
> to make an IDE with such a feature working.
>
Well, the code is supposed to be self-documenting, and that is true to
a greater or lesser extent for the Python code in the Python core. Other
authors' practices vary. My own are abominable. Whoever wrote "sys"
was good:

""">>> print sys.__doc__
This module provides access to some objects used or maintained by the
interpreter and to functions that interact strongly with the interpreter.

Dynamic objects:

argv -- command line arguments; argv[0] is the script pathname if known
path -- module search path; path[0] is the script directory, else ''
modules -- dictionary of loaded modules

[...44 more lines of useful output...]

Functions:

displayhook() -- print an object to the screen, and save it in __builtin__._
excepthook() -- print an exception and its traceback to sys.stderr
exc_info() -- return thread-safe information about the current exception
exit() -- exit the interpreter by raising SystemExit
getdlopenflags() -- returns flags to be used for dlopen() calls
getrefcount() -- return the reference count for an object (plus one :-)
getrecursionlimit() -- return the max recursion depth for the interpreter
setcheckinterval() -- control how often the interpreter checks for events
setdlopenflags() -- set the flags to be used for dlopen() calls
setprofile() -- set the global profiling function
setrecursionlimit() -- set the max recursion depth for the interpreter
settrace() -- set the global debug tracing function"""

That's actually not bad. It takes the usual Microsoft document about thirty
pages to say (their equivalent of) that much about the software they are
trying to describe. But don't get me started on that, the old warhorse is
getting considerably better of late.

Sadly, the same cannot be said of Twisted, for example:

""">>> import twisted
>>> twisted.__doc__
'\nTwisted: The Framework Of Your Internet.\n'
>>>"""

If I didn't know better (and, as it happens, I don't know *very* much
better) I might imagine that documentation wasn't going to be this
particular package's strong point. Eventually I might have something to say
about the Twisted philosophy, but right now I just plain need to learn more
about it. We can compare that with other installed products, of course
[readers: follow right along at home, seeing what the __doc__ string of
various modules looks like]. Good grief, how will these people ever achieve
world domination?

""">>> import mx.ODBC.Windows as db
>>> print db.__doc__
 Generic ODBC interface

    Use this subpackage as template for new subpackages.

    Copyright (c) 2000, Marc-Andre Lemburg; mailto:mal at lemburg.com
    Copyright (c) 2000-2002, eGenix.com Software GmbH;
mailto:info at egenix.com
    See the documentation for further information on copyrights,
    or contact the author. All Rights Reserved."""

Clearly something commercial going on here: an accurate impression, since
this code requires a license for commercial (broadly, non-personal) use even
though it is maintained as an open source product. Its programming practices
(in so far as I am quaified to judge) seem to indicate a more-than-moderate
degree of competence in its construction.

""">>> import MySQLdb as db
>>> print db.__doc__
MySQLdb - A DB API v2.0 compatible interface to MySQL.

This package is a wrapper around _mysql, which mostly implements the
MySQL C API.

connect() -- connects to server

See the C API specification and the MySQL documentation for more info
on other items.

For information on how MySQLdb handles type conversion, see the
MySQLdb.converters module."""

Again some moderately clueful information that warns me something might well
be importing _mysql, probably a DLL. I've actually poked about a bit in the
installer code for mxODBC and MySQLdb and know they are both workmanlike
open source products.

> The alternative, which is the only one I know of when it comes to
> Python, is to have the documentation handy. This is usually not a
> problem, except that it often takes a lot more clicking or
> button-pressing to find what you want. Also, this requires that the
> documentation is good in content and format, which is not my
> experience with Python-related 3:rd party libraries (e.g. Twisted,
> wxPython, PyGame, pymqi).
>
The idea is to have the documentation handy all the time, in as many
different forms as possible. I quite like the Windows help file format, but
for now find HTML most portable (the PDF is quite good typographically, but
a bit much for anything lower-res than 1600 x 1200.

It's likely your Python is recent enough to do this:

""">>> import sys
>>> help(sys)"""

[Window turns into "more"-like display of what appears to be Unix-style man
page about the godd 'ole Python sys module, containing pretty much what was
quoted above].

hitting the "q" key returns you to the interactive prompt.


> So what do you people think of this. Am I the only one that see this
> as a problem? Any suggestions for solutions?
>
Sheesh, dude, how much handier can you *want* the documentation. You want
the function to cut in when you just *think* about reading the docs.

You might argue that this is difficult to find, but I would disagree:

""">>> help
Type help() for interactive help, or help(object) for help about object.
>>>"""

> Another point is, I belive, more related to convention than static
> typing. When it comes to reusable components, Java has beans, and
> Windows has OCX. A nice feature is that they have conventions for
> exposing interface definitions that enable tools to interface to them
> without knowing about them in advance. I am not aware of any such
> conventions for Python, and introspection cannot (afaik) tell you much
> about the parameters since what you may have, at best, is a default
> value with a type, and in worst case **kwargs.
>
There has been a lot of discussion about how interfaces might be integrated
into the core, including a model proof-of-concept implementation by Alex
Martelli that I haven't played with. Interfaces are apparently making it
into Zope 3, so who knows. At least there'll be an interface-based
component-based architecture to play with, with luck.

Until then one is "restricted" (if you regard this as restrictive) to
writing generally polymorphic code, where if your object provides a
"file-like" interface there's a good chance most other things you use will
be able to use it just like a file. Unless it's not sufficiently file-like.

> I have only used it very little, so this is just a guess, but doesn't
> Boa constructor require built-in support for every kind of widget or
> other component presented? So if I build a new widget, I can't just
> add it to the palette and use it?
>
This kind of extensibility isn't common, I believe, in the graphical
toolsets available, though I know that Rowland Smith is looking at dynamic
component creation for PythonCard. I have personal interests in people being
able to put together Windows-based applications quickly and effectively, and
PythonCard looks like the best chance for that right now.
 Speaking of which:

""">>> import PythonCardPrototype
>>> print PythonCardPrototype.__doc__

Created: 2001/08/05
Purpose: Turn PythonCard into a package

__version__ = "$Revision: 1.1.1.1 $"
__date__ = "$Date: 2001/08/06 19:53:11 $""""

> So once again, what do you think? If this is possible, then I just
> have an ignorance gap to fill, which I look forward to. If not, should
> it be, or should I change my way of thinking?
>
Well, now you've read this, you tell me the answer.
>
> While a little longer that I had wished, I hope that this isn't taken
> as a rant or troll - I am sincerely curious and want to make my Python
> experience even more comfortable

Fortunately Python appears to encourage tranquil and comfortable approaches
to programming. I hope you enjoy your time as a Python programmer.

regards
--
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/