Re: f---ing typechecking

Hendrik van Rooyen wrote: > I don't think its reasonable - its just an accident of implementation. There's nothing accidental about the implementation of the in-place operators. It was designed the way it is so that it would work in a reasonable way with both mutable and immutable objects. -- Gr

RE: f---ing typechecking

Nick Craig-Wood wrote: > Which appears to support my point, x (and a for that matter) are the > same for both methods wheter you do x = x + a or x += a. > > The mechanism is different certainly, but the result should be the > same otherwise you are breaking the basic rules of arithmetic the > prog

Re: f---ing typechecking

Delaney, Timothy (Tim) <[EMAIL PROTECTED]> wrote: > Nick Craig-Wood wrote: > > > x += a > > > > does not equal > > > > x = x + a > > > > which it really should for all types of x and a > > Actually, this will *never* be the case for classes that do in-place > augmented assignment. >

Re: f---ing typechecking

On 2007-02-21, Hendrik van Rooyen <[EMAIL PROTECTED]> wrote: > "Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: >> Ie >> >> x += a >> >> does not equal >> >> x = x + a >> >> which it really should for all types of x and a > > One would hope so , yes. > > However, I think that the first for

Re: f---ing typechecking

"Nick Craig-Wood" <[EMAIL PROTECTED]> wrote: > > Ie > > x += a > > does not equal > > x = x + a > > which it really should for all types of x and a One would hope so , yes. However, I think that the first form is supposed to update in place, while the second is free to bind a new

RE: f---ing typechecking

Nick Craig-Wood wrote: > x += a > > does not equal > > x = x + a > > which it really should for all types of x and a Actually, this will *never* be the case for classes that do in-place augmented assignment. a = [1] b = [2] c = a + b print a, b, c a += b prin

Re: f---ing typechecking

Neil Cerutti <[EMAIL PROTECTED]> wrote: > On 2007-02-14, Farshid Lashkari <[EMAIL PROTECTED]> wrote: > > Szabolcs Nagy wrote: > > L=[1] > > L.extend((1,)) > > L > >> [1, 1] > > > > Are list.extend() and list concatenation supposed to behave > > differently? I always thought concatenati

Re: f---ing typechecking

Quoth Paul Rubin : | Donn Cave <[EMAIL PROTECTED]> writes: | > What this proves is that you can implement | > an argument list at run time, but it by no means changes the | > nature of the argument list as a sequence. | | Right, it's treated as a sequence rather than a rec

Re: f---ing typechecking

"Paul McGuire" <[EMAIL PROTECTED]> writes: > This may be where the "tuple is like a struct" analogy isn't so good, > and "tuple is like a list but immutable" is better. Right, that's what I'm getting at. -- http://mail.python.org/mailman/listinfo/python-list

Re: f---ing typechecking

On 15 Feb 2007 16:04:14 -0800, Paul McGuire <[EMAIL PROTECTED]> wrote: > On Feb 15, 5:21 pm, Paul Rubin wrote: > > How can there be a structure datatype with an unpredictable > > number of members? > > > > It might have come across as a different question-sorry for any >

Re: f---ing typechecking

Donn Cave <[EMAIL PROTECTED]> writes: > What this proves is that you can implement > an argument list at run time, but it by no means changes the > nature of the argument list as a sequence. Right, it's treated as a sequence rather than a record structure. So is that consistent with the "tuples ar

Re: f---ing typechecking

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > Donn Cave <[EMAIL PROTECTED]> writes: > > Unpredictable? How do you manage to write functions in this case? > > Are all your formal parameter lists like (*a), with logic to deal > > with the variable lengths? > > I'm

Re: f---ing typechecking

Donn Cave <[EMAIL PROTECTED]> writes: > Unpredictable? How do you manage to write functions in this case? > Are all your formal parameter lists like (*a), with logic to deal > with the variable lengths? I'm thinking of functions like printf, which take a variable number of args and don't assign t

Re: f---ing typechecking

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > Donn Cave <[EMAIL PROTECTED]> writes: > > If t is a valid argument tuple for function f, then can t[1:] > > also be a valid argument tuple for function f? > > > > For ordinary functions without special argument handli

Re: f---ing typechecking

Agreed. This would be similar to: py> 1 + 1.0 Traceback: can only add int to int. Etc. But then again, the unimaginative defense would be that it wouldn't be python if you could catentate a list and a tuple. Of course, that behaviour would be quite defensible; auto-casting int to float is _w

Re: f---ing typechecking

"Paul McGuire" <[EMAIL PROTECTED]> writes: > Now what is it you want to do with args that you can't do with it as a > tuple? I'm ok with it being a tuple, but I'm not so wed to the notion that tuples are record structures. I think it would be lame to not be able to iterat through the arg list,

