Perl is worse!

[Alex Martelli]

"Steve Lamb" <grey at despair.rpglink.com> wrote in message
news:slrn8o6mr7.f91.grey at teleute.rpglink.com...
    [snip]
>     Because Python can toss two types out.  String or None, only one of
which
> can be converted.

Python can 'toss out' other types too, because you can use any type
as the argument to groups(), which is used as the value 'tossed out'
for groups for which there is no match.  None is just the default.

And of course None can also be converted, it's just not converted
by a plain int(x).  But it just takes an int(x or 7) to fix that,
for example (if one wants None to be converted to 7...:-).


> >software not working in case of such input!
>
>     Assumption it is dealing with money.  What about logs processing?

Losing accumulated logs, and/or logging false data, would be utter
disasters.  Learning *ASAP* that the log-processing program has a
bug is clearly the priority; if subtly-false data were being logged
instead, that could go on for weeks before being noticed -- and
the subtly-mendacious logs could be worse than useless until this
IS noticed (and just-useless afterwards:-), since from the false
information in the logs wrong business decisions could be taken.


> >>>> bar
> ><function foo at 80c8f68>
>
>     Right, I understand thta.  Which is why I keep pointing out that it is
> meaningless in the context of a script.  You tell me why I would need to
know
> that in a script and maybe we can get around this.  I just see no need,
ever,
> for something that cannot be accessed by the script in the first place.

The problem is, how to ensure that an expression IS utterly devoid of
side effects, without substantial cost.  In the general case I am not
sure it can be done.  For the specific case of an expression consisting
just of the mention of a variable (not a class instance's field), it
could be done; would it be worth having a special-case, an exception
that is only raised for that very specific case?

Some expressions that have no side effects are very handy, by the way.
For example, prepending and appending a """ to a block of lines (thus
turning them all into an expression that is a single constant string)
may be a useful way to "comment out" the whole block.  To avoid any
interference with such useful idioms, very clear and detailed rules
should be drawn up about WHICH no-side-effects expressions will raise
an exception.  Can they be made simple enough that their practical
usefulness is substantial?  If so, it could be an improvement.


> >have the computer give up on things if I'm trying to do things that
> >don't seem to make any sense immediately. That way I need to remember
> >less.
>
>     To me it is remembering more.  "Now, this variable coming in from that
> file over there, going through this code over here in a different module,
> entering in here... was it converted twice or three times and what do I
need
> to do with it now."
>
>     Vs.
>
>     "Here it is, those checks said it is this, do it."

Why would you need to keep track of all things in the former
paragraph?  Just be explicit about what is to be done for each
of the cases it can be, and you're all set.

If it can only be a sequence of 1 or more digits, great, all
you need to do is int(x).  If it can also be an empty sequence,
or None, then you need to do int(x or 0), for example.  And
so on.  Just be explicit about what you want done!


> >Unless you made it possible that b contained something that couldn't be
> >turned into a number, such as None. If you made that possible you aren't
> >sure beyond all doubt that the variable contains a number, right?
>
>     Which is, of course, a product of the lanauge.  I know it is going to
be a
> digit or empty.  Sad part is Python makes empty None and None mutable into
> pretty much nothing.

The None is immutable, just as strings are immutable (and numbers,
and tuples), but *why is that sad*?!  You don't need to mutate the
value, in any of these cases -- you just need to use it to compute
another, related value.  And of course you can do it with None just
as you can do it with a string, etc, etc.

Furthermore, I keep pointing out that, if you call the groups method
of the match object, what Python returns for non-matching groups IS
UP TO YOU: it will return the argument you pass to groups, None if
you choose to pass no argument.  So, *what* is supposed to be 'sad'?!


> >Sure, but it is the same in Python, right? Except that in the end you
have
> >to cast your integers to ints or whatever other thing you were expecting
> >from your input.
>
>     So why, then, when I have done the check should I have to do it,
again,
> for the sake of the language.

You have done no check about whether each given group matched
something, or not.  There is no "again" about it: you've NEVER
done any such check, so it can't possibly be a question of doing
it "again", can it?!

Further, the 'check' in this case can be as simple as an 'or',
in the expression int(x or 0); and you can even omit it totally
if you choose to ensure uniform-cases by passing a value, whose
choice is totally up to you, to the groups method.

What more do you need to convince you that your criticisms of
the options that Python gives you to handle this specific issue
are utterly unfounded...?


Alex