Perl is worse!

[Karl Ulbrich]

Quoting Steve Lamb (grey at despair.rpglink.com):
> On Sun, 30 Jul 2000 02:22:31 +0200, Alex Martelli <alex at magenta.com> wrote:
> >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...:-).
> 
>     It is my understand that in an int(None or 0) what is happening is that
> the None fails, the or kicks in and we're really int()ing an integer in the
> first place, not actually converting the None.

Perhaps Alex should have said "a variable containing None can also be 
converted [to an integer]", but the intent (solving your problem)
was clear.

You are correct that the actual None object is not converted -- the 'or'
is selecting the other value (7, in the example) if None occurs.

> >Losing accumulated logs, and/or logging false data, would be utter
> >disasters. 
> 
>     You're speaking in absolute terms on something which is best determined by
> the end user, not the language.  To me, for a lot of the logs I process, no,
> it isn't a disaster.  It isn't even a minor annoyance.  It is just a speck of
> dust on a rather large desk that I couldn't care less about.  Having the logs
> processing puke on me, or any other of dozens of applications I can think of,
> because of a inconsiquential burp in the data is the real annoyance.

In that case, would "inconsistent is better than consistent" be 
an accurate reflection of your criteria for a log processing language?

Actually that's not a fair generalization.  For your logs, clearly
minor errors in the data don't matter to you.  You've been shown
examples where minor errors mean a LOT, and you've also been shown
Python ways to ignore the kinds of errors your data generates.

It's *very* unreasonable to expect that *everyone* would want 
inconsistent data to slip through unnoticed, even if it is reasonable
for a particular problem domain.

> >bug is clearly the priority; if subtly-false data were being logged
> >instead, 
> 
>     Uhm, logs processing process logs for one of a variety of uses.  IE, the
> data has already been logged, how can it be falsely logged again?

Easy. As an example, suppose your program processes 400 MB worth
of http logs each day (not an uncommon task), but extracts and logs
only a fraction of that for long-term storage (daily logs are not deemed
worthy of permanent backups).

If weeks go by and you've silently missed a value because Someone Else
changed a title somewhere, who will wish he'd seen the error the
day it occured instead of a month later when there's no July data?

> >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.
> 
>     Except now you need to do tons of conversion at different levels depending
> on what you do with the data.  You either type it up front and have it fail
> later, or type it later dozens of times.  Neither is appealing to me.

I think you're exagerrating the burden; Alex gave you examples (in another
msg) that show how to make a function that returns matches as integers.

> >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'?!
> 
>     I don't see where I can tell it to pass something other than None on a
> match.  The docs I read, (not here) state that it /will/ return None on a
> no-match, not that it /can/ and that you can override it.

I don't see it either (Alex?) in the library reference.  Personally
I thought both the 'int(x or 0)' approach and the function Alex suggested
were good ways to establish problem-specific default values, especially
since '0' isn't always an apprpriate default.

Karl Ulbrich