3 ms·

> I had a bug where I changed the return type of a function to be a tuple > If a given programming language community winds up bleeding members who are moving

by dkarl 4y ago

> I had a bug where I changed the return type of a function to be a tuple > If a given programming language community winds up bleeding members who are moving on due to the lack of better static type checking systems, then the people left will invariably be much more likely to be against static type systems. This reminds me of one of the things I hate most about the Python library ecosystem: libraries attempt to camouflage type errors resulting from changes like this. Something that should be an immediate runtime error turns into a subtle production bug. I discovered an error of this kind just this week while doing what I often have to do when refactoring someone else's code in Python: reading and distrusting every single damned line. Which led to reading the source code of a third-party library, where I discovered something that I've seen often enough that I'm starting to think it's some kind of norm in Python libraries: A function is documented to take a list of Foo. But if the value you pass is not a list, it doesn't throw an error. If the value is None, it uses []. If the value is a set or a generator or a tuple, it uses list(value). If the value is none of those things, it uses [value]. Now that it has a list, it looks at the values in the list, and for any value that isn't a Foo instance, it does its best to handle it. For example, if it's a str, it passes the value to the Foo constructor. This might feel helpful for beginners and non-professionals just trying to get something to work on a single data set, testing everything by hand, but it amounts to passive-aggressive betrayal when you're trying to maintain a large codebase with multiple contributors. In the case I discovered this week, instead of an immediate runtime error prompting the programmer to make a trivial fix in their code, we had a feature subtly degraded in production for months. Very "helpful."

HdS84 4y ago
What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else. And yes generally agree that Paramus should be not be too accepting. It gets confusing fast.
- collinmanderson 4y ago
  > What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else. Python has an Iterable type class for this. https://docs.python.org/3/library/typing.html#nominal-vs-structural-subtyping https://docs.python.org/3/library/typing.html#nominal-vs-str... https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable https://docs.python.org/3/library/collections.abc.html#colle...

by dkarl 4y ago

HdS84 4y ago

What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else. And yes generally agree that Paramus should be not be too accepting. It gets confusing fast.

collinmanderson 4y ago
> What's missing here is an Ienumerable from c#. That's basically anything that can be iterated like a list. So a function could take this enumerable and convert it to a list but should probably reject everything else. Python has an Iterable type class for this. https://docs.python.org/3/library/typing.html#nominal-vs-structural-subtyping https://docs.python.org/3/library/typing.html#nominal-vs-str... https://docs.python.org/3/library/collections.abc.html#collections.abc.Iterable https://docs.python.org/3/library/collections.abc.html#colle...