Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

Something that worries me about perl to no end is tests like:

if ($lastname) { ... }

This fails when $lastname="0". But I am constantly seeing perl code that does it.



Actually, what worries you is not Perl per se, but people that write Perl code and don't know what they want to test for. The code shown interrogates $lastname for values that represent truth in Perl, while it ought to be checking for definedness:

    if(defined $lastname) { ... }
The two are totally different cases. I would also argue that the problem lies elsewhere if you have values for a 'lastname' field in your data set that consist of a single letter.


Considering that there a plenty of people with no last name at all, I don't find it at all hard to imagine that there might also be people with a real last name consisting of only one letter.

There is a town famously called simply "Y" in France.


One letter strings evaluate as true. This would only be false for a last name comprised of the single digit '0'


It's not Perl. I recently had a conversation with a friend who didn't like me using "if myvar == 0:" or "if myvar is 0:" in python code rather than "if myvar:". Call me paranoid, but i like to be as explicit as possible in my checks, you never know when magic conversion tricks (which are often platform- or implementation-dependant) will end up biting you in the ass.


Python is a little better than Perl or PHP on this; it won't treat the string "0" as false. It does, however, treat both 0 and None as false, and also 0.0 == 0 == False, which is the same kind of potential bug.

Generally I find that Python's avoidance of implicit string type conversions means that I almost never have this kind of bug in my Python.

On another note, `myvar is 0` is undefined behavior; Python implementations can perfectly legitimately return False for that even if myvar is, in fact, the integer 0. Try this, in Python 2.7.3:

  >>> x = 257
  >>> x is 257
  False
  >>> x = 257; x is 257
  True
  >>> 257 is 2**8 + 1
  False
  >>> 256 is 2**8
  True
  >>> x = 256
  >>> x is 256
  True
That's because `is` denotes object identity, not value equality, and for immutable objects like integers, strings, and tuples of immutable objects, object identity is fair game for optimization. In the above, "is" gives us a fascinating window into the particular optimization decisions taken by the CPython 2.7.3 interpreter. But, child, if you want your code's behavior to depend on some problem domain instead of interpreter optimizations, don't use "is" to compare integers!


Yes child, check this out: http://lateral.netmanagers.com.ar/weblog/posts/BB979.html , in particular my comment from two months ago. http://lateral.netmanagers.com.ar/weblog/posts/BB979.html#co... and see where I'm coming from.


Using "if myvar is 0" exposes you to more implementation dependent behavior than "if myvar".


I agree, but it's still more explicit in terms of what process is used to evaluate the content of myvar and what it should match, especially in a context where you're expecting a numeric value rather than a boolean.


The same problem exists in PHP, where "", "0" and 0 are all treated as false if you don't check the type. Welcome to the trap of loose typing.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: