tim_one at email.msn.com
Sat Aug 28 10:05:31 CEST 1999
> def seqToString( seq ):
> result = result + ']'
> Personally, I think falling out of functions and expecting None to be
> implicitly returned is a very Perl-ish thing to do...
Oddly enough not. In the absence of an explicit "return", Perl returns the
value of the last expression evaluated before falling off the end, so in your
function above it returns what you intended.
> Why don't we add $_ to Python as well?
Because that would be Perlish <wink>. The notion of an implicit operand first
appeared in string matching languages, where it's a PITA (and error-prone) to
have to keep specifying the same string and index vrbls. Perl buys efficiency
& convenience with this trick for the same reason, although outside of string
crunching I'm not sure I've seen a good use of it. The reason it doesn't fit
in Python is that Python isn't specialized to string crunching -- or to any
other particular domain.
> I don't think it's too hard to explicitly return None when that's
> what you want to do, and I would think/hope that most existing Python
> code does this already.
Python doesn't return None for the convenience of people too lazy to explicitly
return None themselves; it's instead a cheap way to make it probable that
someone using a procedure as a function will get an error (None supports no
operations except true/false interpretation) without blowing up the interpreter
(do this in C and you'll access random stack trash).
> It is possible, but more complicated, to make this a compile time
> error. This would essentially require a function/procedure
> distinction with restrictions about how you used return in each one.
Do you imagine Guido didn't consider this when he designed the language?
nothing's-a-pure-win-ly y'rs - tim
More information about the Python-list