6 ms·

Well join should be on sequence instead of list then. To me it seems unnatural to see join on string because string feels more 'basic' than a sequence, so I wo

by zupatol 18y ago

Well join should be on sequence instead of list then. To me it seems unnatural to see join on string because string feels more 'basic' than a sequence, so I would expect the sequence to know about strings rather than the opposite. But the argument against join on string is not as strong as the argument against sum on array.

calambrac 18y ago
This is such a non-issue. Really. The parent posted the reasoning behind the decision, that reasoning is sound. Your disagreement is purely aesthetic, there's simply no practical reason why the current way is wrong. Please just accept that this is how it is, and stop complaining about it. Please?
- philh 18y ago
  Python is intended to be aesthetically pleasing in some sense, so I don't think aesthetic objections to some of its features are unwarranted.
  - calambrac 18y ago
    This isn't one of the 'some'. http://en.wikipedia.org/wiki/Color_of_the_bikeshed http://en.wikipedia.org/wiki/Color_of_the_bikeshed
    - scott_s 18y ago
      I don't think this is bike-shedding. That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. In this case, their objection is that it violates their intuition, but the placement of join is a natural result of how Python's types are defined. Defining join on all sequences would have real (annoying) implications.
      - calambrac 18y ago
        That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. How does that not fit this situation? Because there's actually a good technical reason to do it the way it's currently done? Wouldn't that imply that there should be even less discussion of it?
        scott_s 18y ago
        No, because the discussion should be explaining that good technical reason. Which is what happened. Bike-shedding is when the arguments have relatively the same merit, and the choice makes little difference in the end. I don't think either applies. An example of bike-shedding in this context would be renaming join to fuse.
        calambrac 18y ago
        Bike-shedding is when someone feels the need to interject their opinion simply because the topic is something they feel they understand, regardless of whether that interjection actually contributes anything. Bitching that '\n'.join(alist) should be alist.join('\n') is a favorite pastime of people who want to demonstrate that they've heard of OO programming. It's a perfect example of bike-shedding.
        scott_s 18y ago
        When I use the term, I assume both sides have marginal arguments - so the resulting discussion is a waste of time. I use it this way to remind a group that we're not discussing something important. But if one of the sides has merit, than it's important for the other side to understand that.
        calambrac 18y ago
        You can't just make up your own definition of a well-known term and then call people wrong when they use it correctly: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/u...