Re: f---ing typechecking

On Feb 15, 5:21 pm, Paul Rubin wrote: > How can there be a structure datatype with an unpredictable > number of members? > > It might have come across as a different question-sorry for any > confusion. This may be where the "tuple is like a struct" analogy isn't so good,

Re: f---ing typechecking

Donn Cave <[EMAIL PROTECTED]> writes: > If t is a valid argument tuple for function f, then can t[1:] > also be a valid argument tuple for function f? > > For ordinary functions without special argument handling, no. > We know that without having to know anything about t, and not > much about f.

Re: f---ing typechecking

In article <[EMAIL PROTECTED]>, Paul Rubin wrote: > [EMAIL PROTECTED] writes: > > My original comment was that tuples could be thought of more like > > C structs or Pascal records. > > Should f(*args) receive a list rather than a tuple arg? No, clearly not. Function

Re: f---ing typechecking

[EMAIL PROTECTED] writes: > My original comment was that tuples could be thought of more like > C structs or Pascal records. Should f(*args) receive a list rather than a tuple arg? -- http://mail.python.org/mailman/listinfo/python-list

Re: f---ing typechecking

Sergey> posix.stat_result is CLASS, not regular tuple. >> I believe it morphed from being a tuple though. I wasn't suggesting >> that Sergey> It it morphed, the tuple nature of it is just history now. No, it is still full of tuple-fu: >>> import os >>> s = os.stat("/et

Re: f---ing typechecking

James Stroud <[EMAIL PROTECTED]> writes: > I increasingly come to the decision to avoid tuples altogether > because, eventually, you end up turning them into lists anyway I don't. I end up extracting them to separate variables. >>> foo = (12, None, "spam") >>> # ... >>> # much code,

Re: f---ing typechecking

On 2007-02-15, Paul McGuire <[EMAIL PROTECTED]> wrote: > Since tuples are immutable, I think of them as fixed data objects with > some simple sequential structure, as opposed to lists which are much > more dynamically accessible/updateable data containers. Me, too. There are plenty of things tha

Re: f---ing typechecking

On 2007-02-14, Farshid Lashkari <[EMAIL PROTECTED]> wrote: > Szabolcs Nagy wrote: > L=[1] > L.extend((1,)) > L >> [1, 1] > > Are list.extend() and list concatenation supposed to behave > differently? I always thought concatenation was just shorthand > for calling extend(). They are dif

Re: f---ing typechecking

Sergey> posix.stat_result is CLASS, not regular tuple. I believe it morphed from being a tuple though. I wasn't suggesting that there is some other way to approximate records. I was trying to demonstrate the use of a tuple as a record. It eventually became so compelling that a new struct_t

Re: f---ing typechecking

On 15 feb, 07:21, James Stroud <[EMAIL PROTECTED]> wrote: > I guess we differ on what is obvious. This seems obvious to me: > > [1] + (1,) => [1, 1] > (1,) + [1] => (1, 1) > > simply becuase the operand on the left should take precendence because > its "__add__" is called and its "__add__" returns

Re: f---ing typechecking

Paul McGuire wrote: > Since tuples are immutable, I think of them as fixed data objects with > some simple sequential structure, as opposed to lists which are much > more dynamically accessible/updateable data containers. Back in my > relational database design days, I sometimes had to create a pr

Re: f---ing typechecking

Steven D'Aprano wrote: > On Wed, 14 Feb 2007 22:21:43 -0800, James Stroud wrote: > >>> The user's expected behaviour for [1] + (1,) might be to return a list, or >>> it might be to return a tuple. Since there is no obviously correct >>> behaviour, the right thing to do is to refuse to guess. >> I

Re: f---ing typechecking

BJörn Lindqvist wrote: > On 2/15/07, James Stroud <[EMAIL PROTECTED]> wrote: >> I guess we differ on what is obvious. This seems obvious to me: >> >> [1] + (1,) => [1, 1] >> (1,) + [1] => (1, 1) > > I agreed with you up to this point. But this seems more obvious to me: > > [1] + (1,) => [1, 1] >

Re: f---ing typechecking

James Stroud wrote: > [EMAIL PROTECTED] wrote: >> Concatenating tuples and lists seems logical if you think of tuples as >> sequences. If you think of them more like Pascal records or C structs >> instead (I believe that's Guido's perspective on tuples) then it makes no >> sense at all. >> >> Skip

Re: f---ing typechecking

On 2/15/07, James Stroud <[EMAIL PROTECTED]> wrote: > I guess we differ on what is obvious. This seems obvious to me: > > [1] + (1,) => [1, 1] > (1,) + [1] => (1, 1) I agreed with you up to this point. But this seems more obvious to me: [1] + (1,) => [1, 1] (1,) + [1] => [1, 1] In other language

