"no variable or argument declarations are necessary."

[James A. Donald]

I am contemplating getting into Python, which is used by engineers I
admire - google and Bram Cohen, but was horrified to read

"no variable or argument declarations are necessary."

Surely that means that if I misspell a variable name, my program will
mysteriously fail to work with no error message.

If you don't declare variables, you can inadvertently re-use an
variable used in an enclosing context when you don't intend to, or
inadvertently reference a new variable (a typo) when you intended to
reference an existing variable.

What can one do to swiftly detect this type of bug?
--
http://www.jim.com

[Paul Rubin]

Steve Holden <st***@holdenweb.com> writes:

In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you want to call it will suffer from the same
shortcomings that C++ and java do, which is to say type checking can't
possibly do anything useful when the acceptable type of a reference is
specified as ANY.

Let's see if I understand what you're saying:

C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:

Python: where you get no useful type checking at all.

That is not very convincing logic.

[Steve Holden]

Paul Rubin wrote:

Steve Holden <st***@holdenweb.com> writes:

In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you want to call it will suffer from the same
shortcomings that C++ and java do, which is to say type checking can't
possibly do anything useful when the acceptable type of a reference is
specified as ANY.

Let's see if I understand what you're saying:

C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:

Python: where you get no useful type checking at all.

That is not very convincing logic.

As we say in Yorkshire, "There's none as thick as them that wants to
be". Let's try to get this in context.

Antoon: Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix all kind of type in a particular list, just
as python does.
Diez: The you have JAVA Object or C void*. Which cause all kinds of runtime
troubles.... because they essentially circumvene the typechecking!
Antoon: Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should it acquire a type system.
Me: Diez' intention seemed fairly clear
to me: he is pointing out that strongly-typed systems invariably fall
back on generic declarations when they want to allow objects of any type
(which, it seems to me, is what you were proposing as well).
You: C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:

Python: where you get no useful type checking at all.

The points that have repeatedly been made are:

1. That even the strict typings required by languages like Java and C++
actually end up getting in the way when the pragmatic requirements of
real-world problems have to be taken into account.

2. That the benefits of declarations are overstated by many of their
proponents.

3. That Python as it is today allows the dynamic creation of names,
which are therefore inherently not available for declaration.

On existing evidence it's extremely unlikely that this post will end the
thread, but I certainly wish *something* would. Unfortunately I seem to
have become part of the problem in that respect :-)

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Diez B. Roggisch]

> Why do you call this a JAVA Object or C void*? Why don't you call

it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should it acquire a type system.

Well, because maybe I wanted you to give you an example of languages
that are statically typed and have such an any construct - that, by the
way, is not a piece of inguine imagination of yours, but has been
thought of before, e.g. CORBA (and called there any, too)? It makes no
sense putting python into that context - as it is _not_ statically
typed. Which you should know, after discussing this very subject way too
long.

Would my suggestion be classified as a statically typed world?

See above.

Your answer tells more about you then about my suggestion.

Your answer tells us something too: Just because you don't know anything
about typechecking does not mean that you are in the position to make
assumptions on "how things could work if the people who know stuff
wouldn't be so stupid". That's like saying "cars can't fly because the
stupid engineers lack my sense of imagination."

Just blathering about the possibility of some super-duper-typechecker
and countering criticism or being told about problems in that domain by
making bold statements that this sure could work - provide us with an
implementation.

Or maybe - just maybe - you could sit back and think about the fact that
lots of people who are way cleverer than you and me have been working on
this subject, and so far haven't found a way. Which doesn't necessarily
mean that there is no way - but certainly its hard, theory-laden work
and won't emerge in a NG discussion by some snide remarks of either you
or anybody else.
Diez

[Diez B. Roggisch]

Paul Rubin wrote:

Steve Holden <st***@holdenweb.com> writes:

In other words, you want Python to be strongly-typed, but sometimes
you want to allow a reference to be to any object whatsoever. In which
case you can't possibly do any sensible type-checking on it, so this
new Python+ or whatever you want to call it will suffer from the same
shortcomings that C++ and java do, which is to say type checking can't
possibly do anything useful when the acceptable type of a reference is
specified as ANY.

Let's see if I understand what you're saying:

C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:

Python: where you get no useful type checking at all.

That is not very convincing logic.

No, he said that this typechecking wouldn't make sense in the case of
ANY being used. And the plethorea of ClassCastExceptions and Segfault
proves the point :)

Diez

[Ben Sizer]

Paul Rubin wrote:

Let's see if I understand what you're saying:

C and Java: you get useful type checking except when you declare
a reference as type ANY. This is a shortcoming compared to:

Python: where you get no useful type checking at all.

That is not very convincing logic.

It's started to get very misleading - Python gives you plenty of
type-checking, as we all know, just not at compile-time. Also comparing
Python to C/Java as you have done is not very appropriate unless you
want Python to have the same sort of compile times as C and Java do.

I think you're doing a small disservice to respond to Steve when not
acknowledging the context of the thread, where Diez was explaining that
the system used in ML would not work in Python, then Antoon made a
suggestion that would fix that particular problem but make others
worse.

I'm not convinced that the Java route - where you type out lengthy type
declarations to get some compile-time typechecking which you usually
end up having to bypass later anyway - is at all beneficial, at least
not in the context of Python. I can't ever remember a time when I
thought "type checking really saved me from a bug there" when using
C/C++/Java, but I _can_ remember many times where I've had to consider
which cast or conversion to use, or had to write another overloaded
function to accommodate a similar-but-different type, or debug a
complex template message, or add a superfluous base class or interface,
all just to get the kind of genericity that Python gives for free. And
it's no good saying that variable declarations will be optional,
because as soon as these statically-typed variables enter the standard
library, every Python programmer will have to take these considerations
on board when writing their code, whether we want to use them or not.

--
Ben Sizer

[Roy Smith]

"Ben Sizer" <ky*****@gmail.com> wrote:

It's started to get very misleading - Python gives you plenty of
type-checking, as we all know, just not at compile-time.

There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as possible. One might
call it just-in-time type checking.

It's not hard to imagine a Python-like language which included (perhaps
optional) variable declarations. A declaration would essentially be an
assertion which was checked after each assignment to that name. So, you
could write:

int i = 5
i = 5.6

