PEP 3107 and stronger typing (note: probably a newbie question)

[paul]

Stephen R Laniel a écrit :

Just a question : what will happen if you get rid of the try/except
block ?-)

The error will remain unnoticed and the argument might survive another
few function calls but eventually fails deep down somewhere with:

TypeError: cannot concatenate 'str' and 'list' objects

then you have to examine the traceback and hope the real error is
visible somewhere (an argument not conforming to the specification of
the function prototype, or the lack thereof).

cheers
Paul

 

[Chris Mellon]

The error will remain unnoticed and the argument might survive another
few function calls but eventually fails deep down somewhere with:

TypeError: cannot concatenate 'str' and 'list' objects

then you have to examine the traceback and hope the real error is
visible somewhere (an argument not conforming to the specification of
the function prototype, or the lack thereof).

In the example given, not catching the example will provide *more*
information than the terrible exception handling performed. If you're
going to write thick boilerplate to log the values of your locals and
arguments around all your functions, I suggest that you not do that
and instead make use of the ehanced tracebacks in the cgitb module,
which will give you a stack trace with the values of the locals in
each stack frame.

The only reason to trap an exception is either to redirect the
exception (for example, I have a call in a thread which can't be
permitted to throw, so exceptions are caught and transfered elsewhere
for logging), or to correct the error that caused the exception.
Boilerplate like this is at best useless, and in the case of the
example given actively worse than simply not catching it at all.

 

[Bruno Desthuilliers]

paul a écrit :

The error will remain unnoticed

Err... cf below, I think you misunderstood me.

and the argument might survive another
few function calls but eventually fails deep down somewhere with:

TypeError: cannot concatenate 'str' and 'list' objects

then you have to examine the traceback and hope the real error is
visible somewhere (an argument not conforming to the specification of
the function prototype, or the lack thereof).

I asked about getting rid of the try/except - not about getting rid of
the calls to int and str:

def my_func( int_arg, str_arg ):
int_arg = int( int_arg )
str_arg = str( str_arg )
# now proceed...

Now, what will happen with this ?

And no, it's not type checking - it's duck typing at work.

 

[Bruno Desthuilliers]

harri a écrit :

Bruno Desthuilliers wrote:
[...]

