Perl is worse!

[Steve Lamb]

On 28 Jul 2000 20:11:42 GMT, Martijn Faassen <m.faassen at vet.uu.nl> wrote:
>with your calculations. So you have to make sure your input is a number
>*anyway* if you want to calculate things, so why not complain in the
>first place when you run into something that doesn't seem to make sense.

    Because in some cases it does make sense.  1 + "1" makes sense.  It is
that grey area that causes problems.

>Anyway, I'm sure we won't be able to budge each other from our
>position on this. :)

    Prolly not.  I can live with it.  I don't like it, but once I know it is
there I can deal with it and move on.  My preferences are just elsewhere is
all.

>Yes, but in Python at least the program doesn't try to do things when you
>forgot to check the user input properly. And that increases the chances
>you'll find the bug in the first place.

    Which also increases the work for the programmer in case, which are in the
vast majority, where he doesn't need to check input since there is no input.
:)

>> (/^(\d{1,2})[Dd](\d{1,3})$/ || /^(\d{1,2})[Dd](\d{1,3})([\+\-])(\d{1,2})$/) 

>I don't know what you mean here. I never do anything like that, I'm
>happy to say. :)

    Extracting up to 6 match groups, 5 of which will be integers with the last
being a + or a -.  This means all groups can be either strings or None.  I've
already verified that groups 1-4&6 will be integers through the regular
expression so why check again?  To move these into ints on Python I needed to
toss the whole lot of assignments into a try/except and do a pass on TypeError
since you can't int() a None and Python doesn't like it when you try.  Seems
like there should be a cleaner way to be able to extrapolate digits out of a
string with re and stuff them into variables with int() without having to toss
it behind and if or try every time.  I don't feel that is an uncommon
occurance for anyone who might be taking numbers from plain text and wanting
to perform math operations on them.

>>     Perl or Python, doesn't matter, you should be able to read it.

>I'm not able to read it.

    Don't do much re work?  ;)

>I'd probably solve that in a more verbose way myself. 

    My perl background shines through, eh?
 
>So you're saying, since I know those particular groups are numbers anyway
>by necessity, it makes no sense to require explicit conversion (with
>int() in Python) to numbers of those things. I just want to use them
>as numbers right away. Did I understand that correctly?

    Bingo.

>As your program proceeds and for instance throws the dice, it'll try to use
>those variables as numbers, but since they're other strings, you'll
>eventually get strange answers (such as 0). And then presumably you'd have to
>search what part of your program is wrong. In Python you'd know pretty
>quickly that you got strings instead of numbers, and so you know what to fix.

    I know even faster in Perl.  When testing RE I take a sample, toss it in
an isolated script and build the regex until the expected results come forth.
When that is done I test it against a much larger data set for any cases I may
have missed.  If errant data gets in after that time in Perl you have a script
which runs but has some problems.  In Python it pukes.  In either case it
happens outside your hands.  When it comes to regex a properly defined regex
will not let through abberant data.  Esp. not when it comes to something as
simple as digits \d versus words \w.

>That wasn't the assumption. I said the exact opposite, you need to 
>remember what type your data is *anyway*. In order to do that you need
>to check the data if it is input.

    On input.  But for data generated internally this is not the case since
you defined it from start to end.

>This is a common misconception. *everything* in Python is always, always,
>references. It is just that certain data types (integers, string, tuples) are 
>immutable; you cannot change them. So the semantics are the same as 
>copy semantics.

    Yes, technically it is always a reference.  I know that in this case:

a = 1
b = 2

    a is a reference to an object, integer, that contains value 1 and b to an
object, integer, that contains the value 2.  What I meant was the difference
shown below:

>>> a = 1
>>> b = a
>>> a = 2
>>> b
1
>>> a = [1]
>>> b = a
>>> del(a[0])
>>> b
[]

    Forget, for a moment, what is happening internally.  What looks like here
is that in the first case there is an assignment going on and in the latter a
reference.  Nevermind that what is happening in the first case is a references
objint[1] and b references objint[1] and when we change a it points to a new
reference objint[2].  It is the difference in behavior of an identical
operator that is ambigious.  I'm sure even though I am aware that it happens I
am going to be nailed by it a few times before I get used to it.

>Isn't that worse than the program giving up? 

    No.  The program giving up in the customer's hands because of an unchecked
