Conventions and static typing

0 views
Skip to first unread message

ulkis

unread,
May 3, 2003, 6:26:33 AM5/3/03
to
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).

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.

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

So what do you people think of this. Am I the only one that see this
as a problem? Any suggestions for solutions?

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.

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?

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?


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.

"Martin v. Löwis"

unread,
May 3, 2003, 9:41:20 AM5/3/03
to
ulkis wrote:
> 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).

I agree mostly. There are some common errors that with "static typing"
are detected by the compiler, in particular typos. For Python, pychecker
can detect a lot of these errors.

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

[...]


> The alternative, which is the only one I know of when it comes to
> Python, is to have the documentation handy.

This is only because the Python IDEs are not that far advanced. A number
of these IDEs, in particular PythonWin, provide the very same features.
How? do I hear you ask. With guessing. PythonWin guesses right
surprisingly often. I think even more can be done if somebody would put
some effort into the IDEs.

> So what do you people think of this. Am I the only one that see this
> as a problem? Any suggestions for solutions?

Improving the tools would require hard work, but I think it would be
worth it. Essentially, the tool needs to guess what a variable is likely
assigned to. If it is a global variable, you often have some assignment
early on, and perhaps a global statement somewhere; you rarely have
cross-module assignments. For classes, you typically have the member
assignment in the class, and the object is typically called "self".
With such heuristics, I'm sure, a tool could be quite helpful.

For "life" objects, in the interactive mode, this already works
quite well.

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

Python is so powerful it that tools don't need conventions. Instead,
they can learn a lot from introspection, and show doc strings to the
users. There are a few docstring conventions, e.g. Guido wants all
docstrings to have the signature completely in the first line, so that
IDEs can use that as a tooltip.

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

Tools do parse doc strings, and introspection helps them finding the
precise names of the parameters. Displaying the parameter names to the
user is often more helpful than displaying the parameter types.

Regards,
Martin

Steve Holden

unread,
May 3, 2003, 3:32:06 PM5/3/03
to
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_...@hotmail.com> wrote in message
news:ace7b0c2.03050...@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:m...@lemburg.com
Copyright (c) 2000-2002, eGenix.com Software GmbH;
mailto:in...@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/

Lulu of the Lotus-Eaters

unread,
May 3, 2003, 10:02:57 PM5/3/03
to
ulkis_...@hotmail.com (ulkis) wrote previously:

|static typing is as marginally useful and incomplete for error removal,
|as DTD:s are for validating the contents of an XML doc...

I'll come to the defense of DTDs here... I agree on static typing.

DTDs do precisely what they were intended to do, and do it extremely
well. In their SGML roots, DTDs are about specifying the layout of
DOCUMENTS. XML, on the other hand, has a split personality, both prose
documents and data-oriented tables/trees.

If you expect a DTD to guarantee for you that cell one and cell two
contain numbers, and cell three contains the average of the two, you'll
be out of luck. It is in answer to such an abuse of XML as a
make-believe RDBMS that abominations like W3C XML Schemas were invented.
Of course, W3C Schemas only wind up going a tiny step towards solving
the problem they aim at, and cause more problems than solutions (RELAX
NG is much nicer, but is again not really data-oriented).

However, if you want a book, or an article, or some other document, to
contain a specific set of contents, a DTD can specify quite precisely
and concisely what is needed. Moreover, if you can guarantee an XML
document conforms to a known DTD, it is amazingly simple to write a
conversion/processing application that will deal correctly with EVERY
instance of a valid document. Mind you, the DTD won't guarantee the
quality of the prose, or the accuracy of the information... but that's
not its goal. A DTD *will* tell you that something is a genuine
"article" according to the elements you need for a particular forum.

Yours, Lulu...

--
Keeping medicines from the bloodstreams of the sick; food from the bellies
of the hungry; books from the hands of the uneducated; technology from the
underdeveloped; and putting advocates of freedom in prisons. Intellectual
property is to the 21st century what the slave trade was to the 16th.

Steven Taschuk

unread,
May 5, 2003, 2:39:12 PM5/5/03
to
Quoth 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.

Is that supposed to be a joke?

--
Steven Taschuk stas...@telusplanet.net
"I tried to be pleasant and accommodating, but my head
began to hurt from his banality." -- _Seven_ (1996)

Peter Hansen

unread,
May 5, 2003, 6:38:32 PM5/5/03
to
Steven Taschuk wrote:
>
> Quoth 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.
>
> Is that supposed to be a joke?

Was this supposed to be sarcasm?

;-)

Reply all
Reply to author
Forward
0 new messages