and the second statement would throw TypeError. This would give you
C++/Java style type safety, but it still wouldn't be compile time.

Perhaps a better way to describe it is that the checking isn't an is-a
assertion, but an acts-like assertion (sort of like Java's interfaces). To
take an example, in the function:

def first3(y):
if len(y) < 3:
return y
return y[0:3]

all I really need from the argument is that I can call len() on it and it
can be sliced. An easy way to describe this would be to say that y must be
a sequence, but that's not strictly accurate, since I can easily declare my
own class which meets those requirements without being a subclass of
sequence (even ignoring for the moment that 'sequence', while talked about
in the documentation, doesn't actually exist as something you can subclass).

[Antoon Pardon]

Op 2005-10-07, Steve Holden schreef <st***@holdenweb.com>:

Antoon Pardon wrote:

Op 2005-10-06, Diez B. Roggisch schreef <de***@nospam.web.de>:

Suppose we have a typesystem which has the type ANY, which would mean
such an object could be any type. You could then have homogenous lists
in the sense that all elements should be of the same declared type and
at the same time mix all kind of type in a particular list, just
as python does.

The you have JAVA Object or C void*. Which cause all kinds of runtime
troubles.... because they essentially circumvene the typechecking!

Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should it acquire a type system.

[sigh]. No, it's just you being you. Diez' intention seemed fairly clear
to me: he is pointing out that strongly-typed systems invariably fall
back on generic declarations when they want to allow objects of any type
(which, it seems to me, is what you were proposing as well).

It is not about falling back on generic declarartion, it is about
how such object will be treated. Diez seems to think that
strongly-typed language can only deal with generic declarations
by using something that allows circumventing the type system.
In other words, you want Python to be strongly-typed, but sometimes you
want to allow a reference to be to any object whatsoever. In which case
you can't possibly do any sensible type-checking on it, so this new
Python+ or whatever you want to call it will suffer from the same
shortcomings that C++ and java do, which is to say type checking can't
possibly do anything useful when the acceptable type of a reference is
specified as ANY.

And you are wrong. The problem with the C void* construct (I'm not that
familiar with java) is that all type information is lost. When you
use such a parameter in a function you have no idea what you are
working with.

But that doesn't need to be if you have a typesystem with an ANY type.
Such a type declaration would mean that object of any type could be
used here. However that doesn't imply that the type information
of the actual objects used, has to be lost. That type information
may still be available and usefull for further type checking.

That you and Diez can only think about C, C++ or java constructs
when I mention an ANY type, is your limitation. It doesn't
need to be the limitation of a specific type system.

--
Antoon Pardon

[Steven D'Aprano]

On Fri, 07 Oct 2005 06:01:00 -0400, Roy Smith wrote:

There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as possible. One might
call it just-in-time type checking.

Well there you go then. Instead of pulling our hair out that Python has no
type checking ("that's a bug in the language design, woe woe woe!!!") we
can just say that Python does JIT type checking, which not only is a
feature, but also satisfies the Pointy Haired Bosses who demand buzzwords
they can't understand.

--
Steven.

[Christophe]

Roy Smith a écrit :

There's more to it than just that. Python's type checking is not just not
done at compile time, it's done as late in run time as possible. One might
call it just-in-time type checking.

It's more of a "Nearly too late" type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.

[Antoon Pardon]

Op 2005-10-07, Diez B. Roggisch schreef <de***@nospam.web.de>:

Why do you call this a JAVA Object or C void*? Why don't you call
it a PYTHON object. It is this kind of reaction that IMO tells most
opponents can't think outside the typesystems they have already
seen and project the problems with those type systems on what
would happen with python should it acquire a type system.
Well, because maybe I wanted you to give you an example of languages
that are statically typed and have such an any construct

But since I have no such type system in mind, such an example is useless.
- that, by the
way, is not a piece of inguine imagination of yours, but has been
thought of before, e.g. CORBA (and called there any, too)? It makes no
sense putting python into that context - as it is _not_ statically
typed. Which you should know, after discussing this very subject way too
long.
The fact that something else uses the same name, for something
doesn't mean it has to be implemented the same way.

Would my suggestion be classified as a statically typed world?

See above.

Your answer tells more about you then about my suggestion.

Your answer tells us something too: Just because you don't know anything
about typechecking does not mean that you are in the position to make
assumptions on "how things could work if the people who know stuff
wouldn't be so stupid". That's like saying "cars can't fly because the
stupid engineers lack my sense of imagination."

Then argue against my ideas, and not your makings of it.

If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not against what I have in mind.

It may very well turn out that my idea is useless, but I will
only accept that when someone comes with arguments against
my actual idea, and not with arguements against their projection
of it.
Just blathering about the possibility of some super-duper-typechecker
and countering criticism or being told about problems in that domain by
making bold statements that this sure could work - provide us with an
implementation.
You have not counterd my idea with criticism. You have decorated my
idea with how you think it would be implemented (C void*) and argued
against that. I don't need to give an implementation to notice, that
you jumped to a particular implementation and basicly just countered
that implementation, not the idea in general.
Or maybe - just maybe - you could sit back and think about the fact that
lots of people who are way cleverer than you and me have been working on
this subject, and so far haven't found a way. Which doesn't necessarily
mean that there is no way - but certainly its hard, theory-laden work
and won't emerge in a NG discussion by some snide remarks of either you
or anybody else.

As far as I'm concerned that was just meant as a matter of fact remark,
with no snide intentions.

--
Antoon Pardon

[Fredrik Lundh]

"Christophe" wrote:

It's more of a "Nearly too late" type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.

use assert as the soonest possible point. implementing "type gates" is
trivial, if you think you need them.

</F>

[mg]

Hello,

In a recursive function like the following :
def foo( j ) :
j += 1
while j < n : j = foo( j )
return j
in found that the recursivity is limited (1000 iterations). Then, I have
two questions :
- why this mecanism has been implemented ?
- it is possible to increase or remove (and how) the number of iterations ?

Regards,
Mathieu

[Christophe]

Fredrik Lundh a écrit :

"Christophe" wrote:

It's more of a "Nearly too late" type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.

use assert as the soonest possible point. implementing "type gates" is
trivial, if you think you need them.

Still, it would be great if there were also some automatic type checking
in place. Using assert is hardly automatic and non intrusive.

I mean, why not ? Why does the compiler let me do that when you know
perfectly that that code is incorrect :
def f():
return "a" + 5

Of course the system can't be perfect but it doesn't need to be. It
doesn't need to constrain us in any way but if it can detect some errors
early, then it is worth it.

[Juho Schultz]

mg wrote:

Hello,

In a recursive function like the following :
def foo( j ) :
j += 1
while j < n : j = foo( j )
return j
in found that the recursivity is limited (1000 iterations). Then, I have
two questions :
- why this mecanism has been implemented ?
- it is possible to increase or remove (and how) the number of iterations ?

Regards,
Mathieu

Try the following for answers to both questions:

import sys
print sys.setrecursionlimit.__doc__

I guess 1000 is the default value.

[Brandon K]

Is there no way to implement your idea in a classical loop? Usually the
syntax is cleaner, and there is no limit (except the limit of the range
function in certain cases). For example what would be wrong with.

def foo(j):
while j < n:
j+=1
return j

I don't know much about the internals of python, but to me it seems like
if you're going to be doing this on the level of 1000s of iterations,
there might be some overhead to using recursion (i.e. function calls)
that a loop wouldn't have (but that's just a guess).

Hello,

In a recursive function like the following :
def foo( j ) :
j += 1
while j < n : j = foo( j )
return j
in found that the recursivity is limited (1000 iterations). Then, I have
two questions :
- why this mecanism has been implemented ?
- it is possible to increase or remove (and how) the number of iterations ?

Regards,
Mathieu

----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

[Brandon K]

def foo(j):
while j < n:
j+=1
return j

of course I mean:
def foo(j):
while j < n:
j+=1
return j

sorry
----== Posted via Newsgroups.com - Usenet Access to over 100,000 Newsgroups ==----
Get Anonymous, Uncensored, Access to West and East Coast Server Farms!
----== Highest Retention and Completion Rates! HTTP://WWW.NEWSGROUPS.COM ==----

[Paul Rubin]

"Fredrik Lundh" <fr*****@pythonware.com> writes:

use assert as the soonest possible point. implementing "type gates" is
trivial, if you think you need them.

What this is about (to me at least) is the edit-debug cycle. Let's
say I write some Python code, using assert to validate datatypes.
Maybe I've made 4 errors. I then write a test function and run it.
Boom, the first assert fails. I fix the first error, run again.
Boom, the next assert fails. Fix the next error, run again, boom,
fix, etc. Four edit-debug cycles.

With static typing, I run the compiler, get 4 error messages, fix all
4, and can get on with the next phase of testing with three fewer edit
cycles. That's a definite benefit of languages like Java. It's not
imaginary. Unit tests on Python code don't make it go away. I have
less Java experience than Python experience by now, but I still find
that Java programs take me fewer iterations to get working than Python
programs. The trouble is that Java has a thousand deficiencies that
outweigh that particular benefit, so overall I like Python a lot
better anyway.

Now some of the Python-is-perfect crowd seems to suffer from a "Blub
paradox" (http://c2.com/cgi/wiki?BlubParadox). They see annoying,
static typed languages like C and Java, and they see pleasant,
dynamically typed languages like Python, and conclude that static
types = annoying, when in fact they can be orthogonal. So, can there
be a language that's both statically typed, and pleasant? I haven't
used one yet, but lately I've been reading about Haskell and want to
give it a try. I keep finding statements like:

To me, Haskell is what Python should have evolved to. As a long-time
Python programmer, I have been very, very pleased with Haskell and am
currently working on porting my code to it (and write new code in
Haskell at every opportunity).
(http://supybot.com/Members/jemfinch/.../document_view)

or:

Using Haskell to develop OpenAFP.hs led to programs that eat constant
2MB memory, scale linearly, and are generally 2OOM faster than my Perl
library.

Oh, and the code size is 1/10.
(http://www.perl.com/pub/a/2005/03/03...interview.html -
Autrijus also raves about how great the book "Types and
Programming Languages" supposedly is--I'm trying to borrow
a copy. Yeah, this is a Perl comparison, but I think of
Perl as being roughly equivalent to Python except a lot uglier).

or:

Haskell is the least-broken programming language available today. C,
C++, Perl, Python, Java, and all the other languages you've heard of
are all much more broken, so debating their merits is pointless. :-)
Unfortunately Real Life involves dealing with brokenness.
(http://www106.pair.com/rhp/books.html)

or:

In conducting the independent design review at Intermetrics, there
was a significant sense of disbelief. We quote from [CHJ93]: "It
is significant that Mr. Domanski, Mr. Banowetz and Dr. Brosgol
were all surprised and suspicious when we told them that Haskell
prototype P1 (see appendix B) is a complete tested executable
program. We provided them with a copy of P1 without explaining
that it was a program, and based on preconceptions from their past
experience, they had studied P1 under the assumption that it was a
mixture of requirements specification and top level design. They
were convinced it was incomplete because it did not address issues
such as data structure design and execution order."
(http://haskell.org/papers/NSWC/jfp.ps - this was from a bake-off
for a military application where the Haskell solution had 85 lines
of code to Ada's 767, C++'s 1105, and Relational Lisp's 274).

Obviously I'm in the usual rose-colored-glasses phase of finding out
about something new and interesting, but I can't help thinking these
guys are onto something. Quite a few of the Haskell Cafe mailing list
members seem to have come to Haskell from Python. (Haskell tutorial:
http://www.isi.edu/~hdaume/htut/ - I've read most of this and it looks
pretty cool--definitely a steeper learning curve than Python but the
result looks a lot more powerful).

[Diez B. Roggisch]

Antoon Pardon wrote:

Then argue against my ideas, and not your makings of it.

If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not against what I have in mind.
Well, you didn't tell us what you had in mind. You just said "let's
introduce something like any". I showed you existing implementations of
such a concept that have problems. You say "thats not what _I_ have in
mind, so your criticism doesn't apply." Guess what, I can't read your
mind. But you did not tell me in what your idea is different from
existing concepts.
You have not counterd my idea with criticism. You have decorated my
idea with how you think it would be implemented (C void*) and argued
against that. I don't need to give an implementation to notice, that
you jumped to a particular implementation and basicly just countered
that implementation, not the idea in general.
Again - where is your idea layed out in (more) detail, so that one can
discuss them? That was all that I'm asking - which of course you
carefully avoided...
As far as I'm concerned that was just meant as a matter of fact remark,
with no snide intentions.

Where exactly come the facts? All I see is some vague "there should be
something better, by introducing ANY". But no details how typechecking
then would work. I showed you that existing type systems can't properly
cope with ANY so far and allow for much errors. Just saying "but mine
won't" is a little bit thin, don't you think?l

Diez

[Diez B. Roggisch]

> It is not about falling back on generic declarartion, it is about

how such object will be treated. Diez seems to think that
strongly-typed language can only deal with generic declarations
by using something that allows circumventing the type system.
No, I don't - now it's you who makes assumptions about what I think. ML
and other FPs show that genericity can be done without circumvening.
Templates and generics in C++ partially do so.

In other words, you want Python to be strongly-typed, but sometimes you
want to allow a reference to be to any object whatsoever. In which case
you can't possibly do any sensible type-checking on it, so this new
Python+ or whatever you want to call it will suffer from the same
shortcomings that C++ and java do, which is to say type checking can't
possibly do anything useful when the acceptable type of a reference is
specified as ANY.
And you are wrong. The problem with the C void* construct (I'm not that
familiar with java) is that all type information is lost. When you
use such a parameter in a function you have no idea what you are
working with.

You don't know JAVA - I do. And nobody said that it lost that
type-information. It doesn't. Still, errors occur - namely
ClassCastEcxeptions.

That indicates that going back and forth via ANY doesn't necessarily
lose any type information, but the capability of today's type-systems
to keep that information across such a transition. This won't work:

Object foo = A();
B bar = (B) foo;

And please, pretty please don't argue with the simplicity of that
example - think of a bazillion statements between these two, possibly
done with run-time-instantiated classes that weren't known at
compile-time.
But that doesn't need to be if you have a typesystem with an ANY type.
Such a type declaration would mean that object of any type could be
used here. However that doesn't imply that the type information
of the actual objects used, has to be lost. That type information
may still be available and usefull for further type checking.
JAVA has that.
That you and Diez can only think about C, C++ or java constructs
when I mention an ANY type, is your limitation. It doesn't
need to be the limitation of a specific type system.

Again: where are the specifics of this system? In your head? Tell us
the gory detail, please.

Diez

[Roy Smith]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

What this is about (to me at least) is the edit-debug cycle. Let's
say I write some Python code, using assert to validate datatypes.
Maybe I've made 4 errors. I then write a test function and run it.
Boom, the first assert fails. I fix the first error, run again.
Boom, the next assert fails. Fix the next error, run again, boom,
fix, etc. Four edit-debug cycles.

With static typing, I run the compiler, get 4 error messages, fix all
4, and can get on with the next phase of testing with three fewer edit
cycles.

That's certainly the plan, but my experience is that it's not the whole
story, for a few reasons.

1) I can often run 4 Python edit-debug cycles in the time it takes me to
run a single C++ cycle, especially if there's a whole pile of build system
gunk layered on top of the raw compile step.

2) When I get a bunch of compile errors, I know that many of them are just
cascaded from a single problem. Thus, I tend to fix the first one and only
take a quick look at all the others. If it's obvious what the problem is,
I'll fix it, but as often as not, I'll just recompile and see what pops out
the next time.

3) Many times, I'll spend more time making the compiler happy than the
protection it affords me is worth. C++ is such a complex language, it's
really hard to write a compiler which follows every detail of the spec, and
the details are what kills you. We had a case the other day where a
const_cast of a reference returned by a function worked just fine on
Solaris, but failed on HPUX. We ended up with three guys digging through
reference manuals trying to figure out how const_cast and references are
supposed to interact. We ended up deciding what we were doing was legal,
but we still had to devise a work-around so it compiled on all platforms.
It's actually a little more complex than that, because we don't even write
raw const_cast's, we use a CONST_CAST macro to work around older compilers
that don't support modern casting, so we burned a little more time
double-checking that our macro expansion wasn't at fault. We could have
done a lot of Python edit-debug cycles in the time it took to sort that one
out.

[Diez B. Roggisch]

> Now some of the Python-is-perfect crowd seems to suffer from a "Blub

paradox" (http://c2.com/cgi/wiki?BlubParadox). They see annoying,
static typed languages like C and Java, and they see pleasant,
dynamically typed languages like Python, and conclude that static
types = annoying, when in fact they can be orthogonal. So, can there
be a language that's both statically typed, and pleasant? I haven't
used one yet, but lately I've been reading about Haskell and want to
give it a try.

Nobody says that there can't be possibly better languages like python
overall, or for specific tasks. However, this discussion is about
introducing type-checking to python. And as someone who has done his
fair share of FP programming let me assure you that

- all declarations are fully type annotated. The inference only comes
into play on _expressions_. The result in python would be that you'd
have to write

def foo(x:int):int :
return 10

but then could use

x = foo()

which made the inference possible. But it _doesn't figure out that foo
returns an int because there is one returned, and misses the :int in
the declaration! Genericity is reached through solving somewhat more
complicated type equations - but these still require declarations:

def bar(l:list[whatever]):whatever :
return head(l)

x = bar([10])

can be resolved as [] will me a list-constructor that gets passed an
int literal - wich in turn means that whatever as type-variable is
bound to int, and thus x is an int, as that is the return type of bar.

- FPs share their own set of problems - try writing a server. The have
inherent troubles with event-driven programs. Then you need monads, and
that makes things a little bit more ugly...

Still, FP is cool. But python too. And just attaching some
type-inference to python won't work.

Diez

[Paul Rubin]

"Diez B. Roggisch" <de***@web.de> writes:

- FPs share their own set of problems - try writing a server. The
have inherent troubles with event-driven programs.
Erlang?
Still, FP is cool. But python too. And just attaching some
type-inference to python won't work.

Yeah, I've figured declarations in Python would be more like Common
Lisp's, i.e. optional, enforced at compile time only when the compiler
can easily figure it out, and at runtime otherwise.

[Diez B. Roggisch]

Paul Rubin wrote:

"Diez B. Roggisch" <de***@web.de> writes:

- FPs share their own set of problems - try writing a server. The
have inherent troubles with event-driven programs.

Erlang?

Guess what, worked with that, too :) And let me assure you - it does
have pretty much runtime type error issues. It's interpreted. I'm not
sure what the compiler/parser gets at loading a source file. And the
Mnesia distributed database lets you easily query the wrong values...
It's interesting, and it's concurrent programming paradigms are great.
But it's far from being perfect, and needs thourough testing before
deploying new code.

