• 0 Posts
  • 4 Comments
Joined 1 year ago
cake
Cake day: June 18th, 2023

help-circle

  • I have to be honest in that, while I think duck typing should be embraced, I have a hard time seeing how people are actually able to deal with large-scale pure Python projects, just because of the dynamic typing. To me, it makes reading code so much more difficult when I can’t just look at a function and immediately see the types involved.

    Because of this, I also have a small hangup with examples in some C++ libraries that use auto. Like sure, I’m happy to use auto when writing code, but when reading an example I would very much like to immediately be able to know what the return type of a function is. In general, I think the use of auto should be restricted to cases where it increases readability, and not used as a lazy way out of writing out the types, which I think is one of the benefits of C++ vs. Python in large projects.


  • The amount of people I’ve been helping out that have copied some code from somewhere and say “it doesn’t work”, and who are dumbfounded when I ask them to read the surrounding text aloud for me…

    Along the same line: When something crashes, and all I have to do is tell people to read the error message aloud, and ask them what that means. It’s like so many people expect to be spoon-fed solutions, to the point where they don’t even stop to think about the problem if something doesn’t immediately work.


  • While I do agree with most of what is said here, I have a hangup on one of the points: Thinking that “docstrings and variable names” are a trustworthy way to indicate types. Python is not a statically typed language - never will be. You can have as much type hinting as you want, but you will never have a guarantee that some variable holds the type you think it does, short of checking the type at runtime. Also, code logic can change over time, and there is no guarantee that comments, docstrings and variable names will always be up to date.

    By all means, having good docstrings, variable names, and type hinting is important, but none of them should be treated as some kind of silver bullet that gets you around the fact that I can access __globals__ at any time and change any variable to whatever I want if I’m so inclined.

    This doesn’t have to be a bad thing though. I use both Python and C++ daily, and think that the proper way to use Python is to fully embrace duck typing. However that also means my code should be written in such a way that it will work as long as whatever input to it conforms loosely to whatever type I’m expecting to receive.