By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
439,986 Members | 1,551 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 439,986 IT Pros & Developers. It's quick & easy.

Why tuple with one item is no tuple

P: n/a
Hi,
type(['1']) <type 'list'>
type(('1'))

<type 'str'>

I wonder why ('1') is no tuple????

Because I have to treat this "special" case differently in my code.

--
Greg
Jul 18 '05 #1
Share this Question
Share on Google+
37 Replies


P: n/a
('1',) is a tuple... you need the comma to make it a tuple.

regards,

Fuzzy
http://www.voidspace.org.uk/python/index.shtml

Jul 18 '05 #2

P: n/a
On Tue, 15 Mar 2005 16:16:34 GMT, Gregor Horvath <g.*******@mx.at> wrote:
Hi,
>>>type(['1']) <type 'list'>
>>>type(('1')) <type 'str'>

I wonder why ('1') is no tuple????
because, syntactically, those parens are for grouping, and do not
unambiguously define a tuple. It's a python gotcha. To define a
one-tuple, put a comma after the '1':
type(('1',))

<type 'tuple'>

Because I have to treat this "special" case differently in my code.


you shouldn't have to; post your code if you still think you do.

Peace
Bill Mill
bill.mill at gmail.com
Jul 18 '05 #3

P: n/a
Gregor Horvath wrote:
Hi,
>>>type(['1']) <type 'list'>
>>>type(('1')) <type 'str'>

I wonder why ('1') is no tuple????

Because I have to treat this "special" case differently in my code.


you need to tell python that ('1') isn't a string inside
a couple parens but a tuple, look:
t = ('1', )
type(t) <type 'tuple'>

if there's no ambiguity you can omit the parens:
t = '1',
type(t)

<type 'tuple'>

HTH,
deelan

--
@prefix foaf: <http://xmlns.com/foaf/0.1/> .
<#me> a foaf:Person ; foaf:nick "deelan" ;
foaf:weblog <http://blog.deelan.com/> .
Jul 18 '05 #4

P: n/a
Gregor Horvath <g.*******@mx.at> wrote:
Hi,
type(['1'])<type 'list'>
type(('1'))

<type 'str'>

I wonder why ('1') is no tuple????


You need to say ('1',). In just plain ('1'), the parens are
interpreted as grouping, not as tuple creation. Depending on your
point of view, this is either a "special case", or an "ugly wart" in
the syntax.

a = () # tuple of zero elements
a = (1,) # tuple of one element
a = 1, # tuple of one element
a = (1) # scalar
a = (1, 2) # tuple of two elements
a = 1, 2 # tuple of two elements
a = , # syntax error

The big question is, is it the parens that make it a tuple, or is it
the comma? If you go along with the parens school of thought, then
(1,) is the special case. If you believe in commas, then the () is
the special case. In either case, it's a bit ugly, but we learn to
overlook the occasional cosmetic blemishes of those we love :-)
Jul 18 '05 #5

P: n/a

thanks are given to all....

"problem" solved...
--
Greg
Jul 18 '05 #6

P: n/a
Hmm,
going 'the other way', you are allowed an extra , but you can't have
(,) as the empty tuple.:
(1,2,) (1, 2) (1,) (1,) (,)

....
Traceback ( File "<interactive input>", line 1
(,)
^
SyntaxError: invalid syntax
-- Pad.

Jul 18 '05 #7

P: n/a
On Tuesday 15 March 2005 08:25 am, Roy Smith wrote:
a = () * * * # tuple of zero elements
a = (1,) * * # tuple of one element
a = 1, * * * # tuple of one element
a = (1) * * *# scalar
a = (1, 2) * # tuple of two elements
a = 1, 2 * * # tuple of two elements
a = , * * * *# syntax error

The big question is, is it the parens that make it a tuple, or is it
the comma? *If you go along with the parens school of thought, then
(1,) is the special case. *If you believe in commas, then the () is
the special case. *In either case, it's a bit ugly, but we learn to
overlook the occasional cosmetic blemishes of those we love :-)


The answer is obvious, the naked comma should be an empty tuple.
--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
Jul 18 '05 #8

P: n/a
On Tue, 15 Mar 2005 10:47:28 -0800, James Stroud <js*****@mbi.ucla.edu> wrote:
On Tuesday 15 March 2005 08:25 am, Roy Smith wrote:
a = () # tuple of zero elements
a = (1,) # tuple of one element
a = 1, # tuple of one element
a = (1) # scalar
a = (1, 2) # tuple of two elements
a = 1, 2 # tuple of two elements
a = , # syntax error

The big question is, is it the parens that make it a tuple, or is it
the comma? If you go along with the parens school of thought, then
(1,) is the special case. If you believe in commas, then the () is
the special case. In either case, it's a bit ugly, but we learn to
overlook the occasional cosmetic blemishes of those we love :-)


