type checking

[sashan]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

 

[Jules Dubois]

On Sun, 12 Oct 2003 15:56:19 +1300, in article

[...] The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time.

Ask yourself how much static type-checking costs you versus how much
dynamic type errors cost you. If your answer demands static type-checking,
Python is not a good choice for you.

Any advice about
how to get around this would be appreciated.

Python, Smalltalk, and other languages are designed without static
type-checking. Getting around this kind of design decision can be
exceptionally difficult or impossible.

 

[Stephen Horne]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Personally, I find that I rarely make these errors in Python. Having
the right datatype is in any case no guarantee of having the right
value.

In Python, bugs are primarily avoided by writing clear code (so that
it is hard to make non-obvious errors) and detected by testing (which
is the only approach that checks whether the requirements are met).

There are also alternative self-consistency checking schemes such as
design-by-contract that may work well for you, though they do operate
at run time rather than compile time.

If you really do need static typing (as opposed to simply needing to
get used to the change), Python is simply the wrong choice of
language. Either Java, C# or Delphi may be a good option for you.

 

[Donn Cave]

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
....
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, (e-mail address removed)

 

[Terry Reedy]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time.

I am beginning to realize that different people probably have
different typo 'profiles', so that I missed typing checks less than I
'missed' writing type declarations (which are another opportunity for
error ;-).

With Python I have to wait for the error to appear at runtime in
order for me to correct it.

In my experience with small functions and programs, Python error
reports come about as fast or faster as C error reports did a decade
ago. Syntax
errors get reported at compile time for Python also.

I find this inefficient. Any advice about
how to get around this would be appreciated.

I suspect that people sometimes became dependent on the system they
use finding the errors it is good at finding, and become a bit
careless with respect to that type of error and focus proofreading on
others that that system is less good at finding. I probably worry
less about syntax errors with Python than I did with Fortran on
punched cards (and an hour or more of turnaround time).

Terry J. Reedy

 

[F. GEIGER]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Use pychecker for that. It really helps to find typos.

Cheers
Franz GEIGER

 

[Miki Tebeka]

Hello sashan,

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

I'll think you'll find dynamic typing saving you time. See
http://www.mindview.net/WebLog/log-0025 for more details.

pychecker does dome checking, but it can't find all the errors that a
statically typed language compiler will find.

IMO the best practice in dynamically typed language is to spend some
of the time you've saved on writing an extensive testing framework.
This will catch much more bugs (including logical ones) that no
compiler will ever catch. See PyUnit for a good framework.

HTH.
Miki

 

[sashan]

I am beginning to realize that different people probably have
different typo 'profiles', so that I missed typing checks less than I
'missed' writing type declarations (which are another opportunity for
error ;-).

I suppose that's one way of looking at it. At least I'm not having to
correct both the function signature in the header in implementation file.

I suspect that people sometimes became dependent on the system they
use finding the errors it is good at finding,

I think this is my situation at the moment.

 

[sashan]

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

Donn Cave, (e-mail address removed)

If it was practical I'd use OCaml or Haskell but they don't have the
external libraries I need.

 

[Alex Martelli]

If it was practical I'd use OCaml or Haskell but they don't have the
external libraries I need.

http://ocamlffi.sourceforge.net/

