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
--
http://mail.python.org/mailman/listinfo/python-list