Still, FP is cool. But python too. And just attaching some
type-inference to python won't work.

Yeah, I've figured declarations in Python would be more like Common
Lisp's, i.e. optional, enforced at compile time only when the compiler
can easily figure it out, and at runtime otherwise.

Easy cases are easy... The thing is: I'm all for typechecking as long
as it doesn't burden me. In FP it doesn't, as the expressional power is
way better. But in JAVA, it does. And just doing wishful-thinking about
that Python should do better that won't help... :)

Diez

[Steve Holden]

Christophe wrote:

Fredrik Lundh a écrit :

"Christophe" wrote:

It's more of a "Nearly too late" type checking I would say. Not that I
complain but it would be great if there were also some automatic type
checking to catch a few errors as soon as possible.

use assert as the soonest possible point. implementing "type gates" is
trivial, if you think you need them.

Still, it would be great if there were also some automatic type checking
in place. Using assert is hardly automatic and non intrusive.

I mean, why not ? Why does the compiler let me do that when you know
perfectly that that code is incorrect :
def f():
return "a" + 5

Of course the system can't be perfect but it doesn't need to be. It
doesn't need to constrain us in any way but if it can detect some errors
early, then it is worth it.

While this is a perfectly acceptable feature request, we should remember
that Python is developed and maintained by a volunteer team. Do we
*really* want them spending their time adding "features" like this?