except is a far cry worse than a nigglet but having it continue on.  As a
customer which would you rather have, given the choice of these two:

a: A program that crashes, stopping everything that you're doing with no
chance of recovery

b: A program that behaves oddly but allows for chance of recovery.

    As a person who uses a lot of programs I'd rather have b which to me
translates into, "Neat, how'd that happen.  Oh, this is how. <file report>"
instead of "*BOOM* WTF!!  Dammit!  Now I have to type that whole message in
again!"

>But you haven't; you haven't told the system it's a number yet. :) That's
>the _only_ extra step you need to take. The system is too stupid to figure
>it out very well on its own anyway, so why not tell the system explicitly?

    No, in my case I needed to check to make sure it was a type that can be
converted to int and then do the actual conversion.  That is two steps more
than I deem needed considering the strictly checked input in the first place.

>Interactive mode (I think it explains in the tutorial) gives you the output
>of expressions as a result always. 

    Right, which is worthless in a script.  I'd personally have the Python
check what mode it is in and toss an exception when it is in interactive mode
and gets a meaningless statement.  It does so on every other possible
ambiguity, why not this one when it is even less grey than a lot of the ones I
am tossing out?  Is there a purpose for having such informative statements in
non-interactive mode?

>No, my entire point was that you need to know what your data is *anyway*.

    Right, I know what the data is, I don't need the language to ask me at
every operation, "Are you sure?  I mean, really, really, REALLY sure!?"

>You need to know that something is an integer anyway, so why not simply
>tell the computer what's going on? I'm *not* saying the language should
>do the checking. It can't; even though Perl tries.

    Because what if I want to do something that the computer thinks is
non-sensical?  

>checking. If you want the system to shut up about your mistakes,
>you can always do this in Python:

>try:
>   a = a + 1
>except:
>   pass

    Great, now I get to litter my code on a per operation basis with tries
instead of being able to set it on certain variables.  That would make more
sense.

>This works. I didn't need to tell the system that 'a' is a cow or a chicken
>or an animal that can make sounds. 

    Of course not, they are types.  The variable gets it type at declaration,
IE, assignment.

>You can do that in Python too. I tend to prefer that as well.

    I also prefer the computer to trust me than mistrust me.

>>     Funny, we have implicit typing in OO code that causes problems later in
>> the code.  So yes in OO code.

>What implicit typing? I don't understand what you mean at all.

   A variable gets its type upon assignment.  That is implicit typing.

>Yes, but if I'm not doing it properly at least the language will complain
>so I get a broad hint I do need to do it properly. :)

    As well as if you're doing it properly the language will still complain
long and loud.

>Huh? Where in Python did you find your declarations? I'm confused.

a = None
int(a)

    a is declared as None at assignment.

>Well, because it doesn't really make a lot of sense if you want to convert
>something to an integer when Python can't figure it out. If you're so
>sure of yourself, you can always do:
>
>try:
>   a = int(b)
>except ValueError:
>   a = 0

    Right, which is basically what I had to do except I left None as None.
Just seems like a pain in the butt to do after I have allready made sure,
beyond all doubt, that those variables contain numbers in the first place.

>All right; this just doesn't happen very often in my code. Generally because
>I can expect a certain regularity in my input. If my input is less regular
>than I expected, I get exceptions. That gives me a nice indicator that my
>expectations were off.

    Which is why for the base parsing routine I use re.  If it doesn't pass re
it doesn't get executed, period.  People can try all they want to get around
the regular expressions but it is really hard to do so.  I don't see a reason
to write my own test parsing routines when re does it for me.

>In that case you don't need to do any checking, obviously. You have a 
>regularity in your data so you just do something like:

>a = int(a)

>Though I may be missing something about regular expressions here and
>I'm goofing up?
 
    A regex could return a string or None, only one of which is convertable to
int.  You must litter your code with such checks.

>Hm, why would you do that? Depends on the structure of your keys. You can
>use numeric keys in your Python dictionary just fine.

    Text for information, numericals to prevent duplication.

>But an integer can be seen as an object with methods as well. A string
>too (Python 2.0 will actually allow you to use string methods). In fact,
>I can make a new type of object in Python that behaves much like your
>Perl scalars:

    Touche'.  ;)

-- 
         Steve C. Lamb         | I'm your priest, I'm your shrink, I'm your
         ICQ: 5107343          | main connection to the switchboard of souls.
-------------------------------+---------------------------------------------