5 ms·

The following example is kinda funny: // This is obviously not too right ",".splitBy("1,2,3,4,5") // This should be right, because it reads out mo

• IshKebab 6y ago
  Yeah Python (and I think JavaScript?) pretty clearly have `join` backwards.
  • b34r 6y ago
    JS uses the second example
    • linkdd 6y ago
      It is because in Javascript everything can be translated to a string: 1 + "hello" == "1hello" Therefore, the type Array can have a join method that have predictable results (unlike Python).
      • Zarel 6y ago
        I don't know what that has to do with `join`'s call order. As mentioned above, it's because Python supports `join` on any sequence, not just the array class. Personally, I find JavaScript's solution neater: [..."hello"].join(" ") === "h e l l o"
        • linkdd 6y ago
          Because when the Javascript engine will try to concatenate all the strings in the Array (the expected behavior of join), it will first translate every object in the array to a string. Javascript always falls back to string, that is also why we have === and == operators. Python's type system is a bit more strict because it will not attempt to serialize your objet if you haven't explicitly done it yourself. My point is: Python doesn't use this notation because it would not make sense in Python.
          • maest 6y ago
            This is also the cause of this lovely bit of JS behaviour: >>> [1,2,10].sort() Array(3) [ 1, 10, 2 ]
• pmontra 6y ago
  Exactly what I came here to write about: Python 3.8.2 (default, Jul 16 2020, 14:00:26) >>> " ".join(["a", "b"]) 'a b' vs Ruby 2.6.5 :001 > ["a", "b"].join(" ") => "a b" I don't know which one is more natural but I prefer the Ruby version because it's consistent with "a b".split(" ") which works in both languages. One less think to remember.
  • linkdd 6y ago
    In Python: ["a", "b"].join(" ") This would mean the type list has a method join, how would it work with the following ? [1.5, "hello", None].join(" ")
    • rgoulter 6y ago
      >>> " ".join([1.5, "hello", None]) Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: sequence item 0: expected string, float found Why would `[1.5, "hello", None].join(" ")` be any different?
      • linkdd 6y ago
        Because "list of string" is not a type in Python. Why would you put a method on a class if only a small subset of it can use it?
        • Mathnerd314 6y ago
          That happens all the time, since Python is dynamically typed. For example a[10] gives an IndexError if a has less than 11 elements. So with static typing, we should restrict indexing to ensure that the number of elements needed are present, and remove indexing from general lists. But you wouldn't remove indexing from lists, that's one of the main functions...
        • matt_kantor 6y ago
          Either way it's a partial function that is not defined for most of its domain. The only difference is how its arguments (including self) get arranged at call sites, right?
• thefifthsetpin 6y ago
  If I were designing a functional language, I'd be thinking about whether data.splitBy or delimiter.split was useful even when not immediately invoked. Consider this crude csv parser: using splitBy: csv.splitBy("\n").map(csv_row=>csv_row.splitBy(",")) using split: "\n".split(csv).map(",".split) split was the clear winner here. Given splitBy, I basically recreated split as a lambda. I tried to create an analog to that where splitBy would come out looking better. I figured that if we didn't know the dimensionality of our data, then delimiters becomes an array of arbitrary length and we could pass data.!splitBy into something like delimiters.reduce. When actually writing that, however, I wound up recreating split again: using splitBy: delimiters.reduce((accum,delim)=>accum.deepMap(data=>data.splitBy(delim)),[data]) using split: delimiters.reduce((accum,delim)=>accum.deepMap(delim.split),[data])