It seems obvious from this that static typecheking would require
dropping all dynamism from Python - then turning it into another, very
different (and mostly useless as far as I'm concerned) language. IOW :
you can't have Python *and* static typechecks - both are mutually
exclusive. Hence my answer : if you want static typecheking, you'll have
to use another language - one way or another.

Well, static typing for me is usually the way to get the last speed
required once the
algorithmic improvements are exhausted.

Indeed - static typing is for compilers, not for programmers.

The language Pyrex uses combines dynamic and static typing in a very
useful manner.

Yes. But Pyrex is another language - and a much less dynamic one.

 

[Stephen R Laniel]

Indeed - static typing is for compilers, not for programmers.

When done well, static typing helps the programmer -- just
like writing good unit tests. It's not a magic bullet, but
it can help.

I'd like to point again to Mark-Jason Dominus's
explanation of how strong static typing can be done well:
http://perl.plover.com/yak/typing/notes.html

The example toward the end of how ML actually spots an
infinite loop at compile time seems to me to be "for
programmers" rather than "for compilers."

--
Stephen R. Laniel
(e-mail address removed)
Cell: +(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key

 

[Paul Boddie]

I'd like to point again to Mark-Jason Dominus's
explanation of how strong static typing can be done well:
http://perl.plover.com/yak/typing/notes.html

What's interesting is that the author touches on explicit attribute
declarations in slide 37 - something which I think John Nagle
suggested recently, although apologies to John and the person in
question if it was someone else. Without actually declaring types for
those attributes, it's possible to make some potential efficiency
gains, and I think that interfaces (really clusters of attributes in
this case) can be deduced with only this information explicitly stated
by the programmer. Of course, you can also try whole program analysis
to get an idea of which instances have which attributes, too.
Certainly, there are lots of approaches available without writing type
names all over the place, as seems to be the fashion in certain
circles.

Paul

 

[Roy Smith]

What's interesting is that the author touches on explicit attribute
declarations in slide 37 - something which I think John Nagle
suggested recently, although apologies to John and the person in
question if it was someone else. Without actually declaring types for
those attributes, it's possible to make some potential efficiency
gains, and I think that interfaces (really clusters of attributes in
this case) can be deduced with only this information explicitly stated
by the programmer. Of course, you can also try whole program analysis
to get an idea of which instances have which attributes, too.
Certainly, there are lots of approaches available without writing type
names all over the place, as seems to be the fashion in certain
circles.

Paul

Software type checking (static, dynamics, whatever) is for weenies. Real
men use hardware type checking. Google "Burroughs B5000".

 

[Bruno Desthuilliers]

Stephen R Laniel a écrit :

When done well, static typing helps the programmer

The closer thing to "well done static typing" I know is type inference
(à la O'Caml). And I don't find it that helpfull to the programmer -
here again, it's mainly to allow compile-time optimizations.

(snip)

The example toward the end of how ML actually spots an
infinite loop at compile time seems to me to be "for
programmers" rather than "for compilers."

It's been a long time since I last got into such a problem. Which BTW
was very quickly spotted and fixed. Compared to what I would loose, I
don't think this kind of "help" is so useful.

Stephen, you may not know yet, but Python is *dynamic*. This defeats
almost all compile-time checking. Of what help would type inference be
when you can dynamically add/remove/replace attributes (including
methods and class) at runtime ?

 

[Stephen R Laniel]

Stephen, you may not know yet, but Python is *dynamic*. This defeats
almost all compile-time checking. Of what help would type inference be
when you can dynamically add/remove/replace attributes (including
methods and class) at runtime ?

Heh. [Insert grimacing smile here]

People on here have been ... ahhh ... *generous* about
explaining that Python is dynamic, and hence that static
typing doesn't make sense. I've got it. I merely passed
along that MJD reference because you were making a point
about what static typing is for in general (i.e., not
specific to Python). I thought I'd give examples of how
languages other than Python use it to good effect, and not
just for compiler optimization.

Cheers,
Steve

--
Stephen R. Laniel
(e-mail address removed)
Cell: +(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key

 

[John Nagle]

harri a écrit :

Indeed - static typing is for compilers, not for programmers.

Actually, static typing is for detecting errors before the
program is run.

John Nagle

 

[John Nagle]

People on here have been ... ahhh ... *generous* about
explaining that Python is dynamic, and hence that static
typing doesn't make sense. I've got it.

That's not really the issue. There are languages with
no static typing, like Python, and there are languages with
fullly enforced static typing, like Java. Both work.

PEP 3107 is static typing without enforcement, which is not a good thing.
It's one that's been tried, many times, as coding conventions. Microsoft
code from the Windows 3.1 era was heavy on that sort of thing.
Remember "Hungarian notation"? "LPSTR"? Yes, that stuff.
Moving to C++ and strong typing was generally considered a major
improvement in the Windows world.

John Nagle

 

[Stephen R Laniel]

You said ?

I could link again to Mark-Jason Dominus, who writes that
people often make the following inference:

1) C is strongly typed.
2) C's typing sucks.
3) Hence strong typing sucks.

But I won't.

It doesn't need to be a religious war. Why can't people just
say "When strong typing is done and used well, it's a
useful tool; when it's not, it's not"?

--
Stephen R. Laniel
(e-mail address removed)
Cell: +(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key

 

[Donn Cave]

John Nagle a écrit :

bruno@bibi ~ $ cat toto.c
#include <stdio.h>
int main(void)
{
char *toto = (char *)42;
printf("%s", toto);
return 0;
}
bruno@bibi ~ $ gcc -ototo toto.c
bruno@bibi ~ $ ./toto
Erreur de segmentation
bruno@bibi ~ $

You said ?

A discussion about static typing on comp.lang.python is liable
to be a little tiresome even when it isn't conducted on such a
silly level.

The GvR ideas I've seen on V3 typing show some acquaintance with
type inference etc. as used in modern functional languages.
While C++ or Java may represent static typing to Python users,
I don't think there's much risk that they will have anything to do
with static typing in V3, if it's supported in some way.

Secondly, one can reasonably argue that steel toed boots
prevent injuries to the toe, without having to prove that
they withstand a welding torch, a nuclear blast, etc.

Donn Cave, (e-mail address removed)

 

[Eduardo \EdCrypt\ O. Padoan]

I could link again to Mark-Jason Dominus, who writes that
people often make the following inference:

1) C is strongly typed.
2) C's typing sucks.
3) Hence strong typing sucks.

AFAIK, Python type system is "stronger" than C. C is just *static* typed.

But I won't.

It doesn't need to be a religious war. Why can't people just
say "When strong typing is done and used well, it's a
useful tool; when it's not, it's not"?

True, why this need to be a religious war instead of everybody
agreeing with you?

 

[Alex Martelli]

PEP 3107 is static typing without enforcement, which is not a good thing.

Wrong: PEP3107 is a syntax for adding arbitrary metadata annotations (so
that said annotations don't get squished where they don't belong, such
as decorators or docstrings, as they used to be in 2.*). The PEP itself
offers a good example that should be vastly sufficient to destroy the
"is static typing" notion:

def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):

how do you get from that example to "PEP 3107 is static typing"? What
an absurd, illogical leap. Here, it's being used to provide
"per-argument docstrings" which a pydoc-like system could access as
compile.func_annotation['source'] and the like, and format as it likes
best. Type annotations (not necessarily for checking -- third party
libraries are free to provide completely different semantics, such as
adaptation) is another possible use, and Pythonistas' creativity may
well supply many, many others.


