Perl is worse!

Martijn Faassen m.faassen at vet.uu.nl
Mon Jul 31 04:14:28 EDT 2000


Steve Lamb <grey at despair.rpglink.com> wrote:
> On 30 Jul 2000 21:07:02 GMT, Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>>print bar

>     This is different than

> bar

Yes, it is; but what the interpreter does is basically put a 'print' for
everything you say.

The point is that you seemed to be saying 'bar' is nothing completely
useless; it's not -- it's a reference to a function object and can be
quite useful.

What our mysterious expression "bar" (quotes not part of it) is, is 
an expression, just like "1 + 1" or "bar()" or "bar(50 * foo())".

I'm not saying this isn't confusing initially; the point is that this is
not just a random weirdness that can easily be fixed (as I and other 
pointed out elsewhere). It's a consequence of a consistency in Python;
*other* expression statements do indeed do useful things.

[snip]
>>And you need to remember what all your operations do to any data type
>>that they may encounter. I don't.

>     I never have yet.  :)

Well, you do, otherwise you can't figure out bugs when you get them,
right?

If you get a mysterious 0, you need to know that this was possible
because somehow a string got involved in your arithmatic expression, right?

>>1 isn't mutable into anything at all either, by the way. Neither are
>>strings. The name 'b' can however be made to point to something else.
>>That is an entirely different thing though, and from the way you're
>>speaking I'm not entirely clear whether you understand this yet.

>     OK, to be strict.  None can't be converted, neither can 1.  For some
> reason, however, b, which was pointing to 1 can be made to point to something
> else which we'll call the integer formerly known as 1 where as None things
> cannot be repointed from.  None is like that really nasy uncle everone has who
> scratches himself in public and has a huge beer belly.  You don't want to
> look, but you are compelled to until the end of time.

That's because you put a None in there in the first place, for some
obscure reason. As soon as you made sure your variable *cannot contain
a None* (and no, you did *not* make sure of this in the regular expression
example you gave, and that's been debated to death already; you have
quite a few alternatives now), you do not have to check until the end
of time. It's not as if 'b' magically can change into something else again
all of a sudden. It only changes into something else if you somehow
made it change (most likely with an assignment).

>     The net result, of course, is that int() can point b to something else in
> some cases and not others, or, in layman's terms, it can convert certain
> things and not others.  However, since the docs for int do state "convert"
> both in the language and in the book I have I don't think it was too bad of me
> to have used that term, no?

No; I just wasn't sure you understood what it meant. You do seem to understand
what's going on behind the scenes, except that you still seem to see
problems that really aren't there. 'b' can't magically change when you
pass it through some function you didn't write, except if you assigned
the outcome to 'b' again. If your function has the chance to return something
else and you don't want 'b' to refer to that, don't do the assignment
(until you made sure of the result, at least).

The nice part comes in when you think a function can only return an
integer and you were wrong (by mistake, or due to some bug in the
function). Python will point out the mistake or bug pretty quickly.

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?



More information about the Python-list mailing list