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.
--
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 form is supposed to update in
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.
a = [1]
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
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 concatenation was just shorthand
for
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
print a,
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 thing to x
On 15 Feb 2007 16:04:14 -0800, Paul McGuire [EMAIL PROTECTED] wrote:
On Feb 15, 5:21 pm, Paul Rubin http://[EMAIL PROTECTED] 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.
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
Quoth Paul Rubin http://[EMAIL PROTECTED]:
| 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
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
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] 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 handling, no.
We
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 them
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] 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 thinking of
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 are
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 languages and
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
Then
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]
(1,) + [1] = [1,
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 guess we
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
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 a list. In
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
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 different. list.extend()
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 that
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, perhaps
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(/etc/hosts)
[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
In article [EMAIL PROTECTED],
Paul Rubin http://[EMAIL PROTECTED] 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 parameters
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. This is
On Feb 15, 5:21 pm, Paul Rubin http://[EMAIL PROTECTED] 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,
and
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, for
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 stdin, line 1, in module
TypeError: can only concatenate tuple (not list) to tuple
[1]+(1,)
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 stdin, line 1, in module
TypeError: can only concatenate tuple (not
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 stdin, line 1, in module
TypeError: can only concatenate tuple (not
Its ugly and boring.
It's rude, unnecessary _and_ boring
--
http://mail.python.org/mailman/listinfo/python-list
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]
It seems like the
James Stroud [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
[1]+(1,)
Traceback (most recent call last):
File stdin, line 1, in module
TypeError: can only concatenate list (not tuple) to list
Its ugly and boring.
Agreed. This would be similar to:
py 1 + 1.0
Traceback:
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
[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 them
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 makes no
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
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
different
[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.
James Then
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 and tuples are
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?
Is that
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 obvious.
[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.
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
48 matches
Mail list logo