Alex

 

[Bruno Desthuilliers]

John Nagle a écrit :

Actually, static typing is for detecting errors before the
program is run.

bruno@bibi ~ $ cat toto.c
#include <stdio.h>
int main(void)
{
char *toto = (char *)42;
printf("%s", toto);
return 0;
}
bruno@bibi ~ $ gcc -ototo toto.c
bruno@bibi ~ $ ./toto
Erreur de segmentation
bruno@bibi ~ $

You said ?

 

[Bruno Desthuilliers]

Stephen R Laniel a écrit :

I could link again to Mark-Jason Dominus, who writes that
people often make the following inference:

1) C is strongly typed.

Lol. C is well known for it's very weak typing.

2) C's typing sucks.
3) Hence strong typing sucks.

Whoever make such a braindead inference should better learn the meaning
of words, read more about the concepts and applications of 'typing' in
CS, and experiment with type-inference based languages.

But I won't.

It doesn't need to be a religious war. Why can't people just
say "When strong typing is done and used well, it's a
useful tool; when it's not, it's not"?

Python is actually a rather strongly typed language. Some would even say
it's more strongly typed than C. Please stop confusing static with
strong. "static" means 'at compile time' - by opposition with "dynamic",
meaning 'at run time'. This is somewhat orthogonal to the
'weak/strong' axis.

 

[sjdevnull]

I could link again to Mark-Jason Dominus, who writes that
people often make the following inference:

1) C is strongly typed.
2) C's typing sucks.
3) Hence strong typing sucks.

But I won't.

It doesn't need to be a religious war. Why can't people just
say "When strong typing is done and used well, it's a
useful tool; when it's not, it's not"?

Python already has strong typing, much stronger than C and arguably
stronger than Java. What it doesn't have is static typing, which is
good--that's one of the defining characteristics of the language, and
dynamic languages have a lot to recommend them.

ML and Haskell are also great languages, but they're great in a very
different way. Lisp probably comes closest to a useful dynamic/static
hybrid, but there the static annotations are pretty much only for the
compiler's benefit, not the programmer's.

 

[Paul Boddie]

Wrong: PEP3107 is a syntax for adding arbitrary metadata annotations (so
that said annotations don't get squished where they don't belong, such
as decorators or docstrings, as they used to be in 2.*).

Really, we all know where PEP 3107 came from and where people are
likely to go with it. When you kick the ball up the field to the
striker, what's the most likely thing the striker is going to do? Pass
back to the goalkeeper? (Apart from in an England vs. Republic of
Ireland game, that is.)

The PEP itself offers a good example that should be vastly sufficient to destroy the
"is static typing" notion:

def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):

how do you get from that example to "PEP 3107 is static typing"?

You just need to put yourself in the position of those advocating
static typing. "Oh, 'something compilable': that's an interface,
'Compilable', which has this and this methods. [Multi-month discussion
ensues on which methods.] And the filename: well, that's a string!"
And so it continues.

What an absurd, illogical leap. Here, it's being used to provide
"per-argument docstrings" which a pydoc-like system could access as
compile.func_annotation['source'] and the like, and format as it likes
best. Type annotations (not necessarily for checking -- third party
libraries are free to provide completely different semantics, such as
adaptation) is another possible use, and Pythonistas' creativity may
well supply many, many others.

I'll accept that it allows higher precision annotations than what
we've had before, although I think it'd be a strong case of denial if
we didn't admit that the people who've probably had to struggle the
most with metadata in docstrings have been those who have been writing
wrappers and bindings. I remember decorators being proposed as useful
there, but anyway. As for javadoc-style documentation as a compelling
motivation, I've seen too much of this kind of thing to be persuaded:

/**
* The compile method.
* @param source Compilable A Compilable
* @param filename String A string
* @param mode Mode A mode
*/
public void compile(Compilable source, String filename, Mode mode);

With PEP 3107, you either get the same inane commentary inline, but
the code is still readable, or you have lots of prose, breaking up the
signature and making it potentially harder to read. The best
documentation might have some reference element as that proposed, but
the prose is what makes it stand out. And in any case, I await this
kind of thing with the above scheme:

def compile(source : MyDoc("something compilable", some_arg,
some_other_arg),
filename : MyOtherDoc("where the compilable thing comes
from", yet_more_stuff),
mode : MyDocEnum("is this a single statement or a
suite?",
EnumValue("it's a statement"), EnumValue("no, it's a
suite!"))):

I guess this could just be me being cynical as usual, though.

Paul

 

[Bjoern Schliessmann]

John Nagle a écrit :

bruno@bibi ~ $ gcc -ototo toto.c
bruno@bibi ~ $ ./toto
Erreur de segmentation
bruno@bibi ~ $

You said ?

Did he say that static typing detects all errors?

Regards,


Björn