Re: sequence multiplied by -1

Discussion in 'Python' started by Thomas Jollans, Sep 25, 2010.

  1. On Saturday 25 September 2010, it occurred to Yingjie Lan to exclaim:
    > Hi,
    >
    > I noticed that in python3k, multiplying a sequence by a negative integer is
    > the same as multiplying it by 0, and the result is an empty sequence. It
    > seems to me that there is a more meaningful symantics.


    Um...

    for every list l and integer n >= 0:
    len(l*n) == len(l)*n

    Multiplying a list by a negative integer should produce a list of negative
    length, which does not exist. IMHO, the only correct behaviour would be to
    raise an exception, though one could argue that there are practical benefits
    for the operation to succeed for any integer operand.

    >
    > Simply put, a sequence multiplied by -1 can give a reversed sequence.


    For that, we have slicing. A negative step value produces a reverse slice of
    the list. You can't argue that this makes sense, can you

    >>> [1,2,3,4][::-1]

    [4, 3, 2, 1]
    >>> [1,2,3,4][::-2]

    [4, 2]
    >>>
     
    Thomas Jollans, Sep 25, 2010
    #1
    1. Advertising

  2. On Sat, 25 Sep 2010 13:45:11 +0200, Thomas Jollans wrote:

    > On Saturday 25 September 2010, it occurred to Yingjie Lan to exclaim:
    >> Hi,
    >>
    >> I noticed that in python3k, multiplying a sequence by a negative
    >> integer is the same as multiplying it by 0, and the result is an empty
    >> sequence. It seems to me that there is a more meaningful symantics.

    >
    > Um...
    >
    > for every list l and integer n >= 0:
    > len(l*n) == len(l)*n
    >
    > Multiplying a list by a negative integer should produce a list of
    > negative length, which does not exist.


    Look at the domain of your invariance. It says nothing about negative n,
    and nor should it.


    > IMHO, the only correct behaviour
    > would be to raise an exception, though one could argue that there are
    > practical benefits for the operation to succeed for any integer operand.


    Since lists of negative length don't exist, we're free to set the
    invariance to something which has a less restrictive domain and is more
    useful than raising an exception:

    for every list l and integer n:
    len(l*n) == len(l)*max(0, n)


    >> Simply put, a sequence multiplied by -1 can give a reversed sequence.

    >
    > For that, we have slicing. A negative step value produces a reverse
    > slice of the list. You can't argue that this makes sense, can you
    >
    >>>> [1,2,3,4][::-1]

    > [4, 3, 2, 1]
    >>>> [1,2,3,4][::-2]

    > [4, 2]


    Why does it not make sense?


    I'm more concerned that the simple idiom:

    # list L must have at least 5 items, so extend it with None if needed
    L.extend([None]*(5 - len(L))

    would suddenly break with this proposal.


    --
    Steven
     
    Steven D'Aprano, Sep 26, 2010
    #2
    1. Advertising

  3. Thomas Jollans

    John Nagle Guest

    On 9/25/2010 4:45 AM, Thomas Jollans wrote:
    > On Saturday 25 September 2010, it occurred to Yingjie Lan to exclaim:
    >> Hi,
    >>
    >> I noticed that in python3k, multiplying a sequence by a negative integer is
    >> the same as multiplying it by 0, and the result is an empty sequence. It
    >> seems to me that there is a more meaningful symantics.


    The concept that the multiply operator should be overloaded to
    do something l33t on sequences was a Python design mistake. It
    leads to semantics like this:

    x = 10
    y = "10"

    x*2
    20
    y*2
    '1010'
    int(y*2)
    1010
    int(y)*2
    20

    That's awful. It's the kind of thing a novice C++
    programmer would write shortly after they discovered operator
    overloading.

    Now, ask yourself, when you get a numeric value back from
    a database, is it an integer or a string? How about the CSV
    module? Are you sure?

    John Nagle
     
    John Nagle, Sep 26, 2010
    #3
  4. On Sat, 25 Sep 2010 22:08:54 -0700, John Nagle wrote:

    > On 9/25/2010 4:45 AM, Thomas Jollans wrote:
    >> On Saturday 25 September 2010, it occurred to Yingjie Lan to exclaim:
    >>> Hi,
    >>>
    >>> I noticed that in python3k, multiplying a sequence by a negative
    >>> integer is the same as multiplying it by 0, and the result is an empty
    >>> sequence. It seems to me that there is a more meaningful symantics.

    >
    > The concept that the multiply operator should be overloaded to
    > do something l33t on sequences was a Python design mistake.


    Repetition is a simple, useful operation, and describing it pejoratively
    as "l33t" is just silly.


    > It leads to semantics like this:
    >
    > x = 10
    > y = "10"
    >
    > x*2
    > 20
    > y*2
    > '1010'
    > int(y*2)
    > 1010
    > int(y)*2
    > 20



    Yes. Where's the problem?

    Are you also concerned that int(max("230", "9")) returns 9 but max(int
    ("230"), int("9")) returns 230?

    It's obvious that there is no such invariant that int(f(y)) must equal
    f(int(y)) for arbitrary functions f, so why do you think that the failure
    of this invariant to hold for the * operator matters in the least?



    > That's awful. It's the kind of thing a novice C++
    > programmer would write shortly after they discovered operator
    > overloading.


    So you say.


    > Now, ask yourself, when you get a numeric value back from
    > a database, is it an integer or a string? How about the CSV module?
    > Are you sure?


    If you're not sure what sort of data you're getting, you've got no
    business blindly applying functions in some arbitrary order to it in the
    hope that the result will be sensible. If the data is meant to be an
    integer, and you might get a string from the database, then convert it to
    an integer as soon as possible. I'm surprised that you think that you
    should be able to apply arbitrary mathematical operations to strings
    *before* turning them into an int and still get sensible results. That
    boggles my mind.



    --
    Steven
     
    Steven D'Aprano, Sep 26, 2010
    #4
  5. Thomas Jollans

    Paul Rubin Guest

    Steven D'Aprano <> writes:
    > I'm surprised that you think that you should be able to apply
    > arbitrary mathematical operations to strings *before* turning them
    > into an int and still get sensible results. That boggles my mind.


    I think the idea is you should not be able to do mathematical operations
    on strings, and if you try to do one, Python should raise an exception,
    rather than using hokey analogies to guess at what you were trying to
    do. If you want to replicate a sequence, introduce a function with a
    name like "replicate", rather than overloading an arithmetic operator.
     
    Paul Rubin, Sep 26, 2010
    #5
  6. On Sat, 25 Sep 2010 23:46:57 -0700, Paul Rubin wrote:

    > Steven D'Aprano <> writes:
    >> I'm surprised that you think that you should be able to apply arbitrary
    >> mathematical operations to strings *before* turning them into an int
    >> and still get sensible results. That boggles my mind.

    >
    > I think the idea is you should not be able to do mathematical operations
    > on strings, and if you try to do one, Python should raise an exception,
    > rather than using hokey analogies to guess at what you were trying to
    > do. If you want to replicate a sequence, introduce a function with a
    > name like "replicate", rather than overloading an arithmetic operator.


    But * isn't a mathematical operation on sequences. It's a repetition
    operator. And repetition isn't a "hokey analogy" of multiplication --
    you've got it completely backwards. Multiplication is a generalisation of
    repetition, and sequence repetition is more fundamental than mathematical
    multiplication. Long before anyone said 2.3 * 5.7 people were able to
    talk about "two bags of wheat, and another two bags of wheat, and repeat
    six more times". That's how multiplication was invented -- from repeated
    addition. Think of writing numbers as tallies, before the invention of
    arabic numerals. III groups of II would be IIIIII.

    The semantics of list.index() and str.index() are not quite the same
    (string indexing finds substrings, while list indexing does not find
    sublists). So what? We have classes and modules and namespaces so that
    you don't need every function to have a unique. It's okay that the index
    method behaves slightly differently when operating on strings and lists,
    and it's okay for the * operator to behave slightly differently too.

    It is true that there's a certain class of coders who apparently like
    line-noise, and so they overload operators to do arbitrary things with no
    concern about familiarity with common convention or readability:

    # sort the sequence by length
    my_seq ** len

    But this is bad because there's no convention for exponentiation being
    related to sorting, and so the code is obscure and unintuitive. Without
    the comments, you would have no idea what the line did. But that's just
    the same as doing this:

    def raise_to_power(alist, key):
    alist.sort(key=key)
    return alist

    This is dumb whether you overload the ** operator or write a function
    called "raise_to_power".

    There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",
    and the fact that it doesn't do the same thing as int("spam")*3 is a
    foolish argument.


    --
    Steven
     
    Steven D'Aprano, Sep 26, 2010
    #6
  7. Thomas Jollans

    Paul Rubin Guest

    Steven D'Aprano <> writes:
    > There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",

    Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?
    Should "spam"*2.5 be "spamspamsp"?
    Should "spam"-"a" be "spm"? What about "spamspam"-"a"?
    And what about "spam"/2? "sp" be an ok first guess, but "sa" might
    make more sense (it means (1,2,3,...)/2 would be (1,3,5...)).

    I say it's all hokey from the get-go ;-).
     
    Paul Rubin, Sep 26, 2010
    #7
  8. Thomas Jollans

    Seebs Guest

    On 2010-09-26, Steven D'Aprano <> wrote:
    > On Sat, 25 Sep 2010 23:46:57 -0700, Paul Rubin wrote:
    >> I think the idea is you should not be able to do mathematical operations
    >> on strings, and if you try to do one, Python should raise an exception,
    >> rather than using hokey analogies to guess at what you were trying to
    >> do. If you want to replicate a sequence, introduce a function with a
    >> name like "replicate", rather than overloading an arithmetic operator.


    > But * isn't a mathematical operation on sequences. It's a repetition
    > operator.


    I think Paul's point is that "*" is in general a mathematical operation,
    and discovering that for some types of objects, it's been given a
    fundamentally unrelated meaning can certainly be a bit of a surprise.

    I actually sort of like that perl has a separate repetition operator.
    And really, when you find yourself saying something nice about perl's
    syntax or punctuation, that's always scary territory to be in.

    > There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",
    > and the fact that it doesn't do the same thing as int("spam")*3 is a
    > foolish argument.


    The languages in which it's surprising are mostly things like perl, where
    there's a certain amount of implicit coercion going on, so it's ambiguous
    whether "3"*3 ought to mean "333" or 9. (Except it isn't, because repetition
    is a separate operator, written "3" x 3 rather than "3" * 3...) People
    coming from that kind of background may be expecting * to stay an
    arithmetic operator, rather than having it change form when applied to
    non-arithmetic objects.

    I'm not sure either way. I think on the whole, I like the notion of
    a repetition operator which is distinct from multiplication, but I also
    definitely prefer the lack of implicit coercion, and without implicit
    coercion, there's a lot less underlying ambiguity to worry about.

    From the top, I guess my analysis is:

    * It seems clear that, given two sequences x and y, "x + y" ought to
    be the concatenation of these sequences.
    * Thus, "x + x" should be x concatenated to itself.
    * Idiomatically, it is not unreasonable to assert that "x * 2" and "x + x"
    could be the same value.
    * It thus makes some sense for <sequence> * <number> to indicate
    repetition of the sequence.
    * Since a string is a kind of a sequence, it also makes sense for
    <string> * <number> to indicate repetition.

    So I think I'm pretty much convinced that Python's behavior makes sense,
    but it makes sense only because I'm going into this expecting operators
    to be defined by types, so I don't expect every '*' to mean 'multiplication'.

    Helps, perhaps, that I got exposed to group theory early enough to be used
    to redefining + and * to be any two operations which have interesting
    properties*.

    -s
    [*] What's purple and commutes? An abelian grape.
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Sep 26, 2010
    #8
  9. Thomas Jollans

    Paul Rubin Guest

    Seebs <> writes:
    > * It seems clear that, given two sequences x and y, "x + y" ought to
    > be the concatenation of these sequences.
    >...
    > Helps, perhaps, that I got exposed to group theory early enough to be used
    > to redefining + and * to be any two operations which have interesting
    > properties*.


    But groups have only one of those operators, and when it's written as +
    that usually means the group is commutative. So you wouldn't want + to
    denote sequence concatenation. If + and * are both present, that sounds
    like a ring, in which case you'd want "foo"*"bar" to work. It actually
    seems to me that exponentiation makes more sense than multiplication
    for turning "a" into "aaa". We think of aaa as what results from
    writing "a" with "3" in the superscript position.
     
    Paul Rubin, Sep 26, 2010
    #9
  10. On 2010-09-26, Paul Rubin <> wrote:
    > Steven D'Aprano <> writes:
    >> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",


    > Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?


    Because

    3 * "spam" == "spam" + "spam" + "spam"

    Just like

    3 * 6 = 6 + 6 + 6

    So now I suppose "+" for string concatenation is a bad thing.

    --
    Grant
     
    Grant Edwards, Sep 26, 2010
    #10
  11. Thomas Jollans

    Mel Guest

    Grant Edwards wrote:

    > On 2010-09-26, Paul Rubin <> wrote:
    >> Steven D'Aprano <> writes:
    >>> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",

    >
    >> Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?

    >
    > Because
    >
    > 3 * "spam" == "spam" + "spam" + "spam"
    >
    > Just like
    >
    > 3 * 6 = 6 + 6 + 6
    >
    > So now I suppose "+" for string concatenation is a bad thing.


    It's awkward for math purists because there's no additive inverse .. hence
    the original poster's idea to simply create one out of the blue. For string
    lengths and list lengths we're stuck with non-negative integers, and no hope
    of general-purpose subtraction.

    I wouldn't change it. As an idiom, ' '*20 is just too handy a way to get a
    20-blank string to give up.

    Mel.
     
    Mel, Sep 26, 2010
    #11
  12. Thomas Jollans

    John Nagle Guest

    On 9/26/2010 1:16 AM, Paul Rubin wrote:
    > Steven D'Aprano<> writes:
    >> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",

    > Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?
    > Should "spam"*2.5 be "spamspamsp"?
    > Should "spam"-"a" be "spm"? What about "spamspam"-"a"?
    > And what about "spam"/2? "sp" be an ok first guess, but "sa" might
    > make more sense (it means (1,2,3,...)/2 would be (1,3,5...)).
    >
    > I say it's all hokey from the get-go ;-).


    I tend to agree. "+" as concatenation is at least associative.
    Trying to concatenate a string with an integer raises an exception,
    so that's not going to generate unexpected values.

    "*" as repetition, on the other hand, is a mixed-mode operation.
    That's why this is troublesome. Where the type spaces are isolated,
    overloading isn't so risky.

    We should have something like "repeat" or "dup" as
    a string method rather than an overloading of the "*" operator.
    Strings already have a range of methods which perform basic
    operations on the string and return a new string, so
    that's consistent.

    "xyz".dup(3)

    is clear enough.

    And allowing

    "xyz"*-3

    was just lame. What reasonable use case does that have?

    John Nagle
     
    John Nagle, Sep 26, 2010
    #12
  13. Paul Rubin <> writes:

    > Seebs <> writes:
    >> * It seems clear that, given two sequences x and y, "x + y" ought to
    >> be the concatenation of these sequences.
    >>...
    >> Helps, perhaps, that I got exposed to group theory early enough to be used
    >> to redefining + and * to be any two operations which have interesting
    >> properties*.

    >
    > But groups have only one of those operators, and when it's written as +
    > that usually means the group is commutative. So you wouldn't want + to
    > denote sequence concatenation. If + and * are both present, that sounds
    > like a ring, in which case you'd want "foo"*"bar" to work. It actually
    > seems to me that exponentiation makes more sense than multiplication
    > for turning "a" into "aaa". We think of aaa as what results from
    > writing "a" with "3" in the superscript position


    This is common notation in Computer Science. Word concatenation is
    often denoted multiplicatively (with the sign generally omitted) and so
    it follows naturally that exponentiation is used for repeated
    concatenation of a word with itself.

    This is also in keeping with group (or rather in in this case, monoid)
    theory notation where commutative group / monoid composition laws are
    denoted additively and non-commutative ones multiplicatively.

    So it would probably have been more in keeping with established
    mathematical / theoretical CS notation to write:

    "spam" * "eggs" instead of "spam" + "eggs"

    and

    "spam"**3 instead of "spam"*3

    However it wouldn't prevent people from thinking about giving a meaning
    to e.g.

    "spam"**-2

    --
    Arnaud
     
    Arnaud Delobelle, Sep 26, 2010
    #13
  14. On Sun, 26 Sep 2010 01:16:49 -0700, Paul Rubin wrote:

    > Steven D'Aprano <> writes:
    >> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",


    > Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?


    The first one would be a reasonable design choice, although less useful
    than what Python does. Instead of:

    rule = "="*12

    you would need to write:

    rule = ''.join("="*12)

    which is a pain.

    The second one is just a lousy design. If you ask for three sheep, you
    expect three sheep, not three sheep heads, plus three sheep tails, plus
    three sheep left-front legs, plus...

    "ssspppaaammm" fails the Principle of Least Surprise. For any positive n,
    you would expect:

    "spam" in ("spam"*n)

    to return True. "ssspppaaammm" fails this test.



    > Should "spam"*2.5 be "spamspamsp"?


    Trying to determine a fraction of a string is troublesome... what is
    1/100th of "abcde"? Some fraction of the letter "a"? What does that even
    mean? The question has no sensible answer, in the same way that asking
    for the real-valued square-root of -1 has no sensible answer. Unlike real
    numbers, which are easily extended to complex values, there's no obvious
    extension of strings to include fractions of characters.

    So the only sensible thing is to say that fractions of strings doesn't
    have any meaning. When faced with "spam"*2.5, you can either raise an
    exception (as Python does), or truncate the second argument to an integer
    value. Which you do is a matter of taste, although I'd argue in favour of
    truncation.


    > Should "spam"-"a" be "spm"? What about "spamspam"-"a"? And what about
    > "spam"/2? "sp" be an ok first guess, but "sa" might make more sense (it
    > means (1,2,3,...)/2 would be (1,3,5...)).


    What makes you think that "spam" - "a" should be anything at all?

    Just because an operator exists doesn't mean it *has* to be defined for
    every possible data set. You're over-thinking this. Repetition of
    sequences is simple and straight-forward. Trying to come up with
    complicated analogues to arbitrary real-number operators is a waste of
    time and effort. That is exactly the sort of nonsense that I already
    agreed should be avoided.



    --
    Steven
     
    Steven D'Aprano, Sep 27, 2010
    #14
  15. On Sun, 26 Sep 2010 09:30:08 +0000, Seebs wrote:

    >> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",
    >> and the fact that it doesn't do the same thing as int("spam")*3 is a
    >> foolish argument.

    >
    > The languages in which it's surprising are mostly things like perl,
    > where there's a certain amount of implicit coercion going on, so it's
    > ambiguous whether "3"*3 ought to mean "333" or 9. (Except it isn't,
    > because repetition is a separate operator, written "3" x 3 rather than
    > "3" * 3...) People coming from that kind of background may be expecting
    > * to stay an arithmetic operator, rather than having it change form when
    > applied to non-arithmetic objects.


    And people with no programming background at all will be surprised that *
    and x aren't two different symbols for the same operation.



    > I'm not sure either way. I think on the whole, I like the notion of a
    > repetition operator which is distinct from multiplication, but I also
    > definitely prefer the lack of implicit coercion, and without implicit
    > coercion, there's a lot less underlying ambiguity to worry about.
    >
    > From the top, I guess my analysis is:
    >
    > * It seems clear that, given two sequences x and y, "x + y" ought to
    > be the concatenation of these sequences.
    > * Thus, "x + x" should be x concatenated to itself. * Idiomatically, it
    > is not unreasonable to assert that "x * 2" and "x + x"
    > could be the same value.
    > * It thus makes some sense for <sequence> * <number> to indicate
    > repetition of the sequence.
    > * Since a string is a kind of a sequence, it also makes sense for
    > <string> * <number> to indicate repetition.


    My analysis as well, except that I see repetition (repeated concatenation/
    addition) as more fundamental than multiplication. Think about being back
    in primary school, where you learn to do this:


    21
    21
    +21
    ----
    63


    before you learned this:

    21
    x3
    ----
    63




    > So I think I'm pretty much convinced that Python's behavior makes sense,
    > but it makes sense only because I'm going into this expecting operators
    > to be defined by types, so I don't expect every '*' to mean
    > 'multiplication'.


    Perhaps you should say "real-valued multiplication" rather than just
    multiplication, because of course matrix multiplication A*B behaves quite
    differently from integer multiplication a*b as well.



    > Helps, perhaps, that I got exposed to group theory early enough to be
    > used to redefining + and * to be any two operations which have
    > interesting properties*.
    >
    > -s
    > [*] What's purple and commutes? An abelian grape.



    Heh :)



    --
    Steven
     
    Steven D'Aprano, Sep 27, 2010
    #15
  16. In message <>, Seebs wrote:

    > Helps, perhaps, that I got exposed to group theory early enough to be used
    > to redefining + and * to be any two operations which have interesting
    > properties ...


    But groups only have one such operation; it’s rings and fields (and number
    systems) that have two.
     
    Lawrence D'Oliveiro, Sep 29, 2010
    #16
  17. Thomas Jollans

    Seebs Guest

    On 2010-09-29, Lawrence D'Oliveiro <_zealand> wrote:
    > In message <>, Seebs wrote:
    >> Helps, perhaps, that I got exposed to group theory early enough to be used
    >> to redefining + and * to be any two operations which have interesting
    >> properties ...


    > But groups only have one such operation; it???s rings and fields (and number
    > systems) that have two.


    They're covered in the same class, therefore, they're part of the same
    field (of study, that is). :p

    -s
    --
    Copyright 2010, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
     
    Seebs, Sep 29, 2010
    #17
  18. On Sun, Sep 26, 2010 at 03:20:18PM +0000, Grant Edwards wrote:
    > On 2010-09-26, Paul Rubin <> wrote:
    > > Steven D'Aprano <> writes:
    > >> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",

    >
    > > Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?

    >
    > Because
    >
    > 3 * "spam" == "spam" + "spam" + "spam"
    >
    > Just like
    >
    > 3 * 6 = 6 + 6 + 6
    >
    > So now I suppose "+" for string concatenation is a bad thing.


    Well I find it an unfortunate choice. The problem is, that it is not that
    unusual to want some class to have the possibility of both addition and
    concatenation. But since we only one symbol for both operations, you will
    have to loose some consistency over this.

    --
    Antoon Pardon
     
    Antoon Pardon, Sep 30, 2010
    #18
  19. On 9/30/2010 5:10 AM Antoon Pardon said...
    > On Sun, Sep 26, 2010 at 03:20:18PM +0000, Grant Edwards wrote:
    >> On 2010-09-26, Paul Rubin<> wrote:
    >>> Steven D'Aprano<> writes:
    >>>> There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",

    >>
    >>> Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?

    >>
    >> Because
    >>
    >> 3 * "spam" == "spam" + "spam" + "spam"
    >>
    >> Just like
    >>
    >> 3 * 6 = 6 + 6 + 6
    >>
    >> So now I suppose "+" for string concatenation is a bad thing.

    >
    > Well I find it an unfortunate choice. The problem is, that it is not that
    > unusual to want some class to have the possibility of both addition and
    > concatenation. But since we only one symbol for both operations, you will
    > have to loose some consistency over this.
    >


    Which is actually a good thing for a class that wants to have both
    concatenation and addition -- which would it do with only one symbol?

    Emile
     
    Emile van Sebille, Sep 30, 2010
    #19
  20. On Thu, Sep 30, 2010 at 07:02:40AM -0700, Emile van Sebille wrote:
    > On 9/30/2010 5:10 AM Antoon Pardon said...
    > >On Sun, Sep 26, 2010 at 03:20:18PM +0000, Grant Edwards wrote:
    > >>On 2010-09-26, Paul Rubin<> wrote:
    > >>>Steven D'Aprano<> writes:
    > >>>>There's nothing obscure or unintuitive about "spam"*3 = "spamspamspam",
    > >>
    > >>>Why would it not be ["spam","spam","spam"] or even "ssspppaaammm"?
    > >>
    > >>Because
    > >>
    > >>3 * "spam" == "spam" + "spam" + "spam"
    > >>
    > >>Just like
    > >>
    > >>3 * 6 = 6 + 6 + 6
    > >>
    > >>So now I suppose "+" for string concatenation is a bad thing.

    > >
    > >Well I find it an unfortunate choice. The problem is, that it is not that
    > >unusual to want some class to have the possibility of both addition and
    > >concatenation. But since we only one symbol for both operations, you will
    > >have to loose some consistency over this.
    > >

    >
    > Which is actually a good thing for a class that wants to have both
    > concatenation and addition


    Why? What is good about losing consistency? It is in this case necessary
    but that doesn't make it good.

    Think about the following possibility.

    Someone provides you with a library of functions that act on sequences.
    They rely on the fact that '+' concatenates.

    Someone else provides you with a library of functions that act on
    numbers. They rely on the fact that '+' provides addition.

    Now however you write your sequence like numbers or number like sequences
    one of those libraries will be useless for it.

    > -- which would it do with only one
    > symbol?


    But why limit ourselves to one symbol for different kind of operations,
    to begin with?

    --
    Antoon Pardon
     
    Antoon Pardon, Oct 1, 2010
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Replies:
    10
    Views:
    552
    ma740988
    Dec 17, 2005
  2. klior

    2 Multiplied clock sync.

    klior, Jul 31, 2007, in forum: VHDL
    Replies:
    0
    Views:
    513
    klior
    Jul 31, 2007
  3. Yingjie Lan

    sequence multiplied by -1

    Yingjie Lan, Sep 25, 2010, in forum: Python
    Replies:
    2
    Views:
    269
    BartC
    Sep 26, 2010
  4. Yingjie Lan

    Re: sequence multiplied by -1

    Yingjie Lan, Sep 25, 2010, in forum: Python
    Replies:
    3
    Views:
    250
    Bruno Desthuilliers
    Oct 3, 2010
  5. Yingjie Lan

    Re: sequence multiplied by -1

    Yingjie Lan, Sep 25, 2010, in forum: Python
    Replies:
    3
    Views:
    246
    Steven D'Aprano
    Sep 26, 2010
Loading...

Share This Page