The answer is obvious, the naked comma should be an empty tuple.


The other answer, that parens should be required to surround all
tuples, is obvious too.

Neither is particularly appealing; a lone comma creating a data
structure seems counter-intuitive, but it's nice to do a, b = b, a
instead of (a, b) = (b, a) . In this case, since the need to create
empty tuples is vanishingly rare, I'm okay with a little
inconsistency.

Peace
Bill Mill
bill.mill at gmail.com
Jul 18 '05 #9

P: n/a
Bill Mill wrote:
On Tue, 15 Mar 2005 10:47:28 -0800, James Stroud <js*****@mbi.ucla.edu> wrote:
On Tuesday 15 March 2005 08:25 am, Roy Smith wrote:
> a = () # tuple of zero elements
> a = (1,) # tuple of one element
> a = 1, # tuple of one element
> a = (1) # scalar
> a = (1, 2) # tuple of two elements
> a = 1, 2 # tuple of two elements
> a = , # syntax error
>
> The big question is, is it the parens that make it a tuple, or is it
> the comma? If you go along with the parens school of thought, then
> (1,) is the special case. If you believe in commas, then the () is
> the special case. In either case, it's a bit ugly, but we learn to
> overlook the occasional cosmetic blemishes of those we love :-)


The answer is obvious, the naked comma should be an empty tuple.


The other answer, that parens should be required to surround all
tuples, is obvious too.

Neither is particularly appealing; a lone comma creating a data
structure seems counter-intuitive, but it's nice to do a, b = b, a
instead of (a, b) = (b, a) . In this case, since the need to create
empty tuples is vanishingly rare, I'm okay with a little
inconsistency.


And if you don't like it at all, you can still use tuple() to "create"
an empty tuple.

Reinhold
Jul 18 '05 #10

P: n/a
Gregor Horvath wrote:

thanks are given to all....

"problem" solved...

Personally I add a , after every list/tuple item. Also the last.

It also makes copy/pasting code easier.
--

hilsen/regards Max M, Denmark

http://www.mxm.dk/
IT's Mad Science
Jul 18 '05 #11

P: n/a
Gregor Horvath <g.*******@mx.at> wrote:
type(['1'])<type 'list'>
type(('1'))

<type 'str'>

I wonder why ('1') is no tuple????


There were lots of answers, but I'm not sure I saw the "why" addressed.

Consider this:

a = (3 + 5) * 5

You really, really want (3 + 5) to be an integer, not a one-item tuple.
--
- Tim Roberts, ti**@probo.com
Providenza & Boekelheide, Inc.
Jul 18 '05 #12

P: n/a
Op 2005-03-16, Tim Roberts schreef <ti**@probo.com>:
Gregor Horvath <g.*******@mx.at> wrote:
>>>type(['1'])

<type 'list'>
>>>type(('1'))

<type 'str'>

I wonder why ('1') is no tuple????


There were lots of answers, but I'm not sure I saw the "why" addressed.

Consider this:

a = (3 + 5) * 5

You really, really want (3 + 5) to be an integer, not a one-item tuple.


I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.

A bit like every char being a string.

--
Antoon Pardon
Jul 18 '05 #13

P: n/a
>> Consider this:
*****a*=*(3*+*5)***5
You really, really want (3 + 5) to be an integer, not a one-item tuple.


I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.

A bit like every char being a string.


There is no char. There are strings of lenght 1. And the above example makes
it clear that there would be an ambiguity that could _maybe_ be solved in a
static typed language (the application of the (3+5) as left side to the
operator <*> if <*> only is defined as [num, num] -> num), but clearly not
in a dynamic typed one as python.

And if the static typed language allows operator overloading, it could very
well be that someone creates a overloading for

<*> : [tuple[num], tuple[num]] -> <whatever>

which would reintroduce the ambiguity.

Soooooo, in the end it boils down to some explicitness - where IMHO an
additional comma is pretty much no problem at all. Another option would of
course be the introduction of different parentheses for tuples - but I
can't find some on my keyboard.

--
Regards,

Diez B. Roggisch
Jul 18 '05 #14

P: n/a
Op 2005-03-16, Diez B. Roggisch schreef <de*********@web.de>:
Consider this:
*****a*=*(3*+*5)***5
You really, really want (3 + 5) to be an integer, not a one-item tuple.
I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.

A bit like every char being a string.


There is no char. There are strings of lenght 1.


That is a matter of view. But to illustrate what I mean,
the following is an infinite loop in python

s = 'hi'
while true:
s = s[0]
And the above example makes
it clear that there would be an ambiguity that could _maybe_ be solved in a
static typed language (the application of the (3+5) as left side to the
operator <*> if <*> only is defined as [num, num] -> num), but clearly not
in a dynamic typed one as python.
That ambiguity is only caused because python uses the same characters
for very different operations and to be honest I don't like that.