SWIG also suppors OCaml since 1.3.14 (haven't tried that out).


Alex

 

[Alex Martelli]

Quoth Stephen Horne <$$$$$$$$$$$$$$$$$@$$$$$$$$$$$$$$$$$$$$.co.uk>:
...
| If you really do need static typing (as opposed to simply needing to
| get used to the change), Python is simply the wrong choice of
| language. Either Java, C# or Delphi may be a good option for you.

Also consider functional languages with strong static typing and
type inference - Haskell, Clean, ML, Objective CAML. Even if they
eventually turn out to be unsuitable for the task at hand, they
offer an interesting and rigorous abstraction of computer programming.

I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python. The languages Donn
lists *DO* (well, I haven't actually tried out Clean, but it looks to me
as if it does). O'CAML in particular is multi-paradigm, a bit rambling, and
perhaps not with the most elegant syntax -- sort of like C++ in these
respects -- but, also like C++ (and Python) takes a LOT of care to
practically FIT IN with your need for solution (e.g. SWIG supports it
to ease interfacing external C=coded libraries). And the base paradigm
of O'CAML is statically typed (even too strict maybe, if you still have to
write +. instead of just + when you're summing floats...) AND very high
level (functional). Haskell is even more mind-expanding and much more
elegant, though perhaps its practicality is (sigh) lesser. Standard ML may
be a bit in-between, perhaps (don't know it as well as the others).

In the end, if you're REALLY keen for static typing you owe it to yourself
to try the real thing, rather than the semi-strict Java &c approaches. If
you're looking to learn, Haskell is hard to beat; if to get practical
solutions to problems, O'CAML may be better. Python is IMHO wonderful
if you DON'T make a fetish of static typing (you might want to try Erlang
for pure functional programming without static typing, btw).

Many of us who used to revere static typing (e.g., Robert Martin, well
noted consultant and author, former editor of C++Report) are on record
as having acknowledged that dynamic typing in fact works better for us.
It just took us a few years to realize this, and vast experience with both
kinds of languages.

If your mind is shaped differently from ours, so that static typing DOES
work better for you even after you've thoroughly familiarized yourself with
a good dynamic-typing language, then moving to a good static-typing
language may indeed be the best strategy for you -- and today's wealth
of choices means no practical restrictions need stop you from doing that.


Alex

 

[Stephen Horne]

I'd like to second Donn's recommendation and express reservations
on Stephen's. Java &c just don't have a high enough semantic level
to give you the same productivity as Python.

I suggested C# - _not_ C. That is a very different thing. C# is
probably slightly higher level than Java - though not in Pythons
league, of course.

I made the suggestions I did mostly because I know each of those
languages has a rich set of libraries available. I am far less certain
of the extent of the libraries for functional languages as on the
whole I've only played with them.

A good language can mean big gains, but not necessarily as big as
someone else having written key parts of your application for you in
the form of libraries - and testing them too.

So that, to me, is a key question - which (functional or other)
languages have the richest and most mature libraries (obviously
relevant to sashans requirements), and how do they compare to those
available in Python on the one hand, or Java, C# etc on the other.

An additional issue is familiarity - if sashan is having a hard time
adapting to Python, I suspect he'll find functional languages require
an even bigger paradigm shift. Java and C# require relatively few
mindset adjustments relative to C++.

 

[Carl Banks]

I'm a Python newbie. I have been using c++ for 5 years and before that I
was programming in Pascal. The one thing that annoys me about python
is dynamic typing because I find myself making typographical errors of
the sort that would under C++ be picked up by the compiler at compiler
time. With Python I have to wait for the error to appear at runtime in
order for me to correct it. I find this inefficient. Any advice about
how to get around this would be appreciated.

Sashan, it seems that what you are looking for is not static typing,
per se, but declarations. Here's an old post I made about a trick
where you can declare variables, and have the function throw an
exception if there are any undeclared locals:

http://tinyurl.com/qnmc

It does not declare types, but it catches typos. You might want to
use it to help you transition to Python. However, if you're still
using Python a few months from now (likely , I bet you'll have
adapted to Python's implicit variable declarations.


--
CARL BANKS http://www.aerojockey.com/software

As the newest Lady Turnpot descended into the kitchen wrapped only in
her celery-green dressing gown, her creamy bosom rising and falling
like a temperamental souffle, her tart mouth pursed in distaste, the
sous-chef whispered to the scullery boy, "I don't know what to make of
her."
--Laurel Fortuner, Montendre, France
1992 Bulwer-Lytton Fiction Contest Winner

 

[Alex Martelli]

Stephen Horne wrote:
...

I suggested C# - _not_ C. That is a very different thing. C# is

Sure. "&c" stands for "etc", in this context "and all the others [which
you had mentioned]".

A good language can mean big gains, but not necessarily as big as
someone else having written key parts of your application for you in
the form of libraries - and testing them too.

Definitely. But SWIG often helps a lot -- if the library's around for C,
it's not far from your favourite SWIG-supported language.

An additional issue is familiarity - if sashan is having a hard time
adapting to Python, I suspect he'll find functional languages require
an even bigger paradigm shift. Java and C# require relatively few
mindset adjustments relative to C++.

True, they're closer to C++ in many respects than Python is (except
that Python, like C++, is multi-paradigm, has multiple inheritance,
allows operator overloading, lets you pick and choose among GUI
toolkits rather than coming with one, etc -- but probably not the kinds
of things one will have most "mindset adjustments" about).

By the same token, Java and C# will give few benefits if you already
master C++ -- perhaps a little help with memory management to be
offset against losing templates, a HUGE loss to adjust to, and such
niceties as the "resource allocation is construction" idiom. If one
masters C++ and is looking for productivity higher enough to matter,
Python (or other similar VHLLs) and FP languages are much more
likely to produce it than Java or C# are.


Alex

 

[Anand Pillai]

I consider Python as high-level psuedo-code. It helps me in
programming, since you dont make mistakes while writing
psuedo-code. So it follows by induction that you dont make
these mistakes like static type errors while programming python.

It is a different approach, by altering your thinking, rather
than relying on tools. Works for me ;-)

Write python program as you would write a flow chart or psuedo-code.
The language constructs are so damn intuitive that it allows you
the freedom to do so.

In the second iteration you can do type checking by perhaps
using the built-in 'type' meta call.


-Anand

 

[Stephen Horne]

I consider Python as high-level psuedo-code. It helps me in
programming, since you dont make mistakes while writing
psuedo-code. So it follows by induction that you dont make
these mistakes like static type errors while programming python.

It is a different approach, by altering your thinking, rather
than relying on tools. Works for me ;-)

