3 ms·

> Is that a problem in practice in Python? > I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring

> Is that a problem in practice in Python? > I prefer being able to tell if something is a collection, and which core type of collection, at a glance (barring refs). Not really a problem, but if you're writing more than a one-off script, such as a module you plan on sharing, it may be common that you get a mixture of concrete types coming in depending on the app and platform. I think in practice, it's actually beneficial to assume you do not know the core type of collection (if your operations will work with many/all of them). For example, a range object or generator in Python 3, but a list in Python 2. And then someone else comes along and uses your modules with sets. So with "fruits" (or something like "fruit_iter" for anyone who disagrees with plural naming), you know that you can safely iterate through it. But you may not be able to do random access, or reassignment of elements. There might be times when this matters, in which case you'd want to enforce a specific type. The only thing I do not like about this is that in Python strings are also iterables. So the difference between passing "Apple" and ["apple"] can be quite large, and yet your program will iterate through "a", "p", "p", "l", "e" with no complaints. The worst experience I've had with this was working with a web API that would return either an array of strings, or only a string if there was one result (not a 1-element array), or a dictionary of objects if there were many results. 99% percent of the time it returned the array of string, and since strings and dictionaries are iterable, it took me a while to notice the bug. I ought to learn Perl, because that's pretty cool. You're right that that example is terrible to read, haha, but I'm sure there are scenarios where it's helpful.

kbenson 11y ago
> The only thing I do not like about this is that in Python strings are also iterables. This touches on a big pet peeve of mine, and coincides with some ranting I was doing on the Scala Native post the other day. :) Languages that support coercion should try to make sure they don't overload core operators for different types of operations for different core types. E.g. '+' for numerical addition and string concatenation (one is commutative, the other is not, and if you decide on which action to take depending the order of variables, that's confusing), or ==/!= for string equivalence and numerical equivalence (10.0 and 10 are numerically equivalent, but for strings we generally want an exact match). Having an iterating operation work on a string without any preparation is one of those things that seems simple and useful, but likely causes a lot of confusion in dynamic languages in practice because you lose track of exactly what it's possible a variable can hold because it's often dependent on the return value of someone else's function. I imagine exposing a method on strings that returned an iterable interface, and requiring that be the method you iterate over a string, would reduce that confusion quite a bit. > I ought to learn Perl, because that's pretty cool. I think it's worth picking up the core concepts for anyone, because there's a few concepts (e.g. context) it implements as core parts of the language that are still rarely used elsewhere. Unfortunately, its hybrid beginnings mean that you can largely miss the importance of things like context early on because the code looks enough like what you are used to that you assume it works the exact same way, and 95% of the time that's true. The other 5% will leave you scratching your head and wonder why Perl seems so stupid or inconsistent, when really your mental model is wrong. List and scalar context and how they apply to the core types should be the first learning item on a new Perl programmer's list if they know another C-like language.

kbenson 11y ago

> The only thing I do not like about this is that in Python strings are also iterables. This touches on a big pet peeve of mine, and coincides with some ranting I was doing on the Scala Native post the other day. :) Languages that support coercion should try to make sure they don't overload core operators for different types of operations for different core types. E.g. '+' for numerical addition and string concatenation (one is commutative, the other is not, and if you decide on which action to take depending the order of variables, that's confusing), or ==/!= for string equivalence and numerical equivalence (10.0 and 10 are numerically equivalent, but for strings we generally want an exact match). Having an iterating operation work on a string without any preparation is one of those things that seems simple and useful, but likely causes a lot of confusion in dynamic languages in practice because you lose track of exactly what it's possible a variable can hold because it's often dependent on the return value of someone else's function. I imagine exposing a method on strings that returned an iterable interface, and requiring that be the method you iterate over a string, would reduce that confusion quite a bit. > I ought to learn Perl, because that's pretty cool. I think it's worth picking up the core concepts for anyone, because there's a few concepts (e.g. context) it implements as core parts of the language that are still rarely used elsewhere. Unfortunately, its hybrid beginnings mean that you can largely miss the importance of things like context early on because the code looks enough like what you are used to that you assume it works the exact same way, and 95% of the time that's true. The other 5% will leave you scratching your head and wonder why Perl seems so stupid or inconsistent, when really your mental model is wrong. List and scalar context and how they apply to the core types should be the first learning item on a new Perl programmer's list if they know another C-like language.