for instance I have written once somekind of vector class where
it was natural for these vectors to be added as well as te be
concatenated. Unfortunately python uses "+" for both so I had
no way to have both operators in a natural way in python.

So that a <*> would create an ambiguity if items would be silently
transformed in a one-item tuple when appropiate is IMO more caused
by the design decision to use <*> for two totally diffent operations
then because of the dynamic nature of python.
And if the static typed language allows operator overloading, it could very
well be that someone creates a overloading for

<*> : [tuple[num], tuple[num]] -> <whatever>

which would reintroduce the ambiguity.

Soooooo, in the end it boils down to some explicitness - where IMHO an
additional comma is pretty much no problem at all. Another option would of
course be the introduction of different parentheses for tuples - but I
can't find some on my keyboard.


Well I can't find braille on my keyboard, but if I wanted to, it
wouldn't be difficult to get it on my screen. So is it with
different parentheses. That python can't use these parentheses
is again a design decision.

--
Antoon Pardon
Jul 18 '05 #15

P: n/a
> That ambiguity is only caused because python uses the same characters
for very different operations and to be honest I don't like that.
As I said: show me which parentheses to use - and keep in mind that:

- < and > are for comparisions and the same ambiguity troubles arise
- unicode surely features some usable characters (e.g. the quotation markes
that look like <<, but are one char). But for one that complains that
typing and additional comma is too much already, I doubt that having to
press some weird multi key stroke is a viable option. To me neither, as I
prefer my parentheses to be accessed easily, even on a vi running in a
console from a tn3270 terminal


for instance I have written once somekind of vector class where
it was natural for these vectors to be added as well as te be
concatenated. Unfortunately python uses "+" for both so I had
no way to have both operators in a natural way in python.
And no way in mathematics or any other language either - if you want the
same function symbol on the same operators to have _different_ semantics,
you're getting pretty non-deterministic.


So that a <*> would create an ambiguity if items would be silently
transformed in a one-item tuple when appropiate is IMO more caused
by the design decision to use <*> for two totally diffent operations
then because of the dynamic nature of python.


Your opinion is wrong. It's because you seem to not have understood the
example: The expression (5 + 4) could be understood as 9 or as (9,). In
python (and each and every other dynamically typed language) you can't
decide which version to take. So you have to decide on _one_, and as every
kid in school learns that (5+4) * 5 is 45, it was a reasonable decision to
use the semantics we have today.

In a statically typed language, (5+4) _could_ be the tuple if the expression
is used in a typing context that makes that determinable. An example would
be

list((5+4))

as the list constructor needs a iterable to work, so it would be declared
like this:

list _ : [ iterable[alpha] ] -> list[alpha]

But then you'd have to forbid overloading of operators, or someone could
declare a list like this:

list _ : [ num ] -> list[int]

to create lists of zeros of type int. Which would reintroduce the ambiguity
again.

And if the static typed language allows operator overloading, it could
very well be that someone creates a overloading for

<*> : [tuple[num], tuple[num]] -> <whatever>

which would reintroduce the ambiguity.

Soooooo, in the end it boils down to some explicitness - where IMHO an
additional comma is pretty much no problem at all. Another option would
of course be the introduction of different parentheses for tuples - but I
can't find some on my keyboard.


Well I can't find braille on my keyboard, but if I wanted to, it
wouldn't be difficult to get it on my screen. So is it with
different parentheses. That python can't use these parentheses
is again a design decision.


For someone who expresses his disliking to type _one_ comma in the few cases
of single element tuples in thousands of lines of code, it strikes me odd
that you'd go an are willing to add extra trouble entering _each_ and
_every_ tuple in your code by using some hitherto unknown character that
won't be enterable easily....

But you showed that strange sense of reasoning before - I remember you
wanting to shave off microseconds by optimising constant expressions like
5*4 whilst at the same time arguing in another thread that you'd like to
have mutable keys for dicts that needed copying the very same keys - at
much greater costs, per case and even more so in general as using dicts is
common where pure constant arithmetic expressions aren't.
--
Regards,

Diez B. Roggisch
Jul 18 '05 #16

P: n/a
Diez B. Roggisch wrote:
for instance I have written once somekind of vector class where
it was natural for these vectors to be added as well as te be
concatenated. Unfortunately python uses "+" for both so I had
no way to have both operators in a natural way in python.

And no way in mathematics or any other language either - if you want the
same function symbol on the same operators to have _different_ semantics,
you're getting pretty non-deterministic.

I think he meant that Python should have introduced different operators
for addition and sequence concatenation.
Your opinion is wrong. It's because you seem to not have understood the
example: The expression (5 + 4) could be understood as 9 or as (9,). In