regards
Steve
--
Steve Holden [phone] [phone]
Holden Web LLC www.holdenweb.com
PyCon TX 2006 www.python.org/pycon/

[Antoon Pardon]

Op 2005-10-07, Diez B. Roggisch schreef <de***@web.de>:

Antoon Pardon wrote:

Then argue against my ideas, and not your makings of it.

If I just use 'ANY' and you fill that in with C void* like
implementation and argue against that, then you are arguing
against your own ghosts, but not against what I have in mind.
Well, you didn't tell us what you had in mind.

Indeed I hadn't. It wasn't needed for the question I posed then.
You just said "let's
introduce something like any". I showed you existing implementations of
such a concept that have problems.
But as far as I can see that is a problem of the implementation
not necessarily of the concept.
You say "thats not what _I_ have in
mind, so your criticism doesn't apply." Guess what, I can't read your
mind. But you did not tell me in what your idea is different from
existing concepts.
Indeed you can't read my mind, but what pops up in your mind shows
your preconceptions. You could have just answered the question
as it was posed, instead of filling in the details yourself, maybe
remarking that you didn't see how it would work with current
type systems you know off.

You have not counterd my idea with criticism. You have decorated my
idea with how you think it would be implemented (C void*) and argued
against that. I don't need to give an implementation to notice, that
you jumped to a particular implementation and basicly just countered
that implementation, not the idea in general.