Re: f---ing typechecking

Since tuples are immutable, I think of them as fixed data objects with some simple sequential structure, as opposed to lists which are much more dynamically accessible/updateable data containers. Back in my relational database design days, I sometimes had to create a primary key for a table by com

Re: f---ing typechecking

<[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > It's effectively a tuple with field names. I don't know when the switch > occurred (it's in 2.2, as far back as my built interpreter versions > currently go), but back in the day os.stat used to return a plain old > tuple. posix.sta

Re: f---ing typechecking

On Wed, 14 Feb 2007 22:21:43 -0800, James Stroud wrote: >> The user's expected behaviour for [1] + (1,) might be to return a list, or >> it might be to return a tuple. Since there is no obviously correct >> behaviour, the right thing to do is to refuse to guess. > > I guess we differ on what is o

Re: f---ing typechecking

Steven D'Aprano wrote: > On Wed, 14 Feb 2007 19:45:14 -0800, James Stroud wrote: >>Steven D'Aprano wrote: >>>Since lists and tuples are completely different objects with completely >>>different usages, what should concatenating a list and a tuple give? >>>Should it depend on the order you pass them

Re: f---ing typechecking

On Wed, 14 Feb 2007 19:45:14 -0800, James Stroud wrote: > Steven D'Aprano wrote: >> On Wed, 14 Feb 2007 13:25:21 -0800, James Stroud wrote: >> >> >>>But then again, the unimaginative defense would be that it wouldn't be >>>python if you could catentate a list and a tuple. >> >> >> Since lists

Re: f---ing typechecking

[EMAIL PROTECTED] wrote: > >> Concatenating tuples and lists seems logical if you think of tuples > >> as sequences. If you think of them more like Pascal records or C > >> structs instead (I believe that's Guido's perspective on tuples) then > >> it makes no sense at all. > >

Re: f---ing typechecking

Steven D'Aprano wrote: > On Wed, 14 Feb 2007 13:25:21 -0800, James Stroud wrote: > > >>But then again, the unimaginative defense would be that it wouldn't be >>python if you could catentate a list and a tuple. > > > Since lists and tuples are completely different objects with completely > diff

Re: f---ing typechecking

On Wed, 14 Feb 2007 13:25:21 -0800, James Stroud wrote: > But then again, the unimaginative defense would be that it wouldn't be > python if you could catentate a list and a tuple. Since lists and tuples are completely different objects with completely different usages, what should concatenating

Re: f---ing typechecking

>> Concatenating tuples and lists seems logical if you think of tuples >> as sequences. If you think of them more like Pascal records or C >> structs instead (I believe that's Guido's perspective on tuples) then >> it makes no sense at all. James> Then iterating over them mak

Re: f---ing typechecking

[EMAIL PROTECTED] wrote: > Concatenating tuples and lists seems logical if you think of tuples as > sequences. If you think of them more like Pascal records or C structs > instead (I believe that's Guido's perspective on tuples) then it makes no > sense at all. > > Skip > Then iterating over th

Re: f---ing typechecking

Concatenating tuples and lists seems logical if you think of tuples as sequences. If you think of them more like Pascal records or C structs instead (I believe that's Guido's perspective on tuples) then it makes no sense at all. Skip -- http://mail.python.org/mailman/listinfo/python-list

Re: f---ing typechecking

"James Stroud" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] >[1]+(1,) >> >> Traceback (most recent call last): >> File "", line 1, in >> TypeError: can only concatenate list (not "tuple") to list >> >> >> Its ugly and boring. > > Agreed. This would be similar to: > > py> 1

Re: f---ing typechecking

Szabolcs Nagy wrote: L=[1] L.extend((1,)) L > [1, 1] Are list.extend() and list concatenation supposed to behave differently? I always thought concatenation was just shorthand for calling extend(). However the following seems to work: >>> L = [1] >>> L += (2,) >>> L [1, 2

Re: f---ing typechecking

> Its ugly and boring. It's rude, unnecessary _and_ boring -- http://mail.python.org/mailman/listinfo/python-list

Re: f---ing typechecking

Sergey Dorofeev wrote: > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > (1,)+[1] > > Traceback (most recent call last): > File "", line 1, in > TypeError: can only concatenate

Re: f---ing typechecking

Sergey Dorofeev wrote: > Python 2.5 (r25:51908, Sep 19 2006, 09:52:17) [MSC v.1310 32 bit (Intel)] on > win32 > Type "help", "copyright", "credits" or "license" for more information. > >>> (1,)+[1] > Traceback (most recent call last): > File "", line 1, in > TypeError: can only concatenate tupl