While I agree that most likely sashan needs a change of mindset rather
than a language with static typing, this is an unrealistically
impressive claim.

There is no context where I do not sometimes make mistakes, including
pseudocode.

Of course errors do tend to be much rarer in Python, mainly because I
am concentrating on the program logic, rather than being distracted by
the overheads of the language.

 

[Stephen Horne]

Stephen Horne wrote:
...

I suggested C# - _not_ C. That is a very different thing. C# is

Sure. "&c" stands for "etc", in this context "and all the others [which
you had mentioned]".

Sorry - I wasn't aware of that abbreviation.

Definitely. But SWIG often helps a lot -- if the library's around for C,
it's not far from your favourite SWIG-supported language.

Good point. Having heard of but never used SWIG, it's not something
that I had considered.

By the same token, Java and C# will give few benefits if you already
master C++ -- perhaps a little help with memory management to be
offset against losing templates, a HUGE loss to adjust to, and such
niceties as the "resource allocation is construction" idiom.

Yes, that is very true. I believe MS are adding generics to C#, but
with such big changes being planned that just rubs in the fact that C#
is an immature language resting on an immature library.

I had assumed that the "resource allocation is construction" idiom
could be applied in any language with both constructors and
exceptions. There are only two issues that I can think of that would
seriously affect it...

1. If the language still tries to call a destructor for an object
when its constructor raised an exception.

2. The lack of automatic destruction of member and base components of
an object if a later part of the objects constuctor propogates an
exception.

3. If the libraries do not consistently apply the idiom.

I assume it's mainly the second and third part where this is an issue.

It hasn't really been an issue so far, but I guess C# constructors
should be written so that they never propogate an exception - the
object should always be constructed in a self-consistent state even if
that state flags an error. Which immediately defeats the whole point
of exceptions.

I guess this might be less serious in a language with full garbage
collection - member fields which were initialised will still get
garbage collected, for instance, and any resources they reference will
get freed when that happens. But that seems like a dangerous system to
rely on. For instance, what happens if you need to access one of those
resources before the GC frees it.

This is one issue I already have with Java/C# style garbage collection
- if you need to ensure that resources are available when needed, you
still end up doing explicit 'deletes' anyway. Fortunately, it's only
in this particular case when that becomes impossible.

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

Hmmm - a thought provoking issue. Thanks for pointing it out.

 

[Alex Martelli]

Stephen Horne wrote:
...

Yes, that is very true. I believe MS are adding generics to C#, but

Generics are also coming in Java (I've lost track of the # of times
i've heard them announced as imminent over the last few years, but
surely ONE of these times it will be true.

with such big changes being planned that just rubs in the fact that C#
is an immature language resting on an immature library.

Can't say that of Java, yet "generics are coming" applies to both.

I had assumed that the "resource allocation is construction" idiom
could be applied in any language with both constructors and
exceptions. There are only two issues that I can think of that would
seriously affect it...

[then listing 3 of them -- nobody expects the spanish inquisition!-)]

4. the destructor is called when it happens to be called, including
perhaps never if the garbage collector never needs to reclaim
_memory_, which is the only resource it directly tracks

C++'s idiom depends on destruction happening _at once_ for
automatic variables going out of scope:

// some preliminaries executed w/o holding the lock
{
LockHolder holder(thelock);

// the guts, executed while holding the lock
}

with LockHolder's ctor calling the acquire, and its dtor the
release, for the lock being held; making the whole idiom roughly
equivalent to, but handier than, Java's or Python's try/finally.

If holder's destructor is liable to be called hours later when
the GC needs it to recover a little memory, the idiom is no use.

rely on. For instance, what happens if you need to access one of those
resources before the GC frees it.
Exactly.

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

Yes, they do (delay the GC, and perhaps delay it indefinitely, since,
in particular, reference loops including objects with __del__ are NOT
unraveled -- the GC punts on the need to call the __del__'s in some
order it cannot possibly infer).

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees. So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).

Hmmm - a thought provoking issue. Thanks for pointing it out.

You're welcome!


Alex

 

[Michael Hudson]

In Python, it doesn't seem to be an issue - presumably because Pythons
garbage collection is based on reference counting so destruction
happens immediately when the last reference has gone. I'm not sure
what happens when there are reference cycles, though - I know Python
handles them, but I'm not sure if they delay the garbage collection.

They do. By how much, well, depends.

Cheers,
mwh

 

[Stephen Horne]

The "immediate destruction when last reference gone" is an implementation
specific detail of CPython -- handy, but there's quite a price paid for
it, so the _language_ makes no guarantees. So you have try/finally for
those cases where you NEED guarantees (not as handy, admittedly).

Ah - I think I've just had one of those subtle but important paradigm
shifts. Resource management (for resources other than memory) simply
rests on slightly different language mechanisms in Python and Java
than it does in C++.

Oddly enough, I think my Python code has reflected this for some time
without me noticing the issue.