Again - where is your idea layed out in (more) detail, so that one can
discuss them? That was all that I'm asking - which of course you
carefully avoided...

Sure I'm reluctant to give details. I consider this a hostile
environment, for this kind of proposals. I'm sure people will
be able to come up with all kind of problems my idea won't solve
and will see this as a reason to think the idea is useless.

Since I have no intention to

As far as I'm concerned that was just meant as a matter of fact remark,
with no snide intentions.

Where exactly come the facts?

About how you filled in the details yourself when all I mentioned
was a type system with an "ANY" type.
All I see is some vague "there should be
something better, by introducing ANY". But no details how typechecking
then would work. I showed you that existing type systems can't properly
cope with ANY so far and allow for much errors. Just saying "but mine
won't" is a little bit thin, don't you think?l

The main idea is that type information would be available at two places.

1) The names, which carry the declared type.

2) The objects which carry the type/class they belong too.

When an object is bound to a name, a check is made that the type of the
object is compatible with the declared type of the name.

A name with type ANY, would be just like any python variable or
instance now. Python could implement this by instead of storing its
variables in dictionaries as (name, value) tuples, by storing them
as (name, declaration, value) tuples and making the necesarry checks
at (re)bind time. Variables that are not declared would get the
ANY declaration so that current scripts would just remain working
as they do now. But as the compiler got more sophisticated some
of these checks might be doable at compile time instead of at
run time.

--
Antoon Pardon

[Paul Rubin]

"Diez B. Roggisch" <de***@web.de> writes:

Erlang?
Guess what, worked with that, too :) And let me assure you - it does
have pretty much runtime type error issues. It's interpreted.

Yes, it makes no attempt at being statically typed. It's like Python
that way, AFAIK.
Easy cases are easy... The thing is: I'm all for typechecking as long
as it doesn't burden me. In FP it doesn't, as the expressional power is
way better. But in JAVA, it does. And just doing wishful-thinking about
that Python should do better that won't help... :)

How about Lisp? It seems to do some good there, without getting in
the way.

[Diez B. Roggisch]

You just said "let's
introduce something like any". I showed you existing implementations of
such a concept that have problems.
But as far as I can see that is a problem of the implementation
not necessarily of the concept.

Without any concept, sure there can't be problems with that concept.

You say "thats not what _I_ have in
mind, so your criticism doesn't apply." Guess what, I can't read your
mind. But you did not tell me in what your idea is different from
existing concepts.

Indeed you can't read my mind, but what pops up in your mind shows
your preconceptions. You could have just answered the question
as it was posed, instead of filling in the details yourself, maybe
remarking that you didn't see how it would work with current
type systems you know off.

How can one answer a question without what he knows? Sure I fill in the
context. If I wouldn't know that this whole NG is about python, I
wouldn't know how to answer most of the questions that arise here.
Which is a general thing about communication.

But I certainly have had more contact with type systems than you had -
so my "filling-out" was by no means unreasonable - as you imply.
Without further details, one can only guess. And debuking guesswork by
saying "but _that_ wasn't what I meant" as you permanently do is easy -
but doesn't make _your_ point valid.
Sure I'm reluctant to give details. I consider this a hostile
environment, for this kind of proposals. I'm sure people will
be able to come up with all kind of problems my idea won't solve
and will see this as a reason to think the idea is useless.
Why hostile? Because people will possibly destroy your wishful thinking
by providing counter examples - if they exist? I doubt that a serious
proposal would get suppressed here - as the static compilers that have
shown up recently prove, as they have been greeted and met with
reasonable criticism where it was in order.

