PEP 3107 and stronger typing (note: probably a newbie question)
Stephen R Laniel
old question that has inspired its share of flame wars; I'm
new to Python, but not new to how Internet discussions work.
So if there's a canonical thread or web page that documents
the whole battle, feel free to point me to it.
Reading [1], I wonder: why isn't the compiler making better
use of (purely optional) type labeling? Why not make a compiler
directive so that
a) it will check the types of all my arguments and return
values, and maybe even
b) do some type inference up the call stack?
E.g.,
def( Class1 arg1, Class2 arg2, ..., ClassN argN ):
someStuff()
would check the types of the arguments, whereas
def( arg1, arg2, ..., argN):
someStuff()
would not? I.e., if I *want* strong static
type-checking, why shouldn't I be able to get it? Is it that
allowing this as a compile-time option would mess up too
many knobs to make it optional?
Again, probably an old debate. I'd like to know why Guido's
decided that not only is strong static typing
productivity-reducing [2], but that it should be *forbidden*.
[1] - http://www.python.org/dev/peps/pep-3107/
[2] - http://www.artima.com/intv/strongweakP.html
--
Stephen R. Laniel
st...@laniels.org
Cell: +(617) 308-5571
http://laniels.org/
PGP key: http://laniels.org/slaniel.key
Paddy
>
> --
> Stephen R. Laniel
> s...@laniels.org
> Cell: +(617) 308-5571http://laniels.org/
> PGP key:http://laniels.org/slaniel.key
You have already raised hackles with the title of your post.
Python has very strog type checking already. It does not
have static type checking which may be what you meant.
It seems that if we want to have Python compile down to
machine code then we may have to confine names to
only refer to objects of one type. (as well as None).
I would prefer it if we weren't also required to
explicitly state the types of variable names.
The reasons are that I am not new to Python and prefer
the dynamism of names and the reliance on tests and
coverage over static type checking.
As you state that you are new to Python, why not try
the Python way; gain proficiency; then think again
about the issue. If you are still of like mind then
your proficiency should enable you to give more
convincing reasons to the ccommunity.
- Paddy.
It would need support. Are you volunteering effort?
bruno.des...@gmail.com
> Before I ask anything, let me note that this is surely an
> old question that has inspired its share of flame wars; I'm
> new to Python, but not new to how Internet discussions work.
> So if there's a canonical thread or web page that documents
> the whole battle, feel free to point me to it.
>
> Reading [1], I wonder: why isn't the compiler making better
> use of (purely optional) type labeling? Why not make a compiler
> directive so that
>
> a) it will check the types of all my arguments and return
> values, and maybe even
> b) do some type inference up the call stack?
>
> E.g.,
>
> def( Class1 arg1, Class2 arg2, ..., ClassN argN ):
> someStuff()
>
> would check the types of the arguments, whereas
>
> def( arg1, arg2, ..., argN):
> someStuff()
>
> would not? I.e., if I *want* strong static
> type-checking,
Then you should use another language.
> why shouldn't I be able to get it?
Use Java and you'll get it.
> Is it that
> allowing this as a compile-time option would mess up too
> many knobs to make it optional?
Given that one can add/replace/remove methods and attributes
dynamically either on a per-class or per-instance basis, and even
dynamically change the class of an object, I fail to see how static
typechecking could be meaningfull.
> Again, probably an old debate. I'd like to know why Guido's
> decided that not only is strong static typing
> productivity-reducing [2],
He did not "decide".
> but that it should be *forbidden*.
I failed to see this word in the given url.
>
> [1] -http://www.python.org/dev/peps/pep-3107/
> [2] -http://www.artima.com/intv/strongweakP.html
>
> --
> Stephen R. Laniel
> s...@laniels.org
> Cell: +(617) 308-5571http://laniels.org/
> PGP key:http://laniels.org/slaniel.key
Stephen R Laniel
> Then you should use another language.
This is what I meant about knowing how Internet discussions
go.
--
Stephen R. Laniel
st...@laniels.org
Cell: +(617) 308-5571
Michael Hoffman
> On Wed, Jun 20, 2007 at 12:59:28PM -0700, bruno.des...@gmail.com wrote:
>> Then you should use another language.
>
> This is what I meant about knowing how Internet discussions
> go.
You originally said "Before I ask anything, let me note that this is
surely an old question that has inspired its share of flame wars; I'm
new to Python, but not new to how Internet discussions work."
In that context, there is no way that this response was a flame. I find
that Pythoneers want to use the right tool for the job. This isn't
always Python. It might be Perl, or OCaml, or Java, or C, or JCL. If you
want static type checking, Python definitely isn't the right tool for you.
If you asked Java programmers why you couldn't turn *off* Java's static
type checking if you wanted to, you'd probably get a similar response.
--
Michael Hoffman
Paddy
> On Wed, Jun 20, 2007 at 12:59:28PM -0700, bruno.desthuilli...@gmail.com wrote:
> > Then you should use another language.
>
> This is what I meant about knowing how Internet discussions
> go.
>
And knowing that, why not take more care with the tone of
your original post, or do more searching and/or lurking
before posting?
Your original post *could* be paraphrased as:
I'm new to Python, Python doesn't have X, X is
obviously a great feature can't you give me X
in Python? P.S. Its obviously been debated before
but I haven't looked - send me a link. I know this
might start a flame war, but I'll ask anyway.
And sure enough, you then goad a regular *contributor*
to comp.lang.python .
I suggest you rephrase your question in a less
confrontational tone but only if you are interested
in civil answers.
- Paddy.
Paddy
>
> --
> Stephen R. Laniel
> s...@laniels.org
> Cell: +(617) 308-5571http://laniels.org/
> PGP key:http://laniels.org/slaniel.key
have you seen language Boo? It adds static typing to Python
inspired syntax: http://boo.codehaus.org/
- Paddy.
Stephen R Laniel
> If you asked Java programmers why you couldn't turn *off* Java's static
> type checking if you wanted to, you'd probably get a similar response.
Perhaps it would help for me to explain what I'd like.
Under both Perl and Python, I've found myself
having/wanting to write things like so:
def my_func( int_arg, str_arg ):
try:
int_arg = int( int_arg )
str_arg = str( str_arg )
except ValueError:
sys.stderr.write( "Args are not of the right type\n" )
sys.exit(1)
Granted, in a dynamic language we won't always (maybe "won't
often") have a situation where the types are known this well
at compile time. But sometimes we will. And it would be nice
to catch these before the program even runs.
So my question is: would bolting on "static type checking
when we can, no type checking when we can't" be too much
to ask?
My reason for asking initially was that the PEP adds all
kinds of information to the function prototype -- e.g.
(quoting from there)
def foobar( a: Integer, b: Sequence ) -> String:
so why not, I reasoned, use this information at compile
time?
Of course I understand the virtue of writing code with good
doctests, etc. But my question is why we can't get some more
static typing as well. Given the tools that'll be in Python
3.0, that doesn't seem unreasonable to ask.
Apparently it is unreasonable. I'm sorry I asked.
Diez B. Roggisch
> Of course I understand the virtue of writing code with good
> doctests, etc. But my question is why we can't get some more
> static typing as well. Given the tools that'll be in Python
> 3.0, that doesn't seem unreasonable to ask.
That is exactly the problem - there is no "some more" static typing.
There is static typing - or not. You can't have it "just a bit".
You can have type annotations to create guarding statements and then
allow better optimized code below that - if everything is "safe".
But static analysis that will allow for compiletime typing error checks
will need _all_ code to be statically typed.
And still not catch all runtime errors, which is basically an instance
of the halting problem.
The somewhat grumpy response you might have gotten is simply because the
whole subject has been discussed about a bazillion times - but never
ever somebody _created_ something that would work. Just asking for it
with vague ideas how that would create a better world.
Diez
George Sakkis
> Perhaps it would help for me to explain what I'd like.
>
> Under both Perl and Python, I've found myself
> having/wanting to write things like so:
>
> def my_func( int_arg, str_arg ):
> try:
> int_arg = int( int_arg )
> str_arg = str( str_arg )
> except ValueError:
> sys.stderr.write( "Args are not of the right type\n" )
> sys.exit(1)
After several hundreds of such checks, good luck making the 2.0
version of your application Unicode-friendly.
> Granted, in a dynamic language we won't always (maybe "won't
> often") have a situation where the types are known this well
> at compile time. But sometimes we will. And it would be nice
> to catch these before the program even runs.
Optional typing has its merits but your example is more of a
counterexample, an example where the explicit try/catch doesn't really
buy you anything. You'd get essentially the same effect if you just
attempted the conversion and let any exception propagate:
def my_func(some_non_hungarian_notation_meaningful_name,
other_non_hungarian_notation_meaningful_name):
a = int(some_non_hungarian_notation_meaningful_name)
b = str(other_non_hungarian_notation_meaningful_name)
More often than not the types that you *think* are required will turn
out to be more (and sometimes less) restrictive than necessary. Still,
If you're addicted to manifest typing [1], the typechecking module [2]
may give you a warm and fuzzy feeling:
from typecheck import accepts
@accepts(int, str)
my_func(some_non_hungarian_notation_meaningful_name,
other_non_hungarian_notation_meaningful_name):
HTH,
George
[1] http://c2.com/cgi/wiki?ManifestTyping
[2] http://oakwinter.com/code/typecheck/tutorial/basics.html
Ben Finney
> Perhaps it would help for me to explain what I'd like.
Thanks for taking the time to think about the request and re-formulate
it.
> Under both Perl and Python, I've found myself
> having/wanting to write things like so:
>
> def my_func( int_arg, str_arg ):
> try:
> int_arg = int( int_arg )
> str_arg = str( str_arg )
> except ValueError:
> sys.stderr.write( "Args are not of the right type\n" )
> sys.exit(1)
The first question that comes to mind -- and you'll find this question
asked of hundreds of people who come to this list with similar stated
goals -- is this: Why are you doing the above?
In Python, the pattern is to allow that exception to propagate back to
the code that tried to use the function, which is the one that is
apparently using the function incorrectly.
That is, you haven't actually told us what you'd like. You've shown us
a function that effectively does nothing but create a str and and int
-- and then discard them. What does this function need to do that you
want to catch an exception and abort inside the function?
--
\ "It is well to remember that the entire universe, with one |
`\ trifling exception, is composed of others." -- John Andrew |
_o__) Holmes |
Ben Finney
Terry Reedy
"Stephen R Laniel" <st...@laniels.org> wrote in message
news:20070620185...@slaniel-laptop.itasoftware.com...
|| Reading [1], I wonder: why isn't the compiler making better
| use of (purely optional) type labeling? Why not make a compiler
| directive so that
|
| a) it will check the types of all my arguments and return
| values, and maybe even
| b) do some type inference up the call stack?
|
| E.g.,
|
| def( Class1 arg1, Class2 arg2, ..., ClassN argN ):
| someStuff()
|
| would check the types of the arguments, whereas
|
| def( arg1, arg2, ..., argN):
| someStuff()
|
| would not? I.e., if I *want* strong static
| type-checking, why shouldn't I be able to get it?
1. Type checking arguments at compile time requires that the types of
arguments be known at compile time. Since arguments often are either names
or expressions using names, this would require that names be typed and that
all assigments to names be type-checked. In other words, static typing
pretty much all the way.
2. Python has multiple implementations. Any requirement such as this would
be a requirement on all. It is possible that there will be some
implementation that does something of what you want while the others
continue as they are. Or that there will be third-party add-ons (like
psyco today).
3. There are multiple possible uses of type annotations: documentation,
speed, error checking, and maybe others yet to be thought of. Mandating
any particular use would be a burden to anyone only interested in other
uses.
As an old-timer, I also do not initially see the point of annotation with
no (required) effect. But then I realized point 3 above.
I believe that the statement you interpreted as 'forbidding' static typing
was Guido's promise that annotations will *not* be a step towards turning
Python into something else -- a staticly typed language. That is important
to the many people who use Python *because* it is dynamically and not
statically typed and who consider that a net benefit.
Terry Jan Reedy
kaens
> That is exactly the problem - there is no "some more" static typing.
> There is static typing - or not. You can't have it "just a bit".
Couldn't a language be made so that if you declared a variable like, say:
string foo = "I'm a string"
it would be a string, and always a string, and if you declared a variable like
foo = "i'm a dynamic variable"
it would be considered dynamic?
This doesn't seem like it would be too hard to add in to a language
that already had dynamic typing (But then again, I am inexperienced -
although interested in - language design).
It seems to me like this could be really useful, but I'm not aware of
any language implementing something like this.
Alex Martelli
> On 6/20/07, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
> > That is exactly the problem - there is no "some more" static typing.
> > There is static typing - or not. You can't have it "just a bit".
>
> Couldn't a language be made so that if you declared a variable like, say:
>
> string foo = "I'm a string"
>
> it would be a string, and always a string, and if you declared a variable like
>
> foo = "i'm a dynamic variable"
>
> it would be considered dynamic?
It would surely be possible to design a language like that, yes. I
suspect that, if you wanted to have both names 'constrained to a type'
and others 'not constrained', it would be better to have more symmetry
between the two situations (e.g., the "duck" type in Boo); but many
languages exist to prove that inferior design choices are often taken.
> This doesn't seem like it would be too hard to add in to a language
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).
It would be extremely cumbersome to start from the implementation of a
language with dynamic typing and extend it to allow the static kind --
each and every name (and item of a container, etc, etc) would have to
carry around an extra pointer to a typechecking function (possibly null
for names that must not be checked). You'd have to carry the whole
mechanism around at runtime since many assignments could in fact not be
checked statically, of course -- consider assigning a "dynamic"
[unchecked] name to a "static" [checked] one, for example; but, more:
class Foo: ...
class Bar: ...
static Foo foo
static Bar bar
...
foo = bar
this kind of thing would also have to be checked at runtime, since there
might be around a
class FooBar(Foo, Bar): ...
and bar might validly be an instance of FooBar -- therefore ALSO an
instance of Foo, thus validly assignable to foo.
Basically, absent the kind of static analysis that you'd do for type
inferencing (study Boo, SML, or Haskell, to learn more about type
inferencing), VERY few assignments could be tagged as invalid at
compile-time in a language with multiple inheritance. Badly designed
static languages (ones without type inferencing) often try to hide that
by forcing the programmer to be redundant, e.g. in specifying a "cast",
but even then runtime checks are often necessary. E.g., even in Java,
Foo foo;
Bar bar;
...
bar = (Bar) foo;
implies a runtime check if either Foo or Bar is an interface (and
well-written OO programs should use interfaces, *NOT* concrete classes,
more often than not: cfr the classic "Design Patterns" book, or Lakos'
excelent book on large scale software in C++, for more about that).
In short, if you really want to avoid (as far as possible) runtime
checks, you should really use a language designed for type inferencing
(Boo is, and in some other ways it's reminiscent of Python; however
there are far more books &c for other languages such as SML and
Haskell). Or, you could read Robert Martin's classic essay at
<http://www.artima.com/weblogs/viewpost.jsp?thread=4639> and ponder
whether Uncle Bob might not have a point...
Alex
Evan Klitzke
> On 6/20/07, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
> > There is static typing - or not. You can't have it "just a bit".
>
>
> string foo = "I'm a string"
>
> it would be a string, and always a string, and if you declared a variable like
>
> foo = "i'm a dynamic variable"
>
> it would be considered dynamic?
>
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).
>
> any language implementing something like this.
I think the main issue is that while you _could_ do that, the fact
that the language allows dynamic variables essentially precludes the
possibility of doing static checks for type issues (see Terry's post
for a better explanation of the issue). So you are by and large not
going to catch type errors until runtime anyway, and this is a feature
that Python already provides (if you try to mix different types in an
incompatible way you'll get a TypeError). I think that raising an
exception is the correct way to deal with type errors in this context.
So it's not that this issue is useless, but rather that it isn't
useful enough to warrant someone implementing it. If there was a good
implementation, and people really liked it and saw how great it was, I
don't think there's any fundamental opposition to its inclusion in the
language. But this hasn't happened yet.
--
Evan Klitzke <ev...@yelp.com>
Bruno Desthuilliers
> On Wed, Jun 20, 2007 at 12:59:28PM -0700, bruno.des...@gmail.com wrote:
>> Then you should use another language.
>
> This is what I meant about knowing how Internet discussions
> go.
>
You said:
"I'm new to Python",
and then :
"if I *want* strong static type-checking, why shouldn't I be able to get
it?"
You obviously don't know Python enough to understand why static
typechecking doesn't belong to Python. Trying to explain would be a
waste of time, because you have to experiment it in real-life situation
to fully understand.
So to put things briefly, Python with static typechecking would not be
Python anymore - it would be another language. Which implies that if you
want static typechecking, you'll have to use another language one way or
another.
Diez B. Roggisch
> On 6/20/07, Diez B. Roggisch <de...@nospam.web.de> wrote:
>
>> That is exactly the problem - there is no "some more" static typing.
>> There is static typing - or not. You can't have it "just a bit".
>
> Couldn't a language be made so that if you declared a variable like, say:
>
> string foo = "I'm a string"
>
> it would be a string, and always a string, and if you declared a
> variable like
>
> foo = "i'm a dynamic variable"
>
> it would be considered dynamic?
>
> This doesn't seem like it would be too hard to add in to a language
> that already had dynamic typing (But then again, I am inexperienced -
> although interested in - language design).
It isn't too hard. All it needs is a bucket at a name that contains a
type reference.
But what you DO with that is the hard thing. Just enforcing types at
runtime is easy. Making JIT-compilation for such code and then put
guarding statements around it - somewhat harder, but easier than full
type inference.
But the OP wanted compile-time static typing checks. And _thats_
virtually impossible unless _everything_ is statically typed. And even
if it is, the ClassCastExceptions of Java prove that.
Take this classic example from the java-world that is statically
correct, but will fail at runtime
class A
class B extends A
B[] bs = new B[100];
A[] as = bs;
as[0] = new A();
The problem here is that the as-array has less type information, and
because of polymorphism rules is allowed to actually hold an B-array.
But that can't allow mere A-objects to be assigned to it!
So the JVM introduces a runtime type check here.
Mixing static and dynamic type information like proposed will only make
this problem more severe, as you know even less about your types. Thus
the whole purpose of static checking vanishes, and the whole thing
shifts to a purely runtime checking.
> It seems to me like this could be really useful, but I'm not aware of
> any language implementing something like this.
Which _might_ be a hint... :)
Diez
Bruno Desthuilliers
>> If you asked Java programmers why you couldn't turn *off* Java's static
>> type checking if you wanted to, you'd probably get a similar response.
>
> Perhaps it would help for me to explain what I'd like.
>
> Under both Perl and Python, I've found myself
> having/wanting to write things like so:
>
> def my_func( int_arg, str_arg ):
> try:
> int_arg = int( int_arg )
> str_arg = str( str_arg )
> except ValueError:
> sys.stderr.write( "Args are not of the right type\n" )
> sys.exit(1)
>
Just a question : what will happen if you get rid of the try/except
block ?-)
Méta-MCI
>Given that one can add/replace/remove methods and attributes
>dynamically either on a per-class or per-instance basis, and even
>dynamically change the class of an object, I fail to see how static
>typechecking could be meaningfull.
Et toc !
Bjoern Schliessmann
>> Then you should use another language.
>
> This is what I meant about knowing how Internet discussions
> go.
I agree. I also notice that (rather newbie-) OPs with not-so-simple
questions are easily offended by technical answers. I'd love to
know why.
Regards,
Björn
--
BOFH excuse #39:
terrorist activities
Stephen R Laniel
> I agree. I also notice that (rather newbie-) OPs with not-so-simple
> questions are easily offended by technical answers. I'd love to
> know why.
One doesn't like to get meta on such things, as so often
happens, so I'll be brief. The way I read my original post
was like so: "I know lots of people have probably had a
similar question, so please point me to a canonical answer
is there is one. So here's the question...". To me, an
appropriate answer there is, "That's a good question, and
many people have asked it. Here's why it's unlikely that
static type-checking makes sense in the context of Python,
and why it couldn't just be added in pieces." We got there
eventually, but only after what seemed to me to be a bout of
rudeness. Now, maybe my own followup clarified something
that I should have included in the original.
"Use another language" is not a technical answer. "Python
could not adopt static typing without substantially changing
the language and destroying what everyone loves about it,
and here are examples of where the problem shows up" is.
But I've just gone meta, so I'll stop.
Peter Decker
<usenet-mail-03...@spamgourmet.com> wrote:
> Stephen R Laniel wrote:
> > On Wed, Jun 20, 2007 at 12:59:28PM -0700,
> > bruno.des...@gmail.com wrote:
>
> >> Then you should use another language.
> >
> > This is what I meant about knowing how Internet discussions
> > go.
>
> I agree. I also notice that (rather newbie-) OPs with not-so-simple
> questions are easily offended by technical answers. I'd love to
> know why.
Oh, c'mon. The OP was asking for an explanation, and got an indignant
response. There is a world of difference between explaining *why*
Python is the way it is, and getting the equivalent of a 4-year-old's
"Because!" as a reply.
To someone who admits that he is largely unfamiliar with the language,
it would seem obvious that Python is "lacking" something that is
important in other languages. An explanation as to why this would be
Bad Thing for Python would be a helful response.
--
# p.d.
Stephen R Laniel
> "Use another language" is not a technical answer. "Python
> could not adopt static typing without substantially changing
> the language and destroying what everyone loves about it,
> and here are examples of where the problem shows up" is.
The best dynamic-versus-static-typing discussion I've ever
seen, by the way, was Mark-Jason Dominus's (he of
"Higher-Order Perl"):
http://perl.plover.com/yak/typing/notes.html
Bruno Desthuilliers
(snip)
> Oh, c'mon. The OP was asking for an explanation, and got an indignant
> response. There is a world of difference between explaining *why*
> Python is the way it is, and getting the equivalent of a 4-year-old's
> "Because!" as a reply.
<because mode="40-years-old">
Python is the way it is because the creator of the language decided to
make it so.
</because>
More seriously, wrt/the dynamic vs static typing religion war, any
developer familiar with usenet should be able to find endless threads
covering the topic, so I don't see any need for one more.
> To someone who admits that he is largely unfamiliar with the language,
> it would seem obvious that Python is "lacking" something that is
> important in other languages.
To someone who is only familiar with declarative static typing. One can
be unfamiliar with Python but familiar with one (or more) of the many
other dynamic languages around...
> An explanation as to why this would be
> Bad Thing for Python would be a helful response.
Did you actually bother to read the full answer ? If so, you missed the
explanation, so let's quote it:
"""
Given that one can add/replace/remove methods and attributes
dynamically either on a per-class or per-instance basis, and even
dynamically change the class of an object, I fail to see how static
typechecking could be meaningfull.
""
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.
Carsten Haese
> "Use another language" is not a technical answer.
The very same post you're referring to did give a technical answer two
paragraphs down:
"""
Given that one can add/replace/remove methods and attributes
dynamically either on a per-class or per-instance basis, and even
dynamically change the class of an object, I fail to see how static
typechecking could be meaningfull.
"""
--
Carsten Haese
http://informixdb.sourceforge.net
Carsten Haese
> On 6/21/07, Bjoern Schliessmann
> <usenet-mail-03...@spamgourmet.com> wrote:
> > > On Wed, Jun 20, 2007 at 12:59:28PM -0700,
> > > bruno.des...@gmail.com wrote:
> >
> > >> Then you should use another language.
> > >
> > > This is what I meant about knowing how Internet discussions
> > > go.
> >
> > I agree. I also notice that (rather newbie-) OPs with not-so-simple
> > questions are easily offended by technical answers. I'd love to
> > know why.
>
> response.
Actually, no, Bruno gave a tongue-in-cheek response accompanying a
technical answer. The OP chose to turn it into an indignant response by
taking one sentence out of context and snipping the pertinent technical
part of Bruno's response.
Kay Schluehr
> Reading [1], I wonder: why isn't the compiler making better
> use of (purely optional) type labeling? Why not make a compiler
> directive so that
>
> a) it will check the types of all my arguments and return
> values, and maybe even
> b) do some type inference up the call stack?
That's simply because no one knows about the effects it has on Pythons
programming practices. Hence it is outsourced to "3rd party packages"
and these can be x-compilers as well that do all the inference stuff
and translate to Pyrex, C++, D or any other language having an
appropriate bridge. This stuff is simply beyond Python 3.0 and might
be addressed in subsequent versions such as Python 3.1 or Python 3.2
when experiences are collected with different "annotations handlers".
kaens
> On Thu, Jun 21, 2007 at 10:11:57AM -0400, Stephen R Laniel wrote:
> > "Use another language" is not a technical answer. "Python
> > could not adopt static typing without substantially changing
> > the language and destroying what everyone loves about it,
> > and here are examples of where the problem shows up" is.
>
> The best dynamic-versus-static-typing discussion I've ever
> seen, by the way, was Mark-Jason Dominus's (he of
> "Higher-Order Perl"):
> http://perl.plover.com/yak/typing/notes.html
>
> Stephen R. Laniel
> st...@laniels.org
> Cell: +(617) 308-5571
> http://laniels.org/
> PGP key: http://laniels.org/slaniel.key
> http://mail.python.org/mailman/listinfo/python-list
>
This really cleared some stuff up for me, thanks.
Robert Brown
> often") have a situation where the types are known this well
> at compile time. But sometimes we will. And it would be nice
> to catch these before the program even runs.
>
> So my question is: would bolting on "static type checking
> when we can, no type checking when we can't" be too much
> to ask?
Common Lisp allows the programmer to optionally provide type declarations to
improve readability or performance. Certain implementations of Common Lisp,
such as cmucl and sbcl, check type declarations at compile time, employ type
interence to generate efficient machine code, and insert run time checks
when the compiler can't prove at compile time that variables have their
declared types.
John Nagle
> That's simply because no one knows about the effects it has on Pythons
> programming practices. Hence it is outsourced to "3rd party packages"
> and these can be x-compilers as well that do all the inference stuff
> and translate to Pyrex, C++, D or any other language having an
> appropriate bridge. This stuff is simply beyond Python 3.0 and might
> be addressed in subsequent versions such as Python 3.1 or Python 3.2
> when experiences are collected with different "annotations handlers".
More interesting than optional annotations are the restrictions of
ShedSkin, which forbid some changing of variable types. This allows
some significant optimizations.
If you accept the ShedSkin or Psyco restrictions, you get most of the
performance advantages of strong typing without all the verbosity of
explicit typing.
PEP 3107 seems to add negative value to the language. The
ability to add arbitrary attributes to parameters which can then
be interpreted by some external library yet to be defined is
a "l33t feature", one that's more cute than useful. Type-based
dispatching is cute, but not really essential to Python.
(PEAK, the main effort in that direction, seems to be defunct.)
What we need are better implementations than CPython, not
hokey attribute schemes bolted onto the language. We're seeing
stuff go in that's easy to add to CPython, but not necessarily
good for the language as a whole.
John Nagle
Paul Rubin
> What we need are better implementations than CPython, not
> hokey attribute schemes bolted onto the language. We're seeing
> stuff go in that's easy to add to CPython, but not necessarily
> good for the language as a whole.
I think it was a real loss that Python 3.0 proposals were closed
before PyPy was widely deployed and we had a chance to get more
experience with it.
Dave Baum
kaens <apatheti...@gmail.com> wrote:
Common Lisp has a mechanism similar to what you described. In general,
variables are completely dynamic. However, it is possible to declare
individual variables to be of specific types. There are also
declarations that allow you to specify your preferences for speed versus
safety. The upshot of all of this is that the language is a dynamic
language most of the time, but the programmer can choose to give the
compiler a bit more information, and with that information a good
compiler can generate more efficient code (often competitive with the
speed of C code).
The Common Lisp approach is not without its problems (for one thing, a
lot of the behavior when type declarations are not met is implementation
dependent). But I think there are some ideas in there that could be
applied to Python.
On the other hand, I'm pretty happy with Python/SWIG/C++ for performance
critical code, so I'm not sure if optional static typing would really be
of much use unless the Python compiler got *very* good at generating
optimized code when declarations were present.
I still think it would be handy to easily specify the expected types of
function arguments. I sometimes write code in this pattern:
def foo(a, b):
"a, b - instances of Bar"
assert isinstance(a, Bar)
assert isinstance(b, Bar)
# do some stuff
Note that the expectation that 'a' and 'b' are to be of type Bar is
specified twice: once for a runtime check, once for the docstring. It
might be nice if there were a mechanism to specify it once and have the
docstring and runtime check both make use of that information:
>>>def foo(Bar a, Bar b):
>>> # do some stuff
>>>foo(1, Bar())
TypeError: argument a is not of type Bar
>>>help(foo)
foo(Bar a, Bar b)
On the downside, this sort of mechanism might do more harm than good.
For one thing, it would really clash with duck typing. For another,
anyone coming to Python from Java/C++ would probably use those
declarations *everywhere*, even when there isn't a good reason to limit
the type.
Dave
Ben Finney
> I think it was a real loss that Python 3.0 proposals were closed
> before PyPy was widely deployed and we had a chance to get more
> experience with it.
I think it's great that we're going to get Python 3.0 soon, and that
Python 4.0 proposals will benefit from a long period of familiarity
with widely-deployed PyPy :-)
--
\ "I bought some batteries, but they weren't included; so I had |
`\ to buy them again." -- Steven Wright |
_o__) |
Ben Finney
Alex Martelli
...
> I still think it would be handy to easily specify the expected types of
> function arguments. I sometimes write code in this pattern:
>
> def foo(a, b):
> "a, b - instances of Bar"
> assert isinstance(a, Bar)
> assert isinstance(b, Bar)
> # do some stuff
so in 3.0 you'll be able to spell that
@checkanddoc
def foo(a: Bar, b: Bar): ...
for some suitable decorator checkanddoc (and be assured that there will
be a bazillion such decorators written to exploit the new syntax, of
varying intent and quality). That's why 3.0 introduces that syntax
(args can be spelled <name>:<expr>) without giving it any semantics
beyond the fact that the info is recorded with the function object and
can be introspected from it -- enabling a thousand flowers to bloom in
terms of such decorators.
> On the downside, this sort of mechanism might do more harm than good.
> For one thing, it would really clash with duck typing. For another,
> anyone coming to Python from Java/C++ would probably use those
> declarations *everywhere*, even when there isn't a good reason to limit
> the type.
Sure, even more than they currently use wanton isinstance calls (or even
worse, type(x)==... checks). But hopefully the new "syntax hook" will
also allow GOOD decorators to emerge (e.g., ones doing adaptation rather
than mere checks).
Alex
Paul Boddie
wrote:
>
> I think it's great that we're going to get Python 3.0 soon, and that
> Python 4.0 proposals will benefit from a long period of familiarity
> with widely-deployed PyPy :-)
I'm not going to name and shame anyone, but here's part of a genuine
docstring from a program I downloaded not so long ago:
It was tested for python 4.0. It certainly doesn't work for python
versions earlier than 3.3.
If I need to speculate about future Python versions, I know who to
ask. ;-)
Paul
P.S. I agree with the sentiment that the annotations feature of Python
3000 seems like a lot of baggage. Aside from some benefits around
writing C/C++/Java wrappers, it's the lowest common denominator type
annotation dialect that dare not be known as such, resulting from a
lack of consensus about what such a dialect should really do, haunted
by a justified fear of restrictive side-effects imposed by a more
ambitious dialect (eg. stuff you get in functional languages) on
dynamically-typed code. I don't think the language should be modified
in ways that only provide partial, speculative answers to certain
problems when there's plenty of related activity going on elsewhere
that's likely to provide more complete, proven answers to those
problems.
John Nagle
> P.S. I agree with the sentiment that the annotations feature of Python
> 3000 seems like a lot of baggage. Aside from some benefits around
> writing C/C++/Java wrappers, it's the lowest common denominator type
> annotation dialect that dare not be known as such, resulting from a
> lack of consensus about what such a dialect should really do, haunted
> by a justified fear of restrictive side-effects imposed by a more
> ambitious dialect (eg. stuff you get in functional languages) on
> dynamically-typed code. I don't think the language should be modified
> in ways that only provide partial, speculative answers to certain
> problems when there's plenty of related activity going on elsewhere
> that's likely to provide more complete, proven answers to those
> problems.
I agree. It's a wierd addition to the language. It looks like
a compromise between the "no declarations" position and the "make
the language strongly typed" position. But it's so ill-defined that
it's not helpful, and worse than either extreme. The whole
approach is antithetical to the "only one way to do it" concept.
This could lead to misery when different libraries use
incompatible type annotation systems, which is not going to be fun.
Python made it this far without declarations, and programmers
seem to like that. We need to get Python performance up, and
the ShedSkin/Psyco restrictions seem to be enough to allow that.
Type annotations don't seem to solve any problem that really needs
to be solved.
The main advantage of strongly typed systems is that more errors
are detected at compile time. You pay for this in additional language
baggage. PEP 3107 adds the excess baggage without providing the benefit
of compile time checks.
John Nagle
Eduardo "EdCrypt" O. Padoan
Remember that pure CPython has no different "compile time" and
runtiime. But Psyco and ShedSkin could use the annotations the way
they want.
Function annotations, as PEP 3107 says, just adds "arbitrary metadata
annotations to Python functions" - If you follow the py-dev discutions
about it, it was only accepted because it have more possible uses then
just type checking. Also, there are many approches and different needs
for type checking/restrictions ("safety", IDEs autocompletion hints,
performance... )
So the annotations will be more a "signature documentation", so
different libraries can do whatever it want of it - I problably will
use only as documentation, like in:
def compile(source: "something compilable",
filename: "where the compilable thing comes from",
mode: "is this a single statement or a suite?"):
--
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
Michael Hoffman
Yes, it does.
--
Michael Hoffman
Kay Schluehr
> PEP 3107 seems to add negative value to the language. The
> ability to add arbitrary attributes to parameters which can then
> be interpreted by some external library yet to be defined is
> a "l33t feature", one that's more cute than useful. Type-based
> dispatching is cute, but not really essential to Python.
I guess you refer to the generic functions PEP. Otherwise type based
dispatching is what Psyco does implicitely by caching variants of
natively compiled code blocks that can be considered as anonymous
functions. But then Psyco has to perform continous measurements and
either select a precompiled block if an appropriate signature has been
found or return code to the bytecode interpreter for further
evaluation. This scheme is an example for type directed evaluation
that does not interfere with Pythons default semantics.
Personally I appreciate having more control over expressions by means
of annotations. I also do think it's valuable for component adaptions.
So far I fail to see why it shall harm Python or having any impact on
its flexibility. Being "unusal" is not an argument neither are vague
apprehensions that Python will be locked into a poor type system with
rigid default semantics.
Kay
tony.t...@gmail.com
> Before I ask anything, let me note that this is surely an
> old question that has inspired its share of flame wars; I'm
> new to Python, but not new to how Internet discussions work.
> So if there's a canonical thread or web page that documents
> the whole battle, feel free to point me to it.
>
> Reading [1], I wonder: why isn't the compiler making better
> use of (purely optional) type labeling? Why not make a compiler
> directive so that
>
> a) it will check the types of all my arguments and return
> values, and maybe even
> b) do some type inference up the call stack?
>
You might like to look at traits http://code.enthought.com/traits/
harri
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.
The language Pyrex uses combines dynamic and static typing in a very
useful manner.
"Practicality beats purity"
Harri
paul
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
> Bruno Desthuilliers schrieb:
> 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
> Bruno Desthuilliers schrieb:
>> Stephen R Laniel a écrit :
>>> On Wed, Jun 20, 2007 at 09:41:09PM +0100, Michael Hoffman wrote:
>>>> If you asked Java programmers why you couldn't turn *off* Java's
>>>> static type checking if you wanted to, you'd probably get a similar
>>>> response.
>>> Perhaps it would help for me to explain what I'd like.
>>>
>>> Under both Perl and Python, I've found myself
>>> having/wanting to write things like so:
>>>
>>> def my_func( int_arg, str_arg ):
>>> try:
>>> int_arg = int( int_arg )
>>> str_arg = str( str_arg )
>>> except ValueError:
>>> sys.stderr.write( "Args are not of the right type\n" )
>>> sys.exit(1)
>>>
>>
>> Just a question : what will happen if you get rid of the try/except
>> block ?-)
>>
> 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
> 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."
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
Paul Boddie <pa...@boddie.org.uk> wrote:
Software type checking (static, dynamics, whatever) is for weenies. Real
men use hardware type checking. Google "Burroughs B5000".
Bruno Desthuilliers
>> Indeed - static typing is for compilers, not for programmers.
>
> 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
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
Bruno Desthuilliers
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 ?
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"?
Donn Cave
Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> wrote:
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, do...@u.washington.edu
Eduardo "EdCrypt" O. Padoan
> On Thu, Jun 28, 2007 at 09:08:16AM +0200, Bruno Desthuilliers wrote:
> > 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.
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? :P
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
>> You said ?
>
> 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.
sjde...@yahoo.com
> On Thu, Jun 28, 2007 at 09:08:16AM +0200, Bruno Desthuilliers wrote:
> > 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"?
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
> John Nagle <n...@animats.com> wrote:
> > 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.*).
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 :
>> Actually, static typing is for detecting errors before the
>> program is run.
>
> 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
--
BOFH excuse #198:
Post-it Note Sludge leaked into the monitor.
Bruno Desthuilliers
> Bruno Desthuilliers wrote:
>> John Nagle a écrit :
>
>>> Actually, static typing is for detecting errors before the
>>> program is run.
>> 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?
Nope, he just asserted something wrong. Static typing is for compiler
optimization. Type checking is at most a side effect, and in some
languages (at least C, C++ and Java) can be totally defeated (usually
using typecasting).
Paul Rubin
> Nope, he just asserted something wrong. Static typing is for compiler
> optimization. Type checking is at most a side effect, and in some
> languages (at least C, C++ and Java) can be totally defeated (usually
> using typecasting).
"Definitions of type system vary, but the following one due to
Benjamin C. Pierce roughly corresponds to the current consensus in
the programming language theory community:
[A type system is a] tractable syntactic method for proving the
absence of certain program behaviors by classifying phrases
according to the kinds of values they compute. (Pierce 2002)."
-- http://en.wikipedia.org/wiki/Type_theory#Type_system
C and C++ are basically untyped languages. Java casts can only
partially defeat its type system, so it's not untyped.
Bruno Desthuilliers
> Bruno Desthuilliers <bruno.42.de...@wtf.websiteburo.oops.com> writes:
>
>>Nope, he just asserted something wrong. Static typing is for compiler
>>optimization. Type checking is at most a side effect, and in some
>>languages (at least C, C++ and Java) can be totally defeated (usually
>>using typecasting).
>
>
> "Definitions of type system vary, but the following one due to
> Benjamin C. Pierce roughly corresponds to the current consensus in
> the programming language theory community:
>
> [A type system is a] tractable syntactic method for proving the
> absence of certain program behaviors by classifying phrases
> according to the kinds of values they compute. (Pierce 2002)."
Is this supposed to contradict my assertion that *static* typing is for
compilers ?
C (and C++) are statically typed. It's usually agreed that C is weakly
typed, and that C++ is somewhat more strongly typed. In both cases, you
can totally defeat compile-time type-checking, with possibly some very
unpredictable results. Python is dynamically typed, but doesn't allow
the kind of results you can get from a C typecast.
> -- http://en.wikipedia.org/wiki/Type_theory#Type_system
> C and C++ are basically untyped languages.
Hem... This assertion is at least debatable. Care to post this on c.l.c
or c.l.c++, so we get some feedback ?
> Java casts can only
> partially defeat its type system,
In Java, an erroneous typecast will result in a runtime error. Where's
the benefit of static typechecking if you can get type errors at runtime?
Bruno Desthuilliers
(snip)
> It looks like
> a compromise between the "no declarations" position and the "make
> the language strongly typed" position.
(snip)
> The main advantage of strongly typed systems is that more errors
> are detected at compile time.
(snip)
s/strongly/statically/
1/ strong typing is not necessarily static typing,
2/ static typing is not necessarily strong typing
3/ dynamic typing is not necessarily weak typing
4/ static typing is not necessarily declarative (ever heard of
type-inference based systems ?)
Bruno Desthuilliers
> On 6/22/07, John Nagle <na...@animats.com> wrote:
> Remember that pure CPython has no different "compile time" and
> runtiime.
Oh yes ? So what's the compiler doing, and what are those .pyc files ?
(hint: read the doc)
Paul Rubin
> > [A type system is a] tractable syntactic method for proving the
> > absence of certain program behaviors by classifying phrases
> > according to the kinds of values they compute. (Pierce 2002)."
>
> Is this supposed to contradict my assertion that *static* typing is
> for compilers ?
Yes, the main benefit these days is to prove the absence of certain
types of bugs in the program.
The article "What To Know Before Debating Type Systems" is pretty
informative (though it doesn't go as far as to call C/C++ untyped):
http://cdsmith.twu.net/types.html
> > C and C++ are basically untyped languages.
>
> Hem... This assertion is at least debatable. Care to post this on
> c.l.c or c.l.c++, so we get some feedback ?
I wouldn't consider the aficionados of those dinosaur languages to be
authorities on such a question.
Bruno Desthuilliers
> Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> writes:
>
>>> [A type system is a] tractable syntactic method for proving the
>>> absence of certain program behaviors by classifying phrases
>>> according to the kinds of values they compute. (Pierce 2002)."
>>
>>Is this supposed to contradict my assertion that *static* typing is
>>for compilers ?
>
> Yes, the main benefit these days is to prove the absence of certain
> types of bugs in the program.
As someone said, if declaring types thrices was enough to ensure
correctness, I'd happily do so.
I still maintain that the primary *practical* reason behind static
typing is to provide optimization clues for the compiler. You can (or at
least could) have declarative static typing with very few type
*checking* - I may be wrong here but I think one could even write a C
compiler without *any* type checking. Heck, the programmer said it's a
char*, so it must be one, right ?-) Of course, no one in it's own mind
would use such a compiler (if you have to suffer from the restrictions
imposed by static typing, you want to also profit from it's benefices -
or at least avoid the possibly dramatic effects of a type error in these
systems). Also, some (mostly) dynamically typed languages have grown
type-annotations for the very same reason : hinting the compiler about
possible optimizations.
wrt/ proofs of correctness, I'll just point to the spectacular failure
of Ariane, which was caused by a *runtime* type error in a system
programmed in ADA - one of the languages with the most psychorigid
declarative static type systems. Not to say these proofs are inexistant,
just that they are IMHO a bit overvalued - at least wrt/ to my daily
concerns. Most of the errors I have to deal with are logical errors, not
type errors, and given the kind of "logic" (err...) you can find in
business applications (to make a long story short : it has very few to
do with mathematics), I have some doubt about what a static type system
- even a _very_ smart one - could prove here, at least if we hope to
deliver the application within time and budget constraints (sorry for
being soo practical here).
> The article "What To Know Before Debating Type Systems" is pretty
> informative (though it doesn't go as far as to call C/C++ untyped):
>
> http://cdsmith.twu.net/types.html
Quote :
"""
Therefore: I give the following general definitions for strong and weak
typing, at least when used as absolutes:
* Strong typing: A type system that I like and feel comfortable with
* Weak typing: A type system that worries me, or makes me feel
uncomfortable
"""
According to this definition, I herefore declare that Python is strongly
typed and Java weakly typed !-)
(sorry, couldn't resist).
More seriously, it's indeed an interesting article - even if I do not
necessarily share all the views of the author - for those not knowing
anything about type systems. But it's clearly a bit oriented and IMHO
fails to present the pros of dynamic typing.
BTW, if I may insert another quote, that I think is relevant here as
well as in another recent thread about 'typed' containers in Python:
"""
I find it amusing when novice programmers believe their main job is
preventing programs from crashing. I imagine this spectacular failure
argument wouldn't be so appealing to such a programmer. More
experienced programmers realize that correct code is great, code that
crashes could use improvement, but incorrect code that doesn't crash is
a horrible nightmare.
"""
>
>>>C and C++ are basically untyped languages.
>>
>>Hem... This assertion is at least debatable. Care to post this on
>>c.l.c or c.l.c++, so we get some feedback ?
>
> I wouldn't consider the aficionados of those dinosaur languages
Hmmm... For a dinausor, C seems well alive. Can you remind me which
language is used to implement CPython and most of actual operating
systems and low-level libraries ?
> to be
> authorities on such a question.
If you mean that most them aren't necessarily great CS theorists, then
you may be right. OTHO, they do have some practical experience with
these languages, so they might have something to say...
Eduardo "EdCrypt" O. Padoan
> Eduardo "EdCrypt" O. Padoan a écrit :
> > runtiime.
>
> Oh yes ? So what's the compiler doing, and what are those .pyc files ?
> (hint: read the doc)
Sorry, I surely know that Python has a compile time, I wanted to say
somthing like "compile time checks except from syntax". My intention
was to show that a *huge* change in the Python interpretation model
would be needed to allow what he wanted, but I finished my email too
early :P
And yes, I readed the docs :)
Alex Martelli
...
> I still maintain that the primary *practical* reason behind static
> typing is to provide optimization clues for the compiler. You can (or at
It's definitely a helpful aspect, yes -- given that compilers able to
infer types are still not very common for widely used languages; also,
complete type checking or inference requires analysis of the whole
program, which may be quite impractical -- and stops what Van Roy and
Haridi, in their masterpiece "Concepts, Techniques and Models of
Computer Programming", call "totally open programming". Quoting a post
of mine from 2004:
"""
I love the explanations of Van Roy and Haridi, p. 104-106 of their book,
though I may or may not agree with their conclusions (which are
basically that the intrinsic difference is tiny -- they point to Oz and
Alice as interoperable languages without and with static typing,
respectively), all the points they make are good. Most importantly, I
believe, the way dynamic typing allows real modularity (harder with
static typing, since type discipline must be enforced across module
boundaries), and "exploratory computing in a computation model that
integrates several programming paradigms".
"Dynamic typing is recommended", they conclude, "when programs must be
as flexible as possible". I recommend reading the Agile Manifesto to
understand why maximal flexibility is crucial in most real-world
application programming -- and therefore why, in said real world rather
than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
dynamic typing is generally preferable, and not such a tiny issue as
they make the difference to be. Still, they at least show more
awareness of the issues, in devoting 3 excellent pages of discussion
about it, pros and cons, than almost any other book I've seen -- most
books have clearly delineated and preformed precedence one way or the
other, so the discussion is rarely as balanced as that;).
"""
> least could) have declarative static typing with very few type
> *checking* - I may be wrong here but I think one could even write a C
> compiler without *any* type checking. Heck, the programmer said it's a
> char*, so it must be one, right ?-)
That compiler, I believe, would violate the ISO standard for C (so
calling it a "C compiler" would be about as correct as calling it a
banana, in my view:-).
> wrt/ proofs of correctness, I'll just point to the spectacular failure
> of Ariane, which was caused by a *runtime* type error in a system
I like a quote by Knuth -- "beware this program may have bugs as I have
only proven it and not tested it":-)
> Hmmm... For a dinausor, C seems well alive. Can you remind me which
So do chickens.
Alex
Bruno Desthuilliers
> Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> wrote:
> ...
>
>>I still maintain that the primary *practical* reason behind static
>>typing is to provide optimization clues for the compiler. You can (or at
>
>
> It's definitely a helpful aspect, yes -- given that compilers able to
> infer types are still not very common for widely used languages;
or given that languages using a type-inferenced based system are not
very widely used...
(snip)
>>least could) have declarative static typing with very few type
>>*checking* - I may be wrong here but I think one could even write a C
>>compiler without *any* type checking. Heck, the programmer said it's a
>>char*, so it must be one, right ?-)
>
>
> That compiler, I believe, would violate the ISO standard for C (so
> calling it a "C compiler" would be about as correct as calling it a
> banana, in my view:-).
Lol. That being said, there were bananas - oops, I meant C compilers -
before the standard existed !-)
>
>>wrt/ proofs of correctness, I'll just point to the spectacular failure
>>of Ariane, which was caused by a *runtime* type error in a system
>
>
> I like a quote by Knuth -- "beware this program may have bugs as I have
> only proven it and not tested it":-)
Yeps.
>
>>Hmmm... For a dinausor, C seems well alive. Can you remind me which
>
> So do chickens.
>
I'm afraid I didn't get the joke... Are you saying that C is a rather,
well, primitive language ?
Diez B. Roggisch
> wrt/ proofs of correctness, I'll just point to the spectacular failure
> of Ariane, which was caused by a *runtime* type error in a system
> programmed in ADA - one of the languages with the most psychorigid
> declarative static type systems.
That's simply not true. The problem hadn't to do with typing - it was a
overflow due to larger input quantities. It had been shown for the
Ariane 4 that this overrun could never happen - by whatever thechnique,
operational or denotational semanticse, I don't know.
For the ariane 5, these input constraints didn't hold, which caused the
unexpected runtime error to occur.
But there is _no_ type-error here! The programmers might have chosen a
different type with larger range, sure. But to say that's a type error
is as saying "using a string where a tuple of int and string were better
is a type error." It's another path of implementation.
Or from a testing angle: if the unit tests did only produce input values
to a certain quantity, the results were ok. Nobody thought about writing
new tests with larger quantities - the same way nobody thought about
proving the program with those same quantities.
Diez
Bruno Desthuilliers
>>
>> wrt/ proofs of correctness, I'll just point to the spectacular failure
>> of Ariane, which was caused by a *runtime* type error in a system
>> programmed in ADA - one of the languages with the most psychorigid
>> declarative static type systems.
>
>
> That's simply not true. The problem hadn't to do with typing - it was a
> overflow due to larger input quantities.
cf below.
> It had been shown for the
> Ariane 4 that this overrun could never happen - by whatever thechnique,
> operational or denotational semanticse, I don't know.
IIRC it was in the specs.
> For the ariane 5, these input constraints didn't hold, which caused the
> unexpected runtime error to occur.
"""
Because of the different flight path, a data conversion from a 64-bit
floating point to 16-bit signed integer value caused a hardware
exception (more specifically, an arithmetic overflow, as the floating
point number had a value too large to be represented by a 16-bit signed
integer).
"""
As far as I'm concerned, it surely qualifies as a runtime type error -
"data conversion from a floating point to a 16-bit signed int" should
not be allowed when unsafe, isn't it ?
"""
Efficiency considerations had led to the disabling of the software
handler (in Ada code) for this error trap.
"""
Which implies that even in ADA, runtime type errors are in fact expected
- else there would be no handler for such a case.
The root of the problem is - of course - not technical but human. As you
said, no one cared to write the appropriate unit tests to ensure this
module - specified for Ariane 4 - could be reused 'as is' for Ariane 5.
But what, how could an ADA module not be correct if it compiles - the
ADA type system is here to "prove the absence of certain bugs", isn't it ?-)
Paddy
>
> >>> [A type system is a] tractable syntactic method for proving the
> >>> absence of certain program behaviors by classifying phrases
> >>> according to the kinds of values they compute. (Pierce 2002)."
>
> >>Is this supposed to contradict my assertion that *static* typing is
> >>for compilers ?
>
> > Yes, the main benefit these days is to prove the absence of certain
> > types of bugs in the program.
>
> As someone said, if declaring types thrices was enough to ensure
> correctness, I'd happily do so.
>
> I still maintain that the primary *practical* reason behind static
> typing is to provide optimization clues for the compiler.
The primary *practical* reason for static typing is that it allows
large software companies to convince customers that they have *the*
method to allow them to apply divide & conquer techniques to solve
their problems with a large team of programmers and justifying
large fees.
How many of those cancelled UK government software projects that
cost me hundreds of millions of pounds were programmed by people
espousing the greater safety of their static typing?
- Paddy.
Alex Martelli
> >
> > So do chickens.
> >
> I'm afraid I didn't get the joke... Are you saying that C is a rather,
> well, primitive language ?
The joke's just based on the fact that (based on DNA analysis) birds are
said to be dinosaurs, and are definitely "well alive":-).
Alex
Diez B. Roggisch
> """
> Because of the different flight path, a data conversion from a 64-bit
> floating point to 16-bit signed integer value caused a hardware
> exception (more specifically, an arithmetic overflow, as the floating
> point number had a value too large to be represented by a 16-bit signed
> integer).
> """
>
> As far as I'm concerned, it surely qualifies as a runtime type error -
> "data conversion from a floating point to a 16-bit signed int" should
> not be allowed when unsafe, isn't it ?
I wouldn't say so. The conversion is a partial function. It _has_ to be
a partial function, as you can't cram 64 bit into 16 without losses. If
you could, infinite compression would be possible.
So - you _have_ to allow such a conversion. That has nothing to do with
types, the types were proper. The values weren't.
> """
> Efficiency considerations had led to the disabling of the software
> handler (in Ada code) for this error trap.
> """
>
> Which implies that even in ADA, runtime type errors are in fact expected
> - else there would be no handler for such a case.
Well, yes, runtime errors occur - in statically typed languages as well.
That's essentially the halting-problem.
> But what, how could an ADA module not be correct if it compiles - the
> ADA type system is here to "prove the absence of certain bugs", isn't
> it ?-)
Yes, certain bugs. Not those though. In the same sense as the python
compiler pukes statically on me if I write
def f():
n = x * 2
x = n
The whole point of the Ariane failure was that nobody believed in the
code because the type analyzer had woven it through - but because the
specs and a mathematical analysis of the code had shown it was to be
trusted. For the old rocket, that was.
The question is not if static typing that prevents certain errors is a
bad thing. It's not. But it comes with a pricetag - the lack of
flexibility. And usually, I'm not willing to pay that price, because it
makes my whole design much more cumbersome and thus often error-prone -
as line numbers increase.
But in a constrained environment like the ariane, where you have limited
resources, you want as much certainity as you can get, together with
operations that run on the native types of your processor in an
efficient way.
Diez
Donn Cave
al...@mac.com (Alex Martelli) wrote:
> "Dynamic typing is recommended", they conclude, "when programs must be
> as flexible as possible". I recommend reading the Agile Manifesto to
> understand why maximal flexibility is crucial in most real-world
> application programming -- and therefore why, in said real world rather
> than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
> dynamic typing is generally preferable, and not such a tiny issue as
> they make the difference to be.
I guess there may be more than one kind of flexibility. The language
I fool around with sometimes that has strong static typing is Haskell.
Though a relatively elementary Haskell programmer (the learning curve
with this language is something you would have to experience to believe),
I feel that the type checking actually helps me program faster.
The compiler's check for structural correctness is after all for my
benefit, and expedites development and maintenance of code, in my
limited experience. The more extensive my changes, the more useful
the type checking is - I'm much more casual about significant code
revision when writing in Haskell, somewhat more casual when writing
in C, and worried when writing Python.
This is the kind of flexibility where you make significant changes
to something, but the result is as structurally consistent as it
would have been if written that way from the start. I have also
seen the kind of flexibility where you use expedient hacks to make
changes with relatively small amounts of code, and I've seen it in
Python applications. It's flexibility when you're doing it, but
it paradoxically causes rigidity as the hacks create more points
of articulation and more things that aren't obvious to the person
making the changes. If that's flexibility, you can have it.
Donn Cave, do...@u.washington.edu
Steve Holden
it's fair to single Python out as a potential problem. As we have known
for a long time you can write unstructured code in almost any language,
and you can do structured programming in almost any language given
discipline.
I certainly agree that if the programmer shows insufficient discipline
the results will likely be bad, but in that light Haskell is really the
ultimate bondage language. Some of us don't like to be tied that tightly.
I don't feel the same trepidation you appear to do when refactoring
Python code. I suppose I might say that in my experience Python allows
you to appreciate a better-engineered solution more easily, and so it
tends to encourage better engineering.
In some ways C# is quite Python-like, and I am beginning to enjoy
writing it from time to time, but when you are dealing with amorphous
collections the casting and conversions can drive you almost insane. And
since the collections are ultimately collections of Object, none of it
actually gets you any nearer your programming goal.
regards
Steve
--
Steve Holden +1 571 484 6266 +1 800 494 3119
Holden Web LLC/Ltd http://www.holdenweb.com
Skype: holdenweb http://del.icio.us/steve.holden
--------------- Asciimercial ------------------
Get on the web: Blog, lens and tag the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------
Alex Martelli
> In article <1i0ikru.1uccqtm1efnzn3N%al...@mac.com>,
> al...@mac.com (Alex Martelli) wrote:
>
> > "Dynamic typing is recommended", they conclude, "when programs must be
> > as flexible as possible". I recommend reading the Agile Manifesto to
> > understand why maximal flexibility is crucial in most real-world
> > application programming -- and therefore why, in said real world rather
> > than in the more academic circles Dr. Van Roy and Dr. Hadidi move in,
> > dynamic typing is generally preferable, and not such a tiny issue as
> > they make the difference to be.
>
> I guess there may be more than one kind of flexibility. The language
> I fool around with sometimes that has strong static typing is Haskell.
> Though a relatively elementary Haskell programmer (the learning curve
> with this language is something you would have to experience to believe),
I do have (some of:-) that experience, and am reasonably at ease in
Haskell (except when it comes to coding monads, which I confess I still
have trouble wrapping my head around).
> I feel that the type checking actually helps me program faster.
> The compiler's check for structural correctness is after all for my
> benefit, and expedites development and maintenance of code, in my
> limited experience. The more extensive my changes, the more useful
> the type checking is - I'm much more casual about significant code
> revision when writing in Haskell, somewhat more casual when writing
> in C, and worried when writing Python.
Eckel's and Martin's well-known essays on why good testing can replace
strict static type checking:
<http://www.mindview.net/WebLog/log-0025>
<http://www.artima.com/weblogs/viewpost.jsp?thread=4639>
Me, I'm always worried about significant code revision _unless I have
good tests in place_. Strict static typechecks catch only a small
subset of frequent mistakes -- good tests catch a far higher quota.
Typechecks do catch some mistakes "faster", but, in my experience on
today's machines, that tiny difference is becoming insignificant,
particularly when you consider that typechecks typically require
whole-program analysis while, as Van Roy and Haridi point out, dynamic
typing affords "totally open coding".
Alex
John Nagle
He's all over the place in that article. He really isn't talking
about strong typing at all. What he does make a case
for is dispatch by name without inheritance, or "duck typing".
But that, in fact, is a form of strong type checking. The effect is
as if "object" had an abstract function for every member function
in the whole program. (And, in fact, in Python you pay exactly the
dispatch cost that would take.)
The problem is that in both C++ and Java, the first round
of the type system was botched. C++ originally had neither
generics nor checked downcasting (a la "dynamic_cast").
Java originally lacked generics. Both languages added those
as bolt-ons, and it shows.
But, again, this really isn't a Python issue.
John Nagle
Paul Rubin
> I do have (some of:-) that experience, and am reasonably at ease in
> Haskell (except when it comes to coding monads, which I confess I still
> have trouble wrapping my head around).
I recently found the article
http://en.wikibooks.org/wiki/Haskell/Category_theory
which had (for me anyway) a far more comprehensible explanation of
monads than anything I ever saw about Haskell programming. Don't be
scared by the title--the article is very readable. It's much clearer
than many Haskell tutorials I've seen, whose monad explanations simply
wouldn't fit in my mind, with weird analogies about robots handling
nuclear waste in containers moving around on conveyor belts, etc. I
think right now I could write an explanation of monads understandable
by any well-versed Python programmer (it would be based on showing the
parallels between Python's list type and Haskell's List monad, then
moving onto sequencing with the Maybe monad, instead of trying to
start by explaining Haskell I/O), so maybe I'll try to do that
sometime.
> Eckel's and Martin's well-known essays on why good testing can replace
> strict static type checking:
> <http://www.mindview.net/WebLog/log-0025>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=4639>
Those are pretty unpersuasive since they're based on Java and C++.
Eckel's example would have been much easier in Haskell, I think.
Did you look at Tim Sweeney's presentation "The Next Mainstream
Programming Language: A Game Developer's Perspective"? I wonder what
you thought of it. It's here:
Powerpoint version:
http://www.cs.princeton.edu/~dpw/popl/06/Tim-POPL.ppt
PDF version:
http://www.st.cs.uni-sb.de/edu/seminare/2005/advanced-fp/docs/sweeny.pdf
He advocates a mixed functional/procedural language with even fancier
static types than Haskell.
> Me, I'm always worried about significant code revision _unless I have
> good tests in place_. Strict static typechecks catch only a small
> subset of frequent mistakes -- good tests catch a far higher quota.
It seems to me that the typecheck is sort of like a test that the
compiler provides for you automatically. You still have to write
tests of your own, but not as many. Also, Python-style unit tests
usually are written for fairly small pieces of code. They usually
don't manage to cover every way that data can flow through a program.
E.g. your program might pass its test and run properly for years
before some weird piece of input data causes some regexp to not quite
work. It then hands None to some function that expects a string, and
the program crashes with a runtime type error. Static typechecking
makes sure that a function expecting a string can never ever receive
None.
I also sometimes have trouble figuring out how to write useful tests,
though maybe there's some understanding that I haven't yet grokked.
However, a lot of my programs crawl the filesystem, retrieve things
over the web, etc. It's hard to make any meaningful tests
self-contained. Last week I needed to write a 20-line Python function
that used os.walk to find all filenames of a certain format in a
certain directory tree and bundle them up in a particular way. The
main debugging hassle was properly understanding the output format of
os.walk. A static type signature for os.walk, checked against my
program, would have taken care of that immediately. Once I got the
function to work, I deployed it without writing permanent tests for
it. An actual self-contained test would have required making some
subdirectories with the right layout before running the function.
Writing a test script that really did that would have taken 10x as
long as writing the function took, and such a complex test would have
needed its own tests (I'd have probably used something like dejagnu).
For functions that simply transform data, I've been enjoying using
doctest, but for functions like the above os.walk thing, I'm not sure
what to do. I'd be happy to receive advice, of course.
> Typechecks do catch some mistakes "faster", but, in my experience on
> today's machines, that tiny difference is becoming insignificant,
> particularly when you consider that typechecks typically require
> whole-program analysis while, as Van Roy and Haridi point out, dynamic
> typing affords "totally open coding".
I don't know if this holds in Haskell, but at least in C, the compiler
could usually find several errors in one pass, while dynamic types
often mean running the program, seeing some function crash from
getting None instead of a string, figuring out and fixing the error,
running again, getting a similar crash in a different place, and
repeating all the above several times.
Lately I've been looking at a somewhat highbrow book on programming
language theory:
http://www.cs.cmu.edu/~rwh/plbook/book.pdf
I don't understand that much of it, but the parts I can make any sense
of are giving me a better picture of what PL designers these days
think about. It's really nothing like how it was in the 1970's.
Roy Smith
> Eckel's and Martin's well-known essays on why good testing can replace
> strict static type checking:
> <http://www.mindview.net/WebLog/log-0025>
> <http://www.artima.com/weblogs/viewpost.jsp?thread=4639>
I've read the first before. I just re-read it. There seem to be three
different concepts all being talked about at the same time.
1) Static vs. dynamic checking.
2) Type (is-a) checking vs. behavior (has-a) checking.
3) Automatic (i.e. compiler generated) vs. manually written tests.
They all allow you to write manual tests. No sane programmer will rely
exclusively on the automatic checks, no matter what flavor they are. The
interesting thing is that most people seem to conflate items 1 and 2 above
into two composite camps: static type checking vs. dynamic behavior
checking. There's really no reason you can't have dynamic type checking
(things that raise TypeError in Python, for example, or C++'s
dynamic_cast). There's also no reason you can't have static behavior
checking (Java's interfaces).
greg
> E.g. your program might pass its test and run properly for years
> before some weird piece of input data causes some regexp to not quite
> work.
Then you get a bug report, you fix it, and you add a test
for it so that particular bug can't happen again.
> Once I got the
> function to work, I deployed it without writing permanent tests for
> it.
That suggests you had a temporary test at some point.
So, keep it and make it a permanent test. Even if it's
just a small manually-created directory, it's still
better than nothing, and you can add to it over time
to cover any bugs that turn up.
--
Greg
Paul Rubin
> > E.g. your program might pass its test and run properly for years
> > before some weird piece of input data causes some regexp to not quite
> > work.
>
> Then you get a bug report, you fix it, and you add a test
> for it so that particular bug can't happen again.
Why on earth would anyone prefer taking a failure in the field over
having a static type check make that particular failure impossible?
> > Once I got the function to work, I deployed it without writing
> > permanent tests for it.
>
> That suggests you had a temporary test at some point.
I ran the function on real, dynamic data and made sure the results
were right.
> So, keep it and make it a permanent test. Even if it's just a small
> manually-created directory, it's still better than nothing, and you
> can add to it over time to cover any bugs that turn up.
That doesn't obviously fit into the doctest framework; such a test
would be considerably more complex than the function itself, and the
types of situations that I could imagine causing failures wouldn't be
included in a test like that. Basically I had to get on to the next
thing. Given the somewhat throwaway nature of this particular code,
nothing else really made sense. But I think I'm going to look into
using dejagnu for more heavyweight testing of some other parts of the
program, so I guess some good came out of discussing this issue.
Thanks.
Bruno Desthuilliers
> greg <gr...@cosc.canterbury.ac.nz> writes:
>>> E.g. your program might pass its test and run properly for years
>>> before some weird piece of input data causes some regexp to not quite
>>> work.
>> Then you get a bug report, you fix it, and you add a test
>> for it so that particular bug can't happen again.
>
> Why on earth would anyone prefer taking a failure in the field over
> having a static type check make that particular failure impossible?
Because static type checks impose a lot of arbitrary restrictions,
boilerplate code etc, which tends to make code more complicated than it
needs to be, which is a good way of introducing bugs that wouldn't have
existed without static type checks. Depending on the application domain
and some technical and non-technical constraints and requirements, it
(often) happens that it's better to have the application deployed now
with an occasional error message than to have it next year...
And FWIW, when it comes to "weird piece of input data", statically typed
languages are not specially better than dynamic ones...
Roy Smith
> Paul Rubin wrote:
> > E.g. your program might pass its test and run properly for years
> > before some weird piece of input data causes some regexp to not quite
> > work.
>
> Then you get a bug report, you fix it, and you add a test
> for it so that particular bug can't happen again.
The TDD zealots would tell you you've got the order wrong. Instead of
"fix, then write a test", it should be "write a failing test, then fix it".
Alex Martelli
Incidentally, I was pretty surprised recently (re-reading Weinberg's
"Psychology of Computer Programming" classic from _1971_) to find out
Weinberg advocating "test-first coding" (not the same thing as
"test-driven design", but sharing the key insight that tests should be
written before the code they test) for psychological reasons. He's
discussing common practices of the '60s, with the same professional
writing both the code and the tests, and pointing out how often the
knowledge of the already-written code subconsciously influences the
programmer to write tests that don't really "challenge" the code enough
-- writing the tests "in advance" would avoid this problem.
Nihil sub sole novi...
Alex
Paul Rubin
> Because static type checks impose a lot of arbitrary restrictions,
> boilerplate code etc, which tends to make code more complicated than
> it needs to be, which is a good way of introducing bugs that wouldn't
> have existed without static type checks.
Why do you say that? By metrics and anecdotal evidence, Haskell code
appears to be at least as compact as Python code.
> Depending on the application domain and some technical and
> non-technical constraints and requirements, it (often) happens that
> it's better to have the application deployed now with an occasional
> error message than to have it next year...
I suppose that includes the thing I'm currently working on. For
some other stuff I've done, such errors would have caused huge hassles,
lost customer money, etc.
> And FWIW, when it comes to "weird piece of input data", statically
> typed languages are not specially better than dynamic ones...
I know that ML gives compiler warning messages if you have a pattern
match (sort of a variant of a case statement, not a regexp match)
which is non-exhaustive. And Haskell's Maybe monad is part of an
idiom that handles failing computations (like regexp matches) much
more gracefully than Python can. Both of those would help this
situation.
Paul Boddie
> Bruno Desthuilliers <bruno.42.de...@wtf.websiteburo.oops.com> writes:
> > Because static type checks impose a lot of arbitrary restrictions,
> > boilerplate code etc, which tends to make code more complicated than
> > it needs to be, which is a good way of introducing bugs that wouldn't
> > have existed without static type checks.
>
> Why do you say that? By metrics and anecdotal evidence, Haskell code
> appears to be at least as compact as Python code.
I think Bruno is referring to another class of languages here.
However, it's interesting to consider the work that sometimes needs to
go in to specify data structures in some languages - thinking of ML
and friends, as opposed to Java and friends. The campaign for optional
static typing in Python rapidly became bogged down in this matter,
fearing that any resulting specification for type information might
not be the right combination of flexible and powerful to fit in with
the rest of the language, and that's how we really ended up with PEP
3107: make the semantics vague and pretend it has nothing to do with
types, thus avoiding the issue completely.
Paul
John Nagle
> Paul Rubin wrote:
>
> The campaign for optional
> static typing in Python rapidly became bogged down in this matter,
> fearing that any resulting specification for type information might
> not be the right combination of flexible and powerful to fit in with
> the rest of the language, and that's how we really ended up with PEP
> 3107: make the semantics vague and pretend it has nothing to do with
> types, thus avoiding the issue completely.
Unfortunately, that may lead to the worst of both worlds.
If you think enforced static typing is painful, try maintaining code with
non-enforced static typing. You can't rely on the type information, and
inevitably some of it will be wrong. You can't tell by looking which
is wrong, of course.
This has been tried. Original K&R C had non-enforced static typing.
All "struct" pointers were equivalent. It wasn't pretty.
It takes strict programmer discipline to make non-enforced static
typing work. I've seen it work in an aerospace company, but the Python
crowd probably doesn't want that level of engineering discipline.
Non-enforced static typing requires a quality assurance group that
reads code and checks coding standards.
John Nagle
Paul Rubin
> This has been tried. Original K&R C had non-enforced static typing.
> All "struct" pointers were equivalent. It wasn't pretty.
>
> It takes strict programmer discipline to make non-enforced static
> typing work. I've seen it work in an aerospace company, but the Python
> crowd probably doesn't want that level of engineering discipline.
I think even enforced static types wouldn't cure what I see as the
looseness in Python. There is not enough composability of small
snippets of code. For example, the "for" statement clobbers its index
variable and then leaks it to the outside of the loop. That may be
more of a culprit than dynamic types. Perl and C++ both fix this with
syntax like
for (my $i in ...) ... (perl) or
for (int i = 0; i < n; i++) ... (C++, Java)
making a temporary scope for the index variable. Python even leaks
the index variable of list comprehensions (I've mostly stopped using
them because of this), though that's a recognized wart and is due to
be fixed.
Python would be helped a lot by some way to introduce temporary
scopes. We had some discussion of this recently, concluding that
there should be a compiler warning message if a variable in a
temporary scope shadows one from a surrounding scope.
Bruno Desthuilliers
> Bruno Desthuilliers <bruno.42.de...@wtf.websiteburo.oops.com> writes:
>
>>Because static type checks impose a lot of arbitrary restrictions,
>>boilerplate code etc, which tends to make code more complicated than
>>it needs to be, which is a good way of introducing bugs that wouldn't
>>have existed without static type checks.
>
>
> Why do you say that? By metrics and anecdotal evidence, Haskell code
> appears to be at least as compact as Python code.
Haskell - as other languages using type-inference like OCaml - are in a
different category. Yes, I know, don't say it, they are statically typed
- but it's mostly structural typing, not declarative typing. Which makes
them much more usable IMHO. It's too bad they are not more widely adopted.
>>Depending on the application domain and some technical and
>>non-technical constraints and requirements, it (often) happens that
>>it's better to have the application deployed now with an occasional
>>error message than to have it next year...
>
>
> I suppose that includes the thing I'm currently working on.
>
> For
> some other stuff I've done, such errors would have caused huge hassles,
> lost customer money, etc.
Still, static typechecking is not a garantee against runtime errors. Nor
against logical errors.
>
>>And FWIW, when it comes to "weird piece of input data", statically
>>typed languages are not specially better than dynamic ones...
>
> I know that ML gives compiler warning messages if you have a pattern
> match (sort of a variant of a case statement, not a regexp match)
I know what pattern matching is, I did play a bit with OCaml and Haskell.
> which is non-exhaustive. And Haskell's Maybe monad is part of an
> idiom that handles failing computations (like regexp matches) much
> more gracefully than Python can. Both of those would help this
> situation.
I'd have to see a concrete use case. And I'd need much more real-world
experience with some ML variant, but this is not something I can expect
to happen in a near future - it's difficult enough to convince PHBs that
Python is fine.
Paul Rubin
> Haskell - as other languages using type-inference like OCaml - are in
> a different category. Yes, I know, don't say it, they are statically
> typed - but it's mostly structural typing, not declarative
> typing. Which makes them much more usable IMHO.
Some users in fact recommend writing an explicit type signature for
every Haskell function, which functions sort of like a unit test.
That doesn't bloat the code up noticibly. The conciseness of those
languages comes more from polymorphism and convenient ways of writing
and using higher-order functions, than from type inference.
> Still, static typechecking is not a garantee against runtime
> errors. Nor against logical errors.
Right, however the reality is it does seem to prevent a lot of
surprises. There's even an intermediate language (a language
generated by a compiler as an intermediate step towards emitting
machine code) called Henk, in which EVERY value is type-annotated (and
in a very fancy type system too). The author reports that the
annotations have been very helpful for noticing compiler bugs.
> I'd have to see a concrete use case. And I'd need much more real-world
> experience with some ML variant, but this is not something I can
> expect to happen in a near future - it's difficult enough to convince
> PHBs that Python is fine.
Monad Reader #7 has an article about some Wall street company using ML:
http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf
see the article by Yaron Minsky.
Bruno Desthuilliers
> Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> writes:
>
>>Haskell - as other languages using type-inference like OCaml - are in
>>a different category. Yes, I know, don't say it, they are statically
>>typed - but it's mostly structural typing, not declarative
>>typing. Which makes them much more usable IMHO.
>
>
> Some users in fact recommend writing an explicit type signature for
> every Haskell function, which functions sort of like a unit test.
Stop here. explicit type signature == declarative static typing != unit
test.
> That doesn't bloat the code up noticibly. The conciseness of those
> languages comes more from polymorphism and convenient ways of writing
> and using higher-order functions, than from type inference.
Type inference is certainly helpful for genericity.
>
>>Still, static typechecking is not a garantee against runtime
>>errors. Nor against logical errors.
>
>
> Right, however the reality is it does seem to prevent a lot of
> surprises.
I have few "surprises" with typing in Python. Very few. Compared to the
flexibility and simplicity gained from a dynamism that couldn't work
with static typing - even using type inference -, I don't see it a such
a wonderful gain. At least in my day to day work.
>
>>I'd have to see a concrete use case. And I'd need much more real-world
>>experience with some ML variant, but this is not something I can
>>expect to happen in a near future - it's difficult enough to convince
>>PHBs that Python is fine.
>
>
> Monad Reader #7 has an article about some Wall street company using ML:
>
> http://www.haskell.org/sitewiki/images/0/03/TMR-Issue7.pdf
>
> see the article by Yaron Minsky.
Sorry, I don't live near Wall Street !-)
BJörn Lindqvist
> Remember that pure CPython has no different "compile time" and
> runtiime. But Psyco and ShedSkin could use the annotations the way
> they want.
.....
> def compile(source: "something compilable",
> filename: "where the compilable thing comes from",
> mode: "is this a single statement or a suite?"):
I think the above would make an annotation-enhanced Psyco or ShedSkin
very confused.
--
mvh Björn
Eduardo "EdCrypt" O. Padoan
This example was to show that annotations are for documentation too,
not only type checking or optimization. It is from the PEP.
----
EduardoOPadoan (eopadoan->altavix::com)
Bookmarks: http://del.icio.us/edcrypt
greg
> greg <gr...@cosc.canterbury.ac.nz> wrote:
> > Then you get a bug report, you fix it, and you add a test
> > for it so that particular bug can't happen again.
> The TDD zealots would tell you you've got the order wrong. Instead of
> "fix, then write a test", it should be "write a failing test, then fix it".
Yes, I'm aware of that. I said "and", not "then". :-)
--
Greg
Roy Smith
John Nagle <na...@animats.com> wrote:
> Non-enforced static typing requires a quality assurance group that
> reads code and checks coding standards.
In other words, it's enforced, but it's enforced by QA people instead of
the compiler.
Michael Hoffman
> On 6/30/07, Bruno Desthuilliers
> <bdesth.qu...@free.quelquepart.fr> wrote:
>> Eduardo "EdCrypt" O. Padoan a écrit :
>> > Remember that pure CPython has no different "compile time" and
>> > runtiime.
>>
>> (hint: read the doc)
>
> Sorry, I surely know that Python has a compile time, I wanted to say
> somthing like "compile time checks except from syntax".
Well, if you try to reassign __debug__ or None you get a SyntaxError,
but I don't think it is truly checking syntax.
--
Michael Hoffman
Nis Jørgensen
> Paul Rubin a écrit :
>> Bruno Desthuilliers <bdesth.qu...@free.quelquepart.fr> writes:
>>
>>> Haskell - as other languages using type-inference like OCaml - are in
>>> a different category. Yes, I know, don't say it, they are statically
>>> typed - but it's mostly structural typing, not declarative
>>> typing. Which makes them much more usable IMHO.
>>
>>
>> Some users in fact recommend writing an explicit type signature for
>> every Haskell function, which functions sort of like a unit test.
>
> Stop here. explicit type signature == declarative static typing != unit
> test.
Well, it quacks like a duck ...
Nis