It should be understood as 9, but if integers etc implement the sequence
protocol, 9 can be used just like a tuple
(http://www.livejournal.com/users/glyf/29038.html).

There have been other proposals where you could write 'for i in 5' etc.

I find this 'creative use of overloading' rather awful. But what the
heck, I find list comprehension rather awful.

Daniel
Jul 18 '05 #17

P: n/a
Daniel Dittmar wrote:
But what the heck, I find list comprehension rather awful.


Sacrilege! ;)

STeVe
Jul 18 '05 #18

P: n/a
> I think he meant that Python should have introduced different operators
for addition and sequence concatenation.
I reread his example and have to admit I'm confused: He complains about
having written his _own_ vector class - and concatenation and addition had
to use both + ?

He could have used | for concatenation instead. Apart from the concatenation
IMHO not being a mathematical founded operation on vectors.

I maybe was confused of him using + as bad example and then extending that
to *. But even more so my point is valid: If you forbid the overloading of
operators, you have to come up with even _more_ operator names, like ocaml
has *. and * for multiplication of floats and ints. So you end up with way
more clutter in the source, certainly more than the occasional extra comma.
Your opinion is wrong. It's because you seem to not have understood the
example: The expression (5 + 4) could be understood as 9 or as (9,). In


It should be understood as 9, but if integers etc implement the sequence
protocol, 9 can be used just like a tuple
(http://www.livejournal.com/users/glyf/29038.html).


The examples focus too much on numbers - if we use instead

("foo")

we would get a iterable yielding ["foo",] or - as string already supports
iteration - ['f', 'o', 'o']. Which one to chose?

There have been other proposals where you could write 'for i in 5' etc.

I find this 'creative use of overloading' rather awful. But what the
heck, I find list comprehension rather awful.


Well, the number of operators built into the language is limited - and I
actually prefer to have the possibility to overload these if I want to.
Nobody forces me - I could use

v1.concat(v2)

for two vectors v1, v2 if I wanted to.
--
Regards,

Diez B. Roggisch
Jul 18 '05 #19

P: n/a
Diez B. Roggisch wrote:
I reread his example and have to admit I'm confused: He complains about
having written his _own_ vector class - and concatenation and addition had
to use both + ?
I've interpreted it as:
If Python had choosen different operators for addition and sequence
concatenation, I could have implemented them both in my vector class. As
it is, I have to implement one of them using a non-standard operator.
The examples focus too much on numbers - if we use instead

("foo")

we would get a iterable yielding ["foo",] or - as string already supports
iteration - ['f', 'o', 'o']. Which one to chose?


What I was hinting at (NOT proposing, I'd hate this) was that integers
implement the [] operator. 5 [0] would then return 5, for all practical
purposes, it would look like a tuple. String already implements []. Yes,
that would lead to really surprising and inconsistent behaviour.
I find this 'creative use of overloading' rather awful. But what the
heck, I find list comprehension rather awful.

Well, the number of operators built into the language is limited - and I
actually prefer to have the possibility to overload these if I want to.
Nobody forces me - I could use

v1.concat(v2)

for two vectors v1, v2 if I wanted to.


My peeve is about having operators added to standard types. This
increases the chances that using an object the wrong way leads to a
bogus result, not a runtime error. A more common programming error I
commit is passing a string where a list ist expected. And then I wonder
why later operations work on one-character strings.

Operator overloading is certainly an irregular verb:
- I make the usage more intuitive
- Yours may lead to misinterpretation
- He obfuscates

Daniel
Jul 18 '05 #20

P: n/a
On Wednesday 16 March 2005 07:22 am, Diez B. Roggisch wrote:
As I said: show me which parentheses to use


I kind of like the comma as a tuple "parentheses"

,1,2,3,

replacing

(1,2,3)
or
1,2,3,
or
1,2,3
or (isn't this is getting out of hand?)
(1,2,3,)

Why not--except of course for backward compatability? Comma is not used for
anything else in python as far as I know. This would be very unambiguous.
Then, the purity would manifest itself the naked comma being an empty tuple.
Think about the zen of:

,
James
--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
Jul 18 '05 #21

P: n/a
James Stroud wrote:
On Wednesday 16 March 2005 07:22 am, Diez B. Roggisch wrote:
As I said: show me which parentheses to use

I kind of like the comma as a tuple "parentheses"

,1,2,3,

replacing

(1,2,3)
or
1,2,3,
or
1,2,3
or (isn't this is getting out of hand?)
(1,2,3,)

Why not--except of course for backward compatability? Comma is not used for
anything else in python as far as I know.


[1, 2, 3]
{'a': 0, 'b': 2}
f(x, y)
print foo,
This would be very unambiguous.
Not entirely.
Then, the purity would manifest itself the naked comma being an empty tuple.
Think about the zen of:

,


Is that a tuple or grit on my monitor? :-)

--
Robert Kern
rk***@ucsd.edu

"In the fields of hell where the grass grows high
Are the graves of dreams allowed to die."
-- Richard Harter
Jul 18 '05 #22

P: n/a
On Wednesday 16 March 2005 04:45 pm, Robert Kern wrote:
This would be very unambiguous.


Not entirely.
Then, the purity would manifest itself the naked comma being an empty
tuple. Think about the zen of:

* *,


Is that a tuple or grit on my monitor? *:-)


OK, OK, I'll give up on the commas. Maybe we should just use dollar signs :?

--
James Stroud, Ph.D.
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095
Jul 18 '05 #23

P: n/a
On Wed, 16 Mar 2005 17:28:51 -0800, James Stroud wrote:
On Wednesday 16 March 2005 04:45 pm, Robert Kern wrote:
> This would be very unambiguous.


Not entirely.
> Then, the purity would manifest itself the naked comma being an empty
> tuple. Think about the zen of:
>
> * *,


Is that a tuple or grit on my monitor? *:-)


OK, OK, I'll give up on the commas. Maybe we should just use dollar signs :?


No, using symbols like that is bad. Clearly we need a new parser constant,
THE_ZERO_LENGTH_EMPTY_TUPLE.

We will, of course, have to forbid assigning any other name to that
constant (more language changes) so that people don't start creating their
own inconsistent name... *especially* shorter ones.
Jul 18 '05 #24

P: n/a
Op 2005-03-16, Diez B. Roggisch schreef <de*********@web.de>:
That ambiguity is only caused because python uses the same characters
for very different operations and to be honest I don't like that.
As I said: show me which parentheses to use - and keep in mind that:

- < and > are for comparisions and the same ambiguity troubles arise
- unicode surely features some usable characters (e.g. the quotation markes
that look like <<, but are one char). But for one that complains that
typing and additional comma is too much already, I doubt that having to
press some weird multi key stroke is a viable option.


Complaints about typing an extra character are not all the same.
One can complain about the extra character that is needed on
the screen and one can complain about the extra finger work
that is needed to get a specific character on the screen.

Besides I don't remember complaining about typing an extra character.
To me neither, as I
prefer my parentheses to be accessed easily, even on a vi running in a
console from a tn3270 terminal

for instance I have written once somekind of vector class where
it was natural for these vectors to be added as well as te be
concatenated. Unfortunately python uses "+" for both so I had
no way to have both operators in a natural way in python.
And no way in mathematics or any other language either - if you want the
same function symbol on the same operators to have _different_ semantics,
you're getting pretty non-deterministic.


So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.
So that a <*> would create an ambiguity if items would be silently
transformed in a one-item tuple when appropiate is IMO more caused
by the design decision to use <*> for two totally diffent operations
then because of the dynamic nature of python.


Your opinion is wrong. It's because you seem to not have understood the
example: The expression (5 + 4) could be understood as 9 or as (9,). In
python (and each and every other dynamically typed language) you can't
decide which version to take. So you have to decide on _one_, and as every
kid in school learns that (5+4) * 5 is 45, it was a reasonable decision to
use the semantics we have today.


No my opinion is not wrong, you just don't understand what I'm saying.

No it was not reasonable to introduce the semantics that made 2 * (1,2)
equal (1,2,1,2) IMO they should have used a differend operator for that
and not the *.
Soooooo, in the end it boils down to some explicitness - where IMHO an
additional comma is pretty much no problem at all. Another option would
of course be the introduction of different parentheses for tuples - but I
can't find some on my keyboard.


Well I can't find braille on my keyboard, but if I wanted to, it
wouldn't be difficult to get it on my screen. So is it with
different parentheses. That python can't use these parentheses
is again a design decision.


For someone who expresses his disliking to type _one_ comma in the few cases
of single element tuples in thousands of lines of code, it strikes me odd
that you'd go an are willing to add extra trouble entering _each_ and
_every_ tuple in your code by using some hitherto unknown character that
won't be enterable easily....


Where did I express this dislike. I'm not denying it because I know I
forget such things, but I sure don't remember now.
But you showed that strange sense of reasoning before - I remember you
wanting to shave off microseconds by optimising constant expressions like
5*4,
AFAIR I was just exploring ideas.
whilst at the same time arguing in another thread that you'd like to
have mutable keys for dicts that needed copying the very same keys - at
much greater costs, per case and even more so in general as using dicts is
common where pure constant arithmetic expressions aren't.


Well it seems you didn't follow that thread thorougly. If you had you
would have known that if the objects one had to work with were at
the same time mutable and usefull as keys, you have to turn them
into an immutable now for use as a key. This is a copy operation.
So compared to the situation now, no extra copying would be necessary
and no extra costs would be needed.

--
Antoon Pardon
Jul 18 '05 #25

P: n/a
> So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.
It certainly did not choose a nondeterministic action - that would mean that
it followed _both_ possibilities at the same time. Which clearly is not
happening.

And we didn't talk about (2,3) + (4,5) not being (6,8) - that's adding two
tuples, not having (9) beeing a tuple instead of a simple nine.

Of course one could have overloaded tuples that way - component wise
addition - but then people would want other kinds of vector algebraic stuff
working on them. But they are not vectors, they are tuples.

And in general, that is an entirely new discussion about the overloading of
operators for tuples, not the syntax of how to create them (which is
legitimate, of course - but misleading for this thread.)
No my opinion is not wrong, you just don't understand what I'm saying.
You alter the subject of discussion (see below), which caused that
confusion.
No it was not reasonable to introduce the semantics that made 2 * (1,2)
equal (1,2,1,2) IMO they should have used a differend operator for that
and not the *.
Maybe - but thats an alltogether different discussion, as I said before.

The point that made me kick into this discussion was:

""" You really, really want (3 + 5) to be an integer, not a one-item tuple.
I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.
"""

So you wanted (8) to be a tuple, or even more so 3 + 5 being (3,) + (5,).
What has that to do with the operator overloading of tuples in general?
It's a syntactic question we're discussing, _not_ a semantic one.

As I stated before, it could become a question of type semantics if python
was statically typed, as then the context of a expression like (8) could
determine which type has to be created - tuple of one item, or simple 8.
But it's not doable in python.
For someone who expresses his disliking to type _one_ comma in the few
cases of single element tuples in thousands of lines of code, it strikes
me odd that you'd go an are willing to add extra trouble entering _each_
and _every_ tuple in your code by using some hitherto unknown character
that won't be enterable easily....


Where did I express this dislike. I'm not denying it because I know I
forget such things, but I sure don't remember now.


I showed the quote above - you wanted to have (8) behave as (8,) - so I
concluded you either don't like typing that extra comma, or alternatively
want introduce a new pair of parentheses to express tuples.
Well it seems you didn't follow that thread thorougly. If you had you
would have known that if the objects one had to work with were at
the same time mutable and usefull as keys, you have to turn them
into an immutable now for use as a key. This is a copy operation.
So compared to the situation now, no extra copying would be necessary
and no extra costs would be needed.


I did follow it, and I didn't say that the copying was necessary all the
time, even for immutable keys.

--
Regards,

Diez B. Roggisch
Jul 18 '05 #26

P: n/a
Antoon Pardon wrote:
for instance I have written once somekind of vector class where
it was natural for these vectors to be added as well as te be
concatenated. Unfortunately python uses "+" for both so I had
no way to have both operators in a natural way in python.


Yes this is a quite common problem if one wants to have both an
addition- and a concatenation operator. I created once a <Hex> class
representing both a bytecode and a number and i resolved the need for
a concatenation by overloading __floordiv__. Both a __div__ and a
__floordiv__ are not needed for most of the types that are not ints.
a,b = Hex(0x78),Hex("00")
a+b 0x78 a//b

0x7800

I would have prefered overloading a common concatenation operaor, say
__cat__ which is mapped onto "||" but i think using "+" for
concatenation comes from the convenience to concatenate strings in this
manner in other languages and has spreaded into the domain of lists and
tuples in Python.

On the other hand i find Mathematicas list operators very appealing:

In =: [1,2,3]^2
Out=: [1,4,9]

Compared with this suggar the list comprehension [x**2 for x in
[1,2,3]]
is ugly.

Regards Kay

Jul 18 '05 #27

P: n/a
Op 2005-03-17, Diez B. Roggisch schreef <de*********@web.de>:
So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.
It certainly did not choose a nondeterministic action - that would mean that
it followed _both_ possibilities at the same time. Which clearly is not
happening.

And we didn't talk about (2,3) + (4,5) not being (6,8) - that's adding two
tuples, not having (9) beeing a tuple instead of a simple nine.
We talked about the confusion that could arrise if a number could be
interpreted as a tuple because the '+' operator has a different
kind of result depending on whether the operands are numbers or
tuples. However if adding tuples would have been defined as
above their would have been a confusion because the result
would have been equivallent. 4 + 5 would have been 9 and
(4,) + (5,) would have been (9,)

And having chosen such a design wouldn't have made python
any less dynamic. So saying that the problem is the result
of python being dynamic as you once did is nonsense.
Of course one could have overloaded tuples that way - component wise
addition - but then people would want other kinds of vector algebraic stuff
working on them. But they are not vectors, they are tuples.
That could very well have been left to the users themselves. They
only needed to have used a different character for concatenation
instead of the "+".
And in general, that is an entirely new discussion about the overloading of
operators for tuples, not the syntax of how to create them (which is
legitimate, of course - but misleading for this thread.)
You claimed it was pythons dynamic nature that makes it difficult
to use items and one-item tuples as equivallent. I say
it has little to do with tha dynamic nature but more with the
design to use the same characters for sequence and number operations.
If these operations would have been indicated by different characters
no such problem would arrise with doing such unification.
No my opinion is not wrong, you just don't understand what I'm saying.


You alter the subject of discussion (see below), which caused that
confusion.
No it was not reasonable to introduce the semantics that made 2 * (1,2)
equal (1,2,1,2) IMO they should have used a differend operator for that
and not the *.


Maybe - but thats an alltogether different discussion, as I said before.


No it is not. It is part of a counter argument to your claim
that python's dynamic nature is in the way.
The point that made me kick into this discussion was:

"""
You really, really want (3 + 5) to be an integer, not a one-item tuple.
I sometimes do wonder if some impliciteness wouldn't be better here,
so that any item could be treated as if it was a one-item tuple.
"""
So you wanted (8) to be a tuple, or even more so 3 + 5 being (3,) + (5,).
What has that to do with the operator overloading of tuples in general?
It's a syntactic question we're discussing, _not_ a semantic one.


I didn't say I want that. I was just wondering if unification between
numbers and one number tuples wouldn't have been a good solution with
the confusion people have about (1) not being a tuple.
As I stated before, it could become a question of type semantics if python
was statically typed, as then the context of a expression like (8) could
determine which type has to be created - tuple of one item, or simple 8.
But it's not doable in python.


It has litte to do with statically typing. But when I explain that
and show what will cause a problem with such unification in current
python you say I'm altering the subject.
For someone who expresses his disliking to type _one_ comma in the few
cases of single element tuples in thousands of lines of code, it strikes
me odd that you'd go an are willing to add extra trouble entering _each_
and _every_ tuple in your code by using some hitherto unknown character
that won't be enterable easily....


Where did I express this dislike. I'm not denying it because I know I
forget such things, but I sure don't remember now.


I showed the quote above - you wanted to have (8) behave as (8,) - so I
concluded you either don't like typing that extra comma, or alternatively
want introduce a new pair of parentheses to express tuples.


I was wondering about the merrits of (8) behaving as (8,) that is
not the same as wanting it. May be you shouldn't read thing that
are not there.

--
Antoon Pardon
Jul 18 '05 #28

P: n/a
Op 2005-03-16, Daniel Dittmar schreef <da****@dittmar.net>:
Diez B. Roggisch wrote:
I reread his example and have to admit I'm confused: He complains about
having written his _own_ vector class - and concatenation and addition had
to use both + ?


I've interpreted it as:
If Python had choosen different operators for addition and sequence
concatenation, I could have implemented them both in my vector class. As
it is, I have to implement one of them using a non-standard operator.
The examples focus too much on numbers - if we use instead

("foo")

we would get a iterable yielding ["foo",] or - as string already supports
iteration - ['f', 'o', 'o']. Which one to chose?


What I was hinting at (NOT proposing, I'd hate this) was that integers
implement the [] operator. 5 [0] would then return 5, for all practical
purposes, it would look like a tuple. String already implements []. Yes,
that would lead to really surprising and inconsistent behaviour.
I find this 'creative use of overloading' rather awful. But what the
heck, I find list comprehension rather awful.

Well, the number of operators built into the language is limited - and I
actually prefer to have the possibility to overload these if I want to.
Nobody forces me - I could use

v1.concat(v2)

for two vectors v1, v2 if I wanted to.


My peeve is about having operators added to standard types. This
increases the chances that using an object the wrong way leads to a
bogus result, not a runtime error. A more common programming error I
commit is passing a string where a list ist expected. And then I wonder
why later operations work on one-character strings.


The standard answer to this seems to be to use unittesting.

--
Antoon Pardon
Jul 18 '05 #29

P: n/a
Antoon Pardon wrote:
My peeve is about having operators added to standard types. This
increases the chances that using an object the wrong way leads to a
bogus result, not a runtime error. A more common programming error I
commit is passing a string where a list ist expected. And then I wonder
why later operations work on one-character strings.

The standard answer to this seems to be to use unittesting.


I do detect that there is a problem. It just takes longer to find the
source of bogus data than to look at a stack trace.

Daniel
Jul 18 '05 #30

P: n/a
Op 2005-03-18, Daniel Dittmar schreef <da************@sap.corp>:
Antoon Pardon wrote:
My peeve is about having operators added to standard types. This
increases the chances that using an object the wrong way leads to a
bogus result, not a runtime error. A more common programming error I
commit is passing a string where a list ist expected. And then I wonder
why later operations work on one-character strings.

The standard answer to this seems to be to use unittesting.


I do detect that there is a problem. It just takes longer to find the
source of bogus data than to look at a stack trace.


Sure. But some language features would make finding the source of
some problems even faster. But when those arguments are made
the response is: use unittesting.

--
Antoon Pardon
Jul 18 '05 #31

P: n/a
Kay Schluehr wrote:
On the other hand i find Mathematicas list operators very appealing:

In =: [1,2,3]^2
Out=: [1,4,9]

Compared with this suggar the list comprehension [x**2 for x in
[1,2,3]]
is ugly.


py> import numarray
py> a = numarray.array([1, 2, 3])
py> a**2
array([1, 4, 9])

STeVe
Jul 18 '05 #32

P: n/a
On 15 Mar 2005 11:25:15 -0500, rumours say that ro*@panix.com (Roy
Smith) might have written:
The big question is, is it the parens that make it a tuple, or is it
the comma? If you go along with the parens school of thought, then
(1,) is the special case. If you believe in commas, then the () is
the special case. In either case, it's a bit ugly, but we learn to
overlook the occasional cosmetic blemishes of those we love :-)


My take on this is that comma defines tuples, and () is the exception.

..>> tpl = 1, 2, 3 * 4; print tpl
(1, 2, 12)
..>> tpl = (1, 2, 3) * 4; print tpl
(1, 2, 3, 1, 2, 3, 1, 2, 3, 1, 2, 3)

So parentheses just change precedence (comma has lower precedence than
star).
--
TZOTZIOY, I speak England very best.
"Be strict when sending and tolerant when receiving." (from RFC1958)
I really should keep that in mind when talking with people, actually...
Jul 18 '05 #33

P: n/a
Antoon Pardon wrote:
<snip>
So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.


("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")

As we say in Australia, "What The ....."

Joal
Jul 18 '05 #34

P: n/a
Op 2005-03-27, Joal Heagney schreef <jo**@bigpond.net.au>:
Antoon Pardon wrote:
<snip>
So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.


("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")


No, that wouldn't be the result. You are still using "+" for
concatenation, even if only on strings. I say python should
have used something else for concatenation (string concatenation
included)

--
Antoon Pardon
Jul 18 '05 #35

P: n/a
>>>>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:

Antoon> Op 2005-03-27, Joal Heagney schreef <jo**@bigpond.net.au>:
Antoon Pardon wrote:
<snip>
So python choose a non-deterministic direction. To me (2,3) + (4,5)
equals (6,8). I don't dispute that having an operator to combine
(2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
used the "+" for that.


("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")


Antoon> No, that wouldn't be the result. You are still using "+"
Antoon> for concatenation, even if only on strings. I say python
Antoon> should have used something else for concatenation (string
Antoon> concatenation included)

To me, nothing is more natural than "ab" + "cd" == "abcd". Also [1,2]
+ [3,4] == [1,2,3,4]. "Dot product" is not really too useful in real
world (non-mathematical) apps.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #36

P: n/a
>>>>> "Ville" == Ville Vainio <vi***@spammers.com> writes:

Ville> To me, nothing is more natural than "ab" + "cd" ==
Ville> "abcd". Also [1,2] + [3,4] == [1,2,3,4]. "Dot product" is
Ville> not really too useful in real world (non-mathematical)
Ville> apps.

.... and of course by "dot product", I don't mean dot product at all. I
was thinking of summing vectors, which is not that much more common
either.

--
Ville Vainio http://tinyurl.com/2prnb
Jul 18 '05 #37

P: n/a
Op 2005-03-29, Ville Vainio schreef <vi***@spammers.com>:
>> "Antoon" == Antoon Pardon <ap*****@forel.vub.ac.be> writes:
Antoon> Op 2005-03-27, Joal Heagney schreef <jo**@bigpond.net.au>: >> Antoon Pardon wrote:
>> <snip>
>>> So python choose a non-deterministic direction. To me (2,3) + (4,5)
>>> equals (6,8). I don't dispute that having an operator to combine
>>> (2,3) and (4,5) in (2,3,4,5) is usefull, but they should never have
>>> used the "+" for that.
>>
>> ("alph", "bravo") + ("delta", "max") --> ("alphdelta", "bravomax")


Antoon> No, that wouldn't be the result. You are still using "+"
Antoon> for concatenation, even if only on strings. I say python
Antoon> should have used something else for concatenation (string
Antoon> concatenation included)

To me, nothing is more natural than "ab" + "cd" == "abcd". Also [1,2]
+ [3,4] == [1,2,3,4]. "Dot product" is not really too useful in real
world (non-mathematical) apps.


What is more natural, that you concatenate strings and lists or that
you use the "+" for it. Suppose python would have used '#" to express
concatenation so that "ab" # "cd" == "abcd". After using this for
sometime nothing would have been more natural than this.

--
Antoon Pardon
Jul 18 '05 #38

This discussion thread is closed

Replies have been disabled for this discussion.