You didn't come up with an Idea so far, as I'm concerned. Just some
random thoughts.

But then again, here we go:
The main idea is that type information would be available at two places.

1) The names, which carry the declared type.
JAVA.
2) The objects which carry the type/class they belong too.
That already is the case.
When an object is bound to a name, a check is made that the type of the
object is compatible with the declared type of the name.
JAVA exactly does that.
A name with type ANY, would be just like any python variable or
instance now. Python could implement this by instead of storing its
variables in dictionaries as (name, value) tuples, by storing them
as (name, declaration, value) tuples and making the necesarry checks
at (re)bind time. Variables that are not declared would get the
ANY declaration so that current scripts would just remain working
as they do now.
So far, this is exactly what java does - plus a more dynamic approach
to method/function invocation on ANY. So it seems my assumptions about
what you had in mind weren't so false after all, eh?
But as the compiler got more sophisticated some
of these checks might be doable at compile time instead of at
run time.

Well, that exactly is the point where we make the transition from "this
is how things work" to pure speculation. Can't say that there won't be
a solution someday - but certainly it requires much more, and from
above nobody can say that this would solve _any_ problem.

What you propose above is what JAVA does - plus more dynamicity. Well,
given that even the "non-dynamic, everything has to be annotated" JAVA
fails to deal with ANY (called Object there), I can't see how a more
dynamic environment will do _better_ in that respect. So unless you lay
out some more detailed ideas how that works, this surely won't do much
if any better than JAVA does today - and JAVA sucks _precisely_ because
of the half-static-half-dynamic nature. It gives you both troubles -
runtime errors like in python, together with compile-time limitations.

Let's face it: you don't know much about type-systems. I do know a bit
more - but don't claim to possess the holy grail. And I don't say that
more powerful analyzing isn't possible. However, all you do so far is
fantasizing and "fail to see why not". Well, that failure might be
because of limited sight on your side - not necessarily on our, which
you constantly claim.

Visions are a nice thing - but actually, in the scientific domain not
so much a vision, but proofs are what is needed. And if you consider it
hostile that nobody buys your ideas because so far they aren't more
than marketing/whishful thinking, I'm sorry that I can't help you.

Diez

[Fredrik Lundh]

"Christophe" wrote:

I mean, why not ? Why does the compiler let me do that when you know
perfectly that that code is incorrect : def f():
return "a" + 5

probably because the following set is rather small:

bugs caused by invalid operations involving only literals, that are not
discovered during initial testing

</F>

[Paul Rubin]

Mike Meyer <mw*@mired.org> writes:

When you want local variable in lisp you do :

(let ((a 3)) (+ a 1))

Excep that's not a decleration, that's a binding. That's identical to
the Python fragment:

a = 3
return a + 1

except for the creation of the new scope. Not a variable decleration
in site.

Really not though, the scope is what makes it a declaration. In
Python you can say:

for i in 1,2:
if i == 2: print x # x is unbound the first time through the loop
x = 9 # but bound the second time

and the print doesn't raise an error. Further, 'x' is still in scope
even after the loop exits. Scheme lets you say something like

(define (counter)
(let ((k 0))
(define (f)
(set! k (+ 1 k))
k)
f))

Yeah, I know you'd write it a bit more concisely in Scheme, but I
wanted to make it look like the Python equivalent:

def counter():
k = 0
def f():
k += 1
return k
return f

The trouble is, in f, k is neither local nor global, so Python throws
up its hands and raises an error. There's no way to tell it where to
find k. This could be solved with a declaration, if Python understood it.

[Diez B. Roggisch]

> How about Lisp? It seems to do some good there, without getting in

the way.

I don't know much about lisp. But the thing is that one of the most
important data structures in python (and basically the only one in
LISP), lists, are a big problem to type-checking if they aren't
homogenous. So I guess one can write a compiler that generates
specialized code for lists of a certain homogenous kind, like lists of
int, float and maybe string - and as long as you ensure that code is
called with such a list, you're ok. But I think that is what psyco
does, too (no idea how these two compare)

Basically, all type-inferencing boils down to collecting constraints on
variable values. Like in this expression

z = x + y

It will be internall represented by this:

z:C = x:A + y:B

which introduces type-variables A,Band C. That tells us that all
operations __plus__ and their respective types could be meant, thus A B
C are constrained by these types. Which, in an overloading-allowing
language, can get pretty much. The trick is to find a solution for the
variables that satisfy all the constraints. And a solution are actual
types, not ad-hoc sets of types - otherwise, you can't create any
specialized code, and the compiler will puke on you.

Saying

z += 10

now creates a constraint that binds C to int, and subsequently A and B.

Now the problem is someting like this:

if x is None:
x = 10
else:
x = x * 10

Lets assume A as type-var for x. Then we have the two contstraints A ->
int and A -> None. Now - is there a type that satisfies both
constraints? No. And even worse, A shall be int by x = 10 - but that
collides with A->None. So the only thing you can do is resort to A=ANY
- and interpret that code above :)

Diez

[Alex Martelli]

Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
...

egold = 0:
while egold < 10:
if test():
ego1d = egold + 1

Oh come on. That is a completely contrived example,

No it is not. You may not have had any use for this
kind of code, but unfamiliary with certain types
of problems, doesn't make something contrived.

It's so contrived it will raise a SyntaxError due to the spurious extra
colon on the first line;-).

Or, consider, once the stray extra colon is fixed:

Helen:/tmp alex$ cat ap.py
def ap():
egold = 0
while egold < 10:
if test():
ego1d = egold + 1

Helen:/tmp alex$ pychecker ap.py
Processing ap...

Warnings...

ap.py:4: No global (test) found
ap.py:5: Local variable (ego1d) not used
Helen:/tmp alex$

If you're so typo-prone and averse to unittests that you consider this
kind of issue to be a serious problem, just use pychecker and get
informed about any such typo, just as above.

Incessant whining about the non-existent advantages of declarations,
rather than the simple use of tools that can diagnose such spelling
mistakes without any need for declarations, would qualify you as a troll
even if you didn't have a long history of trolling this group...
Names do get misspelled and sometimes that misspelling is hard to spot.

