The Industry choice

Cameron Laird claird at lairds.us
Tue Jan 4 17:08:03 CET 2005


In article <87zmzsax12.fsf at hector.domek>,
Peter Dembinski  <pdemb at illx.org> wrote:
			.
			.
			.
>def foo(x):
>    return str(x)
>
>str = foo(x)
>
>And now, let's say that foo()'s definition is in another module.
>It is hard for a programmer to quickly determine the type for str,
>that's the problem with programming in languages that don't have
>type declarations.

I think I don't understand.  I believe you're saying that Python and
C might code homologously as

  def py_foo(x)
    return py_bar(x)

and
  
  char *C_foo(int x)
  {
    return C_bar(x);
  }

and that these definitions make it evident that C_foo() returns a
(char *), while there's no such manifest restriction on the type 
of py_foo().  Well, yes, that's so (but what did it have to do with
definitions in another module?).  There's nothing peculiar in this
to functions, right?  Python declares types of *no* bindings, so 
your claim is equally true of local variables, correct?

And this is all a *benefit* of Python, at least as I see it.  Yes,
good style in Python is different from good style in C, but the
former's strong implicit typing has, I think, equal claim to 
virtue.

Type in C are so epiphenomenal.  They communicate little of what *I*
need to know.



More information about the Python-list mailing list