4 ms·

> One thing that always bugged me was the lack of "strict" mode (see perl) What Perl has as "strict" mode, Python just has by default all the time. The typing

> One thing that always bugged me was the lack of "strict" mode (see perl) What Perl has as "strict" mode, Python just has by default all the time. The typing is dynamic but strong, it will complain about unbound variables instead of silently creating them, scoping, while not ideal, is sane out of the box. What Python doesn't have is taint mode, but that is quirky and fragile as hell in Perl as well, and more of a nuisance nowadays than an actual aid.

duskwuff 3y ago
> The typing is dynamic but strong, it will complain about unbound variables instead of silently creating them Are you sure about that? def example(x): result = 123 if x == 456: reslut = 789 # undetected typo return result In Perl, this throws an error at compile time: use 5.036; sub example ($x) { my $result = 123; if ($x == 456) { $reslut = 789; # <-- Global symbol "$reslut" requires explicit package name } return $result; }
- orf 3y ago
  Every python linter or code quality tool has been able to detect unused local variables like this since at least the year of our lord, 1841. You don’t need this baked into the language.
- WesolyKubeczek 3y ago
  So what? This is just one class of the mistakes you can make. For the sake of argument, if you do have both "$result" and "$reslut" (they don't need to be named like this, of course, just continuing your example) with very different purposes, and you use the wrong one, the result is ... just as wrong. I think all popular linters for Python catch the mistake you have shown since a decade or so. You create a variable and then don't use it. On the other hand, I've been screwed over by wild list context suddenly appearing and swallowing my undefs (that I needed to be there) countless times. To this, Perl doesn't have a remedy. It won't even warn me that a function returned an undef but the list context squashed it into nothingness. This causes, for example, off-by-one errors that lead to creation of malformed hashes which sometimes may look almost right except the data is corrupted now. Even worse, two undefs instead of one will silence the warning about odd number of elements forming a hash, and that hash will be just as corrupted. Perl weenies very much like to brag about crutches their language invented to bravely overcome the problems it itself has created, and it prevents them from realizing how limited those crutches are.
  - KaiserPro 3y ago
    perl is not a perfect language. nobody should be claiming that. They way function args are define is just pure passive aggression (oh so you _want_ people to name args properly eh? go on, you validate the arg name. Go on, fiddle with the hash like that). However we should be able to look at any language and pull out its interesting/useful features. I loved perl's can do attitude. You wanna do that to an array? sure. it'd going to end bad, but here you go kid, have at it. Is that good for everyone? no. does it mean that you need to be hilariously disciplined to make readable code? very yes. Can one make readable and maintainable code in perl? hell yes. I've worked on some wonderfully maintainable perl code. I've also worked on a lot of shite. But then the same goes for python. I transmute research code into production, and let me tell you, there are some "perls" of programmers right there.
  - duskwuff 3y ago
    I'm not saying that Perl is perfect. Far from it. But saying that Python "will complain about unbound variables instead of silently creating them" is simply incorrect. One of the defining characteristics of Python's variable scope is that assigning to a name always creates it in the current scope; there's no other way to declare a variable. And that's all I'm trying to demonstrate here.
    - WesolyKubeczek 3y ago
      The act of assigning is creating a variable; the act of using it will complain about an unbound variable. Perl in non-strict mode, PHP last I touched it, Bourne-style shells will just go “yeah, whatever, here’s an empty string”.
- KaiserPro 3y ago
  yes! exactly this. Now obviously people would say "just use a linter" but its not actually as reliable as a builtin. Moreover, people who have dyslexia are not always able to spot stuff like this.

duskwuff 3y ago

> The typing is dynamic but strong, it will complain about unbound variables instead of silently creating them Are you sure about that? def example(x): result = 123 if x == 456: reslut = 789 # undetected typo return result In Perl, this throws an error at compile time: use 5.036; sub example ($x) { my $result = 123; if ($x == 456) { $reslut = 789; # <-- Global symbol "$reslut" requires explicit package name } return $result; }

orf 3y ago
Every python linter or code quality tool has been able to detect unused local variables like this since at least the year of our lord, 1841. You don’t need this baked into the language.
WesolyKubeczek 3y ago
So what? This is just one class of the mistakes you can make. For the sake of argument, if you do have both "$result" and "$reslut" (they don't need to be named like this, of course, just continuing your example) with very different purposes, and you use the wrong one, the result is ... just as wrong. I think all popular linters for Python catch the mistake you have shown since a decade or so. You create a variable and then don't use it. On the other hand, I've been screwed over by wild list context suddenly appearing and swallowing my undefs (that I needed to be there) countless times. To this, Perl doesn't have a remedy. It won't even warn me that a function returned an undef but the list context squashed it into nothingness. This causes, for example, off-by-one errors that lead to creation of malformed hashes which sometimes may look almost right except the data is corrupted now. Even worse, two undefs instead of one will silence the warning about odd number of elements forming a hash, and that hash will be just as corrupted. Perl weenies very much like to brag about crutches their language invented to bravely overcome the problems it itself has created, and it prevents them from realizing how limited those crutches are.
- KaiserPro 3y ago
  perl is not a perfect language. nobody should be claiming that. They way function args are define is just pure passive aggression (oh so you _want_ people to name args properly eh? go on, you validate the arg name. Go on, fiddle with the hash like that). However we should be able to look at any language and pull out its interesting/useful features. I loved perl's can do attitude. You wanna do that to an array? sure. it'd going to end bad, but here you go kid, have at it. Is that good for everyone? no. does it mean that you need to be hilariously disciplined to make readable code? very yes. Can one make readable and maintainable code in perl? hell yes. I've worked on some wonderfully maintainable perl code. I've also worked on a lot of shite. But then the same goes for python. I transmute research code into production, and let me tell you, there are some "perls" of programmers right there.
- duskwuff 3y ago
  I'm not saying that Perl is perfect. Far from it. But saying that Python "will complain about unbound variables instead of silently creating them" is simply incorrect. One of the defining characteristics of Python's variable scope is that assigning to a name always creates it in the current scope; there's no other way to declare a variable. And that's all I'm trying to demonstrate here.
  - WesolyKubeczek 3y ago
    The act of assigning is creating a variable; the act of using it will complain about an unbound variable. Perl in non-strict mode, PHP last I touched it, Bourne-style shells will just go “yeah, whatever, here’s an empty string”.
KaiserPro 3y ago
yes! exactly this. Now obviously people would say "just use a linter" but its not actually as reliable as a builtin. Moreover, people who have dyslexia are not always able to spot stuff like this.