It's totally trivial, of course, as shown above, and there is no need to
pervert and distort the language for the purpose, as you, troll, have
kept whining about for years. I'm partial to pychecker -- that's what
we use at Google, and we also, incidentally, recently had the good
fortune to hire Neal Norwitz, pychecker's author; but there are several
other free tools that perform similar tasks, albeit with very different
philosophy, such as Logilab's pylint...:

Helen:/tmp alex$ pylint ap.py
No config file found, using default configuration
************* Module ap
W: 2: Bad indentation. Found 3 spaces, expected 4
W: 3: Bad indentation. Found 3 spaces, expected 4
W: 4: Bad indentation. Found 5 spaces, expected 8
W: 5: Bad indentation. Found 7 spaces, expected 12
C: 0: Too short name "ap"
W: 0: Missing docstring
W: 0: Missing required attribute "__revision__"
C: 1:ap: Too short name "ap"
W: 1:ap: Missing docstring
E: 4:ap: Undefined variable 'test'
W: 5:ap: Unused variable 'ego1d'

[rest of long critique of ap.py snipped]

Again, unused variables (typos...) get easily diagnosed without any need
for declarations. (Similar tools, of course, apply to languages
requiring declaration, to diagnose a variable that's declared but
unused, which is a very bad code smell typical of such languages). Of
course, pylint is about enforcing all sort of code rules, such as, by
default, indentation by multiples of 4 spaces, name length, docstrings,
and so on; while pychecker is much simpler and more narrowly aimed at
diagnosing likely mistakes and serious code smells.

But, with either tool or any of many others, there is no need at all for
declarations in order to catch typos (of course, unittests are still a
VERY good idea -- catching all typos and even coding rules violations is
NO guarantee that your code is any good, testing is A MUST).

It would give the
programmer a false sense of security since they 'know' all their
misspellings are caught by the compiler. It would not be a substitute for
run-time testing.

I don't think anyone with a little bit of experience will be so naive.

Heh, right. After all, _I_, for example, cannot have even "a little bit
of experience" -- after all, I've been programming for just 30 years
(starting with my freshman year in university), and anyway all I have to
show for that is a couple of best-selling books, and a stellar career
culminating (so far) with my present job as Uber Technical Lead for
Google, Inc, right here in Silicon Valley... no doubt Google's reaching
over the Atlantic to come hire me from Italy, and the US government's
decision to grant me a visa under the O-1 category (for "Aliens with
Outstanding Skills"), were mere oversights on their part that,
obviously, I cannot have even "a little bit of experience", given that I
(like great authors such as Bruce Eckel and Robert Martin) entirely
agree with the opinion you deem "so naive"... that any automatic
catching of misspellings can never be a substitute for unit-testing!
Ah well -- my good old iBook's settings had killfiles for newsreaders,
with not many entries, but yours, Antoon, quite prominent and permanent;
unfortunately, that beautiful little iBook was stolen
(http://www.papd.org/press_releases/8...macs_211.html), so I got
myself a brand new one (I would deem it incorrect to use for personal
purposes the nice 15" Powerbook that Google assigned me), and it takes
some time to reconstruct all the settings. But, I gotta get started
sometime -- so, welcome, o troll, as the very first entry in my
brand-new killfile.

In other words: *PLONK*, troll!-)
Alex

[Paul Rubin]

al***@mail.comcast.net (Alex Martelli) writes:

ap.py:4: No global (test) found
ap.py:5: Local variable (ego1d) not used
Helen:/tmp alex$

If you're so typo-prone and averse to unittests that you consider this
kind of issue to be a serious problem, just use pychecker and get
informed about any such typo, just as above.

That's very helpful, but why isn't it built into Python?

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al***@mail.comcast.net (Alex Martelli) writes:

ap.py:4: No global (test) found
ap.py:5: Local variable (ego1d) not used
Helen:/tmp alex$

If you're so typo-prone and averse to unittests that you consider this
kind of issue to be a serious problem, just use pychecker and get
informed about any such typo, just as above.

That's very helpful, but why isn't it built into Python?

Because some users will prefer to use a different approach to checking,
for example, such as pylint (much more thorough in enforcing coding
rules and checking for all sort of things) or nothing (much faster than
pychecker, which in turn is faster than pylint). Just as for other
programming tools, such as, say, an editor, I think it's wise to avoid
excessive and premature standardization on one specific tool to the
detriment of others. (IDLE is "bundled with" Python, but not _built
into_ it -- indeed some would claim that the bundling was too much).

Not all tools need evolve at the same speed as the core language, which
currently follows a wise policy of "major" releases (2.3, 2.4, etc)
about 18 to 24 months apart, and NO feature changes for "point" release
(2.4.2 has exactly the same features as 2.4.1 -- it just fixes more
bugs). Any tool which gets built into python (or, less strictly but
still problematically, is separate but bundled with it) must get on
exactly the same schedule and policy as Python itself, and that is
definitely not something that's necessarily appropriate.

If you're worried about the end-users which can't be bothered to
download tools (and, for that matter, libraries) separately from the
main language, the solution is "sumo releases" -- Enthought Python (from
Enthought) being an extreme example, but Active Python (from
ActiveState) comes with quite a few bundled add-ons, too. I believe
that Linux has proven the validity of this general model: having the
"core" (mostly the kernel, in Linux's case; the language and standard
library, in Python's) evolve and get released as its own speed, and
having _distributions_ bundling the core with different set of tools and
add-ons get released on THEIR preferred schedules, independently.
Alex

[Antoon Pardon]

Op 2005-10-07, Diez B. Roggisch schreef <de***@web.de>:

Well, that exactly is the point where we make the transition from "this
is how things work" to pure speculation.
Everything starts with pure speculation. I had no intention of
introducing the big type system here. I just think people who
oppose type systems, limit themselves too much to how things
currently work and from there oppose anything that resembles
a type system instead of thinking of what they would like
a type system to do even if it is not implemtable now.
Can't say that there won't be
a solution someday - but certainly it requires much more, and from
above nobody can say that this would solve _any_ problem.

What you propose above is what JAVA does - plus more dynamicity.
So it isn't exactly JAVA afterall.
Well,
given that even the "non-dynamic, everything has to be annotated" JAVA
fails to deal with ANY (called Object there),
So please explain how my system fails with the ANY.
I can't see how a more
dynamic environment will do _better_ in that respect.
You first argued that a type system had to limit the coder and you
gave the example of the homegeneous list. I suggested an ANY type
and asked how a homegeneous list of ANY's would limit the coder.
Your respons was that this was like a JAVA Object or C void* hack,
that can be used to circumvent the type system and cause all kinds
of problems, presumebly python was not vulnerable to.

So I would either like you to explain how my idea can be used to
circumvent the type system and cause problems, which don't
concern python or explain how this system will limit the coder
with respect what can be done in python.

So unless you lay
out some more detailed ideas how that works, this surely won't do much
if any better than JAVA does today - and JAVA sucks _precisely_ because
of the half-static-half-dynamic nature. It gives you both troubles -
runtime errors like in python, together with compile-time limitations.
I have no need to convince you. It was you who made this claim how
a type system had to limit the coder. That you can't see how it
could be done is not an argument. Surely if a typesystem *must* limit
the user or else cause all kinds of problems as more general argument
can be given that doesn't depend on the specific implementation.
Let's face it: you don't know much about type-systems. I do know a bit
more - but don't claim to possess the holy grail. And I don't say that
more powerful analyzing isn't possible. However, all you do so far is
fantasizing and "fail to see why not". Well, that failure might be
because of limited sight on your side - not necessarily on our, which
you constantly claim.
Well, I could accept that if you would have explained what the problem
would be with my system instead of just saying you couldn't see how
it would be more usefull than JAVA Objects.
Visions are a nice thing - but actually, in the scientific domain not
so much a vision, but proofs are what is needed.
Well you made the claim that a type system had to limit the coder.
Now prove your claim. Untill this is done I see no problem thinking
about type systems that don't limit the coder.
And if you consider it
hostile that nobody buys your ideas because so far they aren't more
than marketing/whishful thinking, I'm sorry that I can't help you.

I don't consider it hostile that nobody buys my ideas. I considered
the environment here hostile to type systems long before I brought
my two cents to the discussions about this subject here.

--
Antoon Pardon

[Bengt Richter]

On Fri, 7 Oct 2005 21:56:12 -0700, al***@mail.comcast.net (Alex Martelli) wrote:

Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
...

>> egold = 0:
>> while egold < 10:
>> if test():
>> ego1d = egold + 1
>>
>
> Oh come on. That is a completely contrived example,
No it is not. You may not have had any use for this
kind of code, but unfamiliary with certain types
of problems, doesn't make something contrived.

It's so contrived it will raise a SyntaxError due to the spurious extra
colon on the first line;-).

Glad to see a smiley ;-)
Or, consider, once the stray extra colon is fixed:
[... demonstration of effective tool use to diagnose contrived[1] snippet's problems ...]

[1] the code snippet certainly seems contrived to me too. Not sure whether entire class of code
that it may have been intended to represent is contrived, but I'm willing to give the benefit
of the doubt if I sense no ill will ;-)
[...]

> It would give the
> programmer a false sense of security since they 'know' all their
> misspellings are caught by the compiler. It would not be a substitute for
> run-time testing.
I don't think anyone with a little bit of experience will be so naive.

This strikes me as a somewhat provocative and unfortunately ambiguous statement ;-)

The way I read it was to assume that Antoon was agreeing with the judgement that
the 'sense of security' would be false, and that he was saying that an experienced
programmer would not be so naive as to feel secure about the correctness of his
code merely on the basis of a compiler's static checks (and thus skip run-time testing).

Heh, right. After all, _I_, for example, cannot have even "a little bit
of experience" -- after all, I've been programming for just 30 years
(starting with my freshman year in university), and anyway all I have to
show for that is a couple of best-selling books, and a stellar career
culminating (so far) with my present job as Uber Technical Lead for
Google, Inc, right here in Silicon Valley... no doubt Google's reaching
over the Atlantic to come hire me from Italy, and the US government's
decision to grant me a visa under the O-1 category (for "Aliens with
Outstanding Skills"), were mere oversights on their part that,
obviously, I cannot have even "a little bit of experience", given that I
(like great authors such as Bruce Eckel and Robert Martin) entirely
agree with the opinion you deem "so naive"... that any automatic
catching of misspellings can never be a substitute for unit-testing! I somehow don't think Antoon was really disagreeing with that (maybe because after
45+ years of programming and debugging I think it would be too absurd ;-)

Ah well -- my good old iBook's settings had killfiles for newsreaders,
with not many entries, but yours, Antoon, quite prominent and permanent;
unfortunately, that beautiful little iBook was stolen
(http://www.papd.org/press_releases/8...macs_211.html), so I got Ugh, bad luck ... but if it had to happen, better that it wasn't from your home.
myself a brand new one (I would deem it incorrect to use for personal
purposes the nice 15" Powerbook that Google assigned me), and it takes
some time to reconstruct all the settings. But, I gotta get started
sometime -- so, welcome, o troll, as the very first entry in my
brand-new killfile. I'd urge you to reconsider, and see if you really see trollish _intent_
in Antoon ;-)

In other words: *PLONK*, troll!-)

IMO that's a bit harsh, especially coming from a molto certified heavyweight ;-)

Antoon doesn't strike me as having the desire to provoke for the sake of provoking,
which seems to me to be the sine qua non hallmark of trolls. Of course anyone
with any ego is likely to be feel like posting defensive tit-for-tat to "correct"
any inadequate appreciation of worth coming from the other side, and that can degenerate
into something that looks like pure troll postings, but I think that is normal succumbing
to ego temptations, not signs true trollishness. E.g., ISTM Antoon and Diez were managing
rather well, both being frustrated in getting points across, but both displaying patience
and a certain civility. To me, the "winning" posts are the ones that further the development
of the "truth" about the topic at hand, and avoid straying into ad hominem irrelevancies.
OTOH, I think everyone is entitled at least to ask if a perceived innuendo was real and
intentional (and should be encouraged to do so before launching a counter-offence).
Sometimes endless niggling and nitpicking gets tiresome, but I don't think that is necessarily
troll scat either. And one can always tune out ;-)

Anyway, thanks for the pychecker and pylint demos. And I'm glad that we can enjoy your posts again,
even if for a limited time.

-- Martellibot admirer offering his .02USD for peace ... ;-)

Regards,
Bengt Richter