Re: Why tuple with one item is no tuple
Op 2005-03-27, Joal Heagney schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Antoon == Antoon Pardon [EMAIL PROTECTED] writes: Antoon Op 2005-03-27, Joal Heagney schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Ville == Ville Vainio [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-29, Ville Vainio schreef [EMAIL PROTECTED]: Antoon == Antoon Pardon [EMAIL PROTECTED] writes: Antoon Op 2005-03-27, Joal Heagney schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
On 15 Mar 2005 11:25:15 -0500, rumours say that [EMAIL PROTECTED] (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... -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-17, Diez B. Roggisch schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-16, Daniel Dittmar schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-18, Daniel Dittmar schreef [EMAIL PROTECTED]: 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-16, Diez B. Roggisch schreef [EMAIL PROTECTED]: 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 *. Soo, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Gregor Horvath [EMAIL PROTECTED] 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, [EMAIL PROTECTED]
Providenza Boekelheide, Inc.
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-16, Tim Roberts schreef [EMAIL PROTECTED]:
Gregor Horvath [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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. Soo, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Op 2005-03-16, Diez B. Roggisch schreef [EMAIL PROTECTED]: 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. Soo, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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. Soo, 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Daniel Dittmar wrote: But what the heck, I find list comprehension rather awful. Sacrilege! ;) STeVe -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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
[EMAIL PROTECTED]
In the fields of hell where the grass grows high
Are the graves of dreams allowed to die.
-- Richard Harter
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
('1',) is a tuple... you need the comma to make it a tuple.
regards,
Fuzzy
http://www.voidspace.org.uk/python/index.shtml
--
http://mail.python.org/mailman/listinfo/python-list
RE: Why tuple with one item is no tuple
Title: RE: Why tuple with one item is no tuple
[Gregor Horvath]
#- type(('1'))
#- type 'str'
#-
#- I wonder why ('1') is no tuple
The parentheses don't create the tuple, the comma does:
('1')
'1'
('1',)
('1',)
'1',
('1',)
. Facundo
Bitácora De Vuelo: http://www.taniquetil.com.ar/plog
PyAr - Python Argentina: http://pyar.decode.com.ar/
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
On Tue, 15 Mar 2005 16:16:34 GMT, Gregor Horvath [EMAIL PROTECTED] 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
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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/ .
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Gregor Horvath [EMAIL PROTECTED] 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 :-)
--
http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
thanks are given to all problem solved... -- Greg -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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. -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
On Tue, 15 Mar 2005 10:47:28 -0800, James Stroud [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
Bill Mill wrote: On Tue, 15 Mar 2005 10:47:28 -0800, James Stroud [EMAIL PROTECTED] 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 -- http://mail.python.org/mailman/listinfo/python-list
Re: Why tuple with one item is no tuple
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 -- http://mail.python.org/mailman/listinfo/python-list
