3 ms·

I've been using python for many, many years. One thing that always bugged me was the lack of "strict" mode (see perl) For those of you not blessed enough to h

I've been using python for many, many years. One thing that always bugged me was the lack of "strict" mode (see perl) For those of you not blessed enough to have done any serious perl, strict was a way of making sure that you hadn't accidentally assigned an output to a spelling mistake. In other words you had to declare all your variables _before_ you used them. I got used to the lack of it, and grew to rely on pylint and other tools. Then I went back to C++ (fuck that as ever) and started c#. I really like c#, and I finally realised what I thought was missing from python: semi static typing. Sure, you can use type hints, but they are pretty much useless as they have no runtime effect, so are basically highly schema'd comments. What I would love is a mode in python where instead of duck typing everything, its statically typed, unless I do a magical incantation. I know that will never happen, as its against python's core values. Its also entirely no trivial to re-build the interpreter. But it would mean we can stop type checking all the time & catch a fucktonne of bugs early.

deleted 3y ago
[deleted]
WesolyKubeczek 3y ago
> 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.
sk11001 3y ago
Type hints aren't useless - you can type check your code before you run it (and they make your code more readable). > What I would love is a mode in python where instead of duck typing everything, its statically typed, unless I do a magical incantation. You can do this with mypy, you can set it to require types everywhere.
XCabbage 3y ago
You get 99% of what you want by just using Python with Mypy (as a pre-commit hook, editor plugin, and/or CI step). Python has static type checking; it just comes in the form of Mypy instead of being baked into the Python executable.
- KaiserPro 3y ago
  So I work with a reasonably well typed codebase, type hints are great for documentation. Especially as most people where I work fear writing any kind reason _why_ they wrote what they wrote. But it don't help with stuff that gets transmuted in flight. Granted with pydactic is your friend here, but thats a lot of work to backport. basically I want c#'s typing system with python's syntax.

deleted 3y ago

[deleted]

WesolyKubeczek 3y ago

> 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.

sk11001 3y ago

Type hints aren't useless - you can type check your code before you run it (and they make your code more readable). > What I would love is a mode in python where instead of duck typing everything, its statically typed, unless I do a magical incantation. You can do this with mypy, you can set it to require types everywhere.

XCabbage 3y ago

You get 99% of what you want by just using Python with Mypy (as a pre-commit hook, editor plugin, and/or CI step). Python has static type checking; it just comes in the form of Mypy instead of being baked into the Python executable.

KaiserPro 3y ago
So I work with a reasonably well typed codebase, type hints are great for documentation. Especially as most people where I work fear writing any kind reason _why_ they wrote what they wrote. But it don't help with stuff that gets transmuted in flight. Granted with pydactic is your friend here, but thats a lot of work to backport. basically I want c#'s typing system with python's syntax.