- nostrademons 18y ago
  That was my point when I started the thread. The Python decision is objectively justified for technical reasons. Yet a large number of people viscerally feel it's wrong. I blame human irrationality - but then, programming languages are meant for humans, so shouldn't they accommodate our irrationality? Otherwise, you get something like Haskell. ;-) BTW, there are other cases where Python has gone the other way. Multiline lambdas, for instance. The case against multiline lambdas is essentially that they look ugly - they let you embed an indentation-sensitive block in what might be a parenthesized expression, which means you need some dangling delimiters. But they're certainly useful, as Scheme/Lisp/Ocaml/etc. have shown. It's similar to the compare-constants-from-the-left idiom in languages where assignment is a valid expression (notably C). If you always write "if (NULL == foo)" instead of "if (foo == NULL)", you eliminate a whole class of bugs. But I've seen very few programmers do this, because it "feels" wrong to a lot of people.
  - calambrac 18y ago
    I completely agreed with your original point. The fact that we went from your comment to people actually bitching about join made me really sad. I shouldn't have said that the join argument was "purely aesthetic", I should have said that it was "purely aesthetic and trivial", because you're right, aesthetics are important, and (imo) are reason enough to disallow multiline lambdas. How do you cross the line from trivial to not? I don't know exactly, but I do know that swapping the position of the involved nouns and taking up the same number of characters for a good technical reason doesn't.
  - lacker 18y ago
    "if (NULL == foo)" and "'\n'.join(lines)" both feel wrong because you are putting the most complicated object last. The most complicated thing should go first so you can sooner figure out what the heck this line of code is talking about. I would support making the C compiler just disallow "if (x = y)".
    - nostrademons 18y ago
      OTOH, in languages that support first-class functions, it's pretty common to put the functional argument last because then it can wrap to another line without leaving dangling parameters: $.each(my_array, function(val) { // Do something // Do something else }); That's putting the most complicated object last, and feels much more natural than: $.each(function(val) { // Do something // Do something else }, my_array); I suspect it's more that English has trained us to read "noun verb object" sentences. In an if statement, `foo` feels like the subject, and then "== NULL" is the predicate. In an array map, the array is the subject, and the function is the predicate. In the Python join example, the array feels like the subject, "join" is the verb, and "," is the object, which is what makes it seem so awkward. Ruby's array.sum feels more natural because the array is the subject and sum is an intransitive verb.
scott_s 18y ago
That's just the thing: there is no sequence class in Python. There's only a sequence concept. A sequence is any object that implements a particular interface. Strings aren't more basic than the concept of a sequence in Python; strings are a type of sequence. See http://docs.python.org/library/stdtypes.html#iterator-types http://docs.python.org/library/stdtypes.html#iterator-types and http://docs.python.org/library/stdtypes.html#http://docs.python.org/library/stdtypes.html#sequence-types-str-unicode-list-tuple-buffer-xrange http://docs.python.org/library/stdtypes.html#http://docs.pyt...
jerf 18y ago
I anticipated this objection if you go back and re-read my post, but I'll blow out the point a bit more here: In Java terms, "sequence" is an interface. You can't put join there. Because then you have to put add, any, none, all, reduce, filter, and so on and so forth for at least another ten or twenty base methods (ignoring everything else that applies just to the sequence protocol written by users), which every single implementation would then have to provide. No matter how abstractly beautiful it may be that this implements object-orientation dogma, in practice it's an idea too stupid to even begin to consider.
- litewulf 18y ago
  Thankfully there is this concept of mixins (and, gasp, multiple inheritance), to solve some of these issues.
tetha 18y ago
I think, the join-akwardness in python mostly is a single-dispatch issue. Both variants, glue.join(sequence) and sequence.get_joined_by(glue) make some sort of sense, however, neither strikes all readers as the one obvious thing that obviously is right. (Compare similar single dispatch issues like: Will the employee have a add_to_department or will the department have a get_new_employee?) Thus, I think, the cleanest solution would be a generic method join(glue, string) so you just call join('\n', lines). This removes the question if the glue is more responsible in the join process or if the sequence is more important in the join process, because both are equally important.

by zupatol 18y ago

calambrac 18y ago

This is such a non-issue. Really. The parent posted the reasoning behind the decision, that reasoning is sound. Your disagreement is purely aesthetic, there's simply no practical reason why the current way is wrong. Please just accept that this is how it is, and stop complaining about it. Please?

philh 18y ago
Python is intended to be aesthetically pleasing in some sense, so I don't think aesthetic objections to some of its features are unwarranted.
- calambrac 18y ago
  This isn't one of the 'some'. http://en.wikipedia.org/wiki/Color_of_the_bikeshed http://en.wikipedia.org/wiki/Color_of_the_bikeshed
  - scott_s 18y ago
    I don't think this is bike-shedding. That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. In this case, their objection is that it violates their intuition, but the placement of join is a natural result of how Python's types are defined. Defining join on all sequences would have real (annoying) implications.
    - calambrac 18y ago
      That applies when people argue over two functionally equivalent options, often to the detriment of more important issues. How does that not fit this situation? Because there's actually a good technical reason to do it the way it's currently done? Wouldn't that imply that there should be even less discussion of it?
      - scott_s 18y ago
        No, because the discussion should be explaining that good technical reason. Which is what happened. Bike-shedding is when the arguments have relatively the same merit, and the choice makes little difference in the end. I don't think either applies. An example of bike-shedding in this context would be renaming join to fuse.
        calambrac 18y ago
        Bike-shedding is when someone feels the need to interject their opinion simply because the topic is something they feel they understand, regardless of whether that interjection actually contributes anything. Bitching that '\n'.join(alist) should be alist.join('\n') is a favorite pastime of people who want to demonstrate that they've heard of OO programming. It's a perfect example of bike-shedding.
        scott_s 18y ago
        When I use the term, I assume both sides have marginal arguments - so the resulting discussion is a waste of time. I use it this way to remind a group that we're not discussing something important. But if one of the sides has merit, than it's important for the other side to understand that.
        calambrac 18y ago
        You can't just make up your own definition of a well-known term and then call people wrong when they use it correctly: http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/usr/local/www/db/text/1999/freebsd-hackers/19991003.freebsd-hackers http://www.freebsd.org/cgi/getmsg.cgi?fetch=506636+517178+/u...
nostrademons 18y ago
That was my point when I started the thread. The Python decision is objectively justified for technical reasons. Yet a large number of people viscerally feel it's wrong. I blame human irrationality - but then, programming languages are meant for humans, so shouldn't they accommodate our irrationality? Otherwise, you get something like Haskell. ;-) BTW, there are other cases where Python has gone the other way. Multiline lambdas, for instance. The case against multiline lambdas is essentially that they look ugly - they let you embed an indentation-sensitive block in what might be a parenthesized expression, which means you need some dangling delimiters. But they're certainly useful, as Scheme/Lisp/Ocaml/etc. have shown. It's similar to the compare-constants-from-the-left idiom in languages where assignment is a valid expression (notably C). If you always write "if (NULL == foo)" instead of "if (foo == NULL)", you eliminate a whole class of bugs. But I've seen very few programmers do this, because it "feels" wrong to a lot of people.
- calambrac 18y ago
  I completely agreed with your original point. The fact that we went from your comment to people actually bitching about join made me really sad. I shouldn't have said that the join argument was "purely aesthetic", I should have said that it was "purely aesthetic and trivial", because you're right, aesthetics are important, and (imo) are reason enough to disallow multiline lambdas. How do you cross the line from trivial to not? I don't know exactly, but I do know that swapping the position of the involved nouns and taking up the same number of characters for a good technical reason doesn't.
- lacker 18y ago
  "if (NULL == foo)" and "'\n'.join(lines)" both feel wrong because you are putting the most complicated object last. The most complicated thing should go first so you can sooner figure out what the heck this line of code is talking about. I would support making the C compiler just disallow "if (x = y)".
  - nostrademons 18y ago
    OTOH, in languages that support first-class functions, it's pretty common to put the functional argument last because then it can wrap to another line without leaving dangling parameters: $.each(my_array, function(val) { // Do something // Do something else }); That's putting the most complicated object last, and feels much more natural than: $.each(function(val) { // Do something // Do something else }, my_array); I suspect it's more that English has trained us to read "noun verb object" sentences. In an if statement, `foo` feels like the subject, and then "== NULL" is the predicate. In an array map, the array is the subject, and the function is the predicate. In the Python join example, the array feels like the subject, "join" is the verb, and "," is the object, which is what makes it seem so awkward. Ruby's array.sum feels more natural because the array is the subject and sum is an intransitive verb.

scott_s 18y ago

That's just the thing: there is no sequence class in Python. There's only a sequence concept. A sequence is any object that implements a particular interface. Strings aren't more basic than the concept of a sequence in Python; strings are a type of sequence. See http://docs.python.org/library/stdtypes.html#iterator-types http://docs.python.org/library/stdtypes.html#iterator-types and http://docs.python.org/library/stdtypes.html#http://docs.python.org/library/stdtypes.html#sequence-types-str-unicode-list-tuple-buffer-xrange http://docs.python.org/library/stdtypes.html#http://docs.pyt...

jerf 18y ago

I anticipated this objection if you go back and re-read my post, but I'll blow out the point a bit more here: In Java terms, "sequence" is an interface. You can't put join there. Because then you have to put add, any, none, all, reduce, filter, and so on and so forth for at least another ten or twenty base methods (ignoring everything else that applies just to the sequence protocol written by users), which every single implementation would then have to provide. No matter how abstractly beautiful it may be that this implements object-orientation dogma, in practice it's an idea too stupid to even begin to consider.

litewulf 18y ago
Thankfully there is this concept of mixins (and, gasp, multiple inheritance), to solve some of these issues.

tetha 18y ago

I think, the join-akwardness in python mostly is a single-dispatch issue. Both variants, glue.join(sequence) and sequence.get_joined_by(glue) make some sort of sense, however, neither strikes all readers as the one obvious thing that obviously is right. (Compare similar single dispatch issues like: Will the employee have a add_to_department or will the department have a get_new_employee?) Thus, I think, the cleanest solution would be a generic method join(glue, string) so you just call join('\n', lines). This removes the question if the glue is more responsible in the join process or if the sequence is more important in the join process, because both are equally important.