Pythonification of the asterisk-based collection packing/unpacking syntax

[Chris Angelico]

On Sun, Dec 18, 2011 at 3:43 PM, Evan Driscoll <edriscoll at wisc.edu> wrote:
> On 12/17/2011 21:42, Chris Angelico wrote:
>> Welcome to the list! If you're curious as to what's happened, check
>> the archives:
>> http://mail.python.org/pipermail/python-list/
> Thanks! Incidentally, is there a good way to respond to the original
> post in this thread, considering it wasn't delivered to me?

I don't know of a way, but this works. It's all part of the same thread.

> I mean, suppose '1' were an object and implemented
> __lt__. Does it suddenly become not weak typing because of that?

Is it weak typing to overload a function?

//C++ likes this a lot.
int foo(int x,int y) {return x*3+y;}
double foo(double x,double y) {return x*3+y;}

This is definitely making the term "strongly typed language" fairly useless.

> (The other thing is that I think strong vs weak is more subjective than
> many of the other measures. Is '1 < True' or '"1"+1' weaker? I think it
> has a lot to do with how the operations provided by the language play to
> your expectations.)

+1. My expectations are:
1) The Boolean value "True" might be the same as a nonzero integer, or
might not; it would make sense to use inequality comparisons with
zero, MAYBE, but not with 1. So I don't particularly care what the
language does with "1 < True", because it's not something that I would
normally do.
2) "1"+1, in any high level language with an actual string type, I
would expect to produce "11". It makes the most sense this way; having
it return 2 means there's a special case where the string happens to
look like a number - meaning that " 1"+1 is different from "1"+1. That
just feels wrong to me... but I'm fully aware that many other people
will disagree.

Yep, it's pretty subjective.

> On 12/17/2011 22:05, Chris Angelico wrote:
>> Not quite; 1 + "one" will be "ne", which might happen to be at memory
>> location 2. The data type is going to be char* (or, in a modern
>> compiler, const char*), not int.
> I'm not quite sure I'd say that it could be 2, exactly, but I definitely
> disagree with this... after running 'int x = 5, *p = &x' would you say
> that "p is 5"? (Assume &x != 5.) 1+"one" *points to* "ne", but it's
> still a pointer.

Point. I stand corrected. I tend to think of a char* as "being" the
string, even though technically it only points to the beginning of it;
it's the nearest thing C has to a string type. (To be honest, it's
still a lot better than many high level languages' string types for
certain common operations - eg trimming leading whitespace is pretty
efficient on a PSZ.) In your example, p would be some integer value
that is the pointer, but *p is 5. However, there's really no syntax in
C to say what the "string value" is.

ChrisA