As you probably know, the next version of Javascript (1.7) will have a number of ideas that have been borrowed from Python. In particular, the "tuple assignment" syntax will now be supported in Javascript, which will be a pleasant addition to the language. However, I noticed that the Javascript version is, in some respects, a superset of the Python functionality. If you are interested, you might have a look at this page: http://developer.mozilla.org/en/docs/New_in_JavaScript_1.7 Go to the section called "Destructuring assignment" to check out how the new syntax is going to work. As an example of what I mean, the Javascript unpacking syntax will allow variables to be skipped: [a,,b] = [1,2,3] In other words, a is assigned the value 1, the value 2 is thrown away, and b is assigned the value 3. In today's Python, this requires a dummy variable. I admit that this is not a particularly important feature; However, given that Javascript is being inspired by Python in this case, maybe it would be appropriate to return the favor? -- Talin
Brett Cannon wrote:
I personally am -1 on the idea. Explicit is better than implicit.
One thing I *would* like to see, that Javascript doesn't seem to have either yet, is a *-arg on the end of the unpacking list: a, b, *c = [1, 2, 3, 4, 5] giving a == 1, b == 2, c == [3, 4, 5]. -- Greg
Brett Cannon wrote:
(If I recall correctly) There was some support for using the '*' outside of function signatures. I think it died out because of too many alternative suggestions. Or there was some sort of ambiguous situations I'm not remembering, possibly confusion with the multiply operator. I have mixed feeling on it myself. The reason being, (to me), using the '*' for both packing and unpacking is not the most readable solution. Also the '*' syntax can't be used to unpack nested items.
Ron
Ron Adam wrote:
I have mixed feeling on it myself.
As far as I remember, there weren't really any objective reasons given against it, just gut feelings of dislike from some people, including Guido. I'm living in hopes that he may come round to the idea in time (as he did with conditional expressions, for example).
The reason being, (to me), using the '*' for both packing and unpacking is not the most readable solution.
To me it doesn't seem any less readable than using [...,...] or (...,...) for both packing and unpacking, or using * in both function definitions and calls. In fact the symmetry is a large part of the beauty of the idea.
Also the '*' syntax can't be used to unpack nested items.
I'm not sure what you mean by that. >>> [[a, b, *c], [d, e, *f], *g] = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> print a, b, c, d, e, f, g 1 2 [3, 4] 5 6 [7, 8] [9, 10] Makes perfectly good sense to me. -- Greg
Greg Ewing wrote:
Didn't say it didn't. Symmetry is not always the best solution. Sometimes asymmetry is good because it can communicate a different context more clearly. That is more of a 'human' issue than machine one. My opinion is in regards to what would be better for me. It's not a right or wrong point of view and may not be better for others. Hmmm... I think there might be an idea related to this of separating formatting from the assignment is such a way that the destination isn't specific to the source structure. (food for thought?) For example: *what if* a sort of string formatting style where used to repack objects at their destination? Where '%%' means repack this object this way at the destination, '[]' is unpack, '*' is pack, and ',' are used to indicate place holders. The example from above could then be... >>> data = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> a, b, c, d, e, f, g = "[[,,*],[,,*],*]" %% data >>> print a, b, c, d, e, f, g 1 2 [3, 4] 5 6 [7, 8] [9, 10] A chained operation would need to be be done in this next example. Works form left to right. >>> data = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> a, b, c, d = ",,,*" %% "[,[],,]" %% data >>> print a, b, c, d [1, 2, 3, 4] 5 6 [7, 8, 9, 10] Possibly the repack specifiers would be pushed onto a stack then pulled back off to do the actual repacking at assignment time. (?) These are just examples to illustrate a concept. The point here is to allow for the separation of the data structure knowledge from assignments while still being an operation that can happen at the destination. That may avoid creating intermediate objects. This type of abstraction may make it easier to interface different types of objects and data structures dynamically. Of course a function could be made to do this, but it would likely be much much slower. a, b, c = repack(data, repack_specifier) Ron
On 3/7/07, Ron Adam <rrr@ronadam.com> wrote:
...
...
This type of abstraction may make it easier to interface different types of objects and data structures dynamically.
I can see how this might be made efficient. I'm not seeing how I could ever maintain code that used it. -jJ
Jim Jewett wrote:
Yes, that would be a problem. (And I need to resist posting things like this because then I feel obligated to try to explain them. ie... wait 24 hours and if it still seems like a good idea, then post it.) Regarding maintaining code: For interfacing purposes you would probably define the re-packers with the data and not where you actually use them. And use in-line comments as well. Trying a different format. (This can't be a serious proposal unless it can be made simple to understand.) '[]' for unpack items, these can be nested. '.' a single unchanged item '.n' for next n unchanged items '*n' for packing next n items '*' pack the rest of the items, use at the end only. '' Null, don't change anything * Doing it in two steps is the easy way, unpack+repack. * Both unpacking/repacking can be done in one step if the items are aligned. * partial unpacking/repacking is perfectly ok. (if it does what you want) data_source_v1 = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] unpack_v1 = "[[][]..]" repack_to_v2 = "..*2..*2*" # 1,2,[3,4],5,6,[7,8],[9,10] data_source_v2 = [1, 2, [3, 4], 5, 6, [7, 8], [9, 10]] unpack_v2 = "[..[]..[][]]" repack_to_v1 = "*4*4.." # [1,2,3,4][5,6,7,8],9,10 def interface_v1(data, unpack='', repack=''): a, b, c, d = repack %% unpack %% data # Do something with a thru d. def interface_v2(data, unpack='', repack=''): a, b, c, d, e ,f, g = repack %% unpack %% data # do something with a thru g # use data sources with interface v1 interface_v1(data_source_v1) # use v1 data as is interface_v1(data_source_v2, unpack_v2, repack_to_v1) # use data sources with interface V2 interface_v2(data_source_v2) # use v2 data as is interface_v2(data_source_v1, upack_v1, repack_to_v2) Decorators probably currently fit this use better I think. Cheers, Ron
Ron Adam wrote:
Then I still don't know what you meant by your original comment. What kind of nested item unpacking would you like to do that the * syntax wouldn't handle?
Symmetry is not always the best solution. Sometimes asymmetry is good because it can communicate a different context more clearly.
Perhaps, but why do you think that the symmetry we already have between packing and unpacking is okay, but a new symmetry involving * wouldn't be okay? -- Greg
Greg Ewing wrote:
This was what I was that originally referring to. data = [1, 2, [3, 4], 5] a, b, c, d, e = data # can't unpack [3,4] here with * a, b, [c, d], e = data # must use [] on the left side instead
The * is used mostly with names and they tend to look more alike than the equivalent packing or unpacking using () or [] in more situations. The () and [] are much more explicit in both packing and unpacking operations. I like the packing and unpacking features of python very much, it's just I would like it a bit more if the '*' symbol for packing and unpacking were different in this particular case. And especially so if '*' packing and unpacking features are used in a more general way. def foo(*args, **kwds): # packs here bar(&args, &&kwds): # unpacks here a, b, *c = a, b, c, d # packs here a, b, c = &items # unpacks here It would just be easier for me to see and keep in my head while I'm working with it. I'm not sure I can explain it better than that, or say exactly why as it probably has more to do with how my brain works than weather it is okay or not okay in any programing sense. Is that clearer? (I don't expect this to be changed) Ron
Brett Cannon wrote:
As mentioned in the recipe, the original discussion was here: http://mail.python.org/pipermail/python-dev/2002-November/030380.html The last message posted on the thread was from GvR, who was against it: http://mail.python.org/pipermail/python-dev/2002-November/030437.html Cheers, /larry/
On 3/5/07, Brett Cannon <brett@python.org> wrote:
It skips in the middle?!? Yuck.
Are you assuming variable-length skips, so that [a,,b] = [1,2,3,4,5] would mean a=1;b=5 ? I had read it is just not requiring a name for the unused dummy variable. It doesn't really seem worse than [a, _junk, b] = [1,2,3] or less explicit than [a,_,b] = [1,2,3] -jJ
On 3/6/07, Jim Jewett <jimjjewett@gmail.com> wrote:
Yep, that's how I read it.
Right, but why the ends? And what if that example had three variables to unpack to, e.g., a, b, and c? With a = 1 and c = 5, what does b get? 2, 4, 3? It can be intrepreted in so many ways its ambiguous without referencing the documentation. -Brett
To me, the interesting development on the JavaScript front is Tamarin, the new JavaScript VM contributed by Adobe. Tamarin contains a just-in-time compiler. I don't know how many people here have seriously looked at the JavaScript engine, but it's not *that* different from Python. I know compiling to machine code has been discussed here, and the consensus is that it's not worth it. I'm wondering: how can this be right for JavaScript and wrong for Python? Is Mozilla making a mistake? -j
Jason Orendorff wrote:
Javascript is a much simpler language than Python, with far fewer potential data types. Maybe that makes it easier to compile efficiently. Most likely it makes the task of writing a compiler much easier. Or, who knows, maybe it isn't right for Javascript either. Just because someone does something doesn't necessarily mean it's a good idea. -- Greg
Brett Cannon wrote:
I personally am -1 on the idea. Explicit is better than implicit.
One thing I *would* like to see, that Javascript doesn't seem to have either yet, is a *-arg on the end of the unpacking list: a, b, *c = [1, 2, 3, 4, 5] giving a == 1, b == 2, c == [3, 4, 5]. -- Greg
Brett Cannon wrote:
(If I recall correctly) There was some support for using the '*' outside of function signatures. I think it died out because of too many alternative suggestions. Or there was some sort of ambiguous situations I'm not remembering, possibly confusion with the multiply operator. I have mixed feeling on it myself. The reason being, (to me), using the '*' for both packing and unpacking is not the most readable solution. Also the '*' syntax can't be used to unpack nested items.
Ron
Ron Adam wrote:
I have mixed feeling on it myself.
As far as I remember, there weren't really any objective reasons given against it, just gut feelings of dislike from some people, including Guido. I'm living in hopes that he may come round to the idea in time (as he did with conditional expressions, for example).
The reason being, (to me), using the '*' for both packing and unpacking is not the most readable solution.
To me it doesn't seem any less readable than using [...,...] or (...,...) for both packing and unpacking, or using * in both function definitions and calls. In fact the symmetry is a large part of the beauty of the idea.
Also the '*' syntax can't be used to unpack nested items.
I'm not sure what you mean by that. >>> [[a, b, *c], [d, e, *f], *g] = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> print a, b, c, d, e, f, g 1 2 [3, 4] 5 6 [7, 8] [9, 10] Makes perfectly good sense to me. -- Greg
Greg Ewing wrote:
Didn't say it didn't. Symmetry is not always the best solution. Sometimes asymmetry is good because it can communicate a different context more clearly. That is more of a 'human' issue than machine one. My opinion is in regards to what would be better for me. It's not a right or wrong point of view and may not be better for others. Hmmm... I think there might be an idea related to this of separating formatting from the assignment is such a way that the destination isn't specific to the source structure. (food for thought?) For example: *what if* a sort of string formatting style where used to repack objects at their destination? Where '%%' means repack this object this way at the destination, '[]' is unpack, '*' is pack, and ',' are used to indicate place holders. The example from above could then be... >>> data = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> a, b, c, d, e, f, g = "[[,,*],[,,*],*]" %% data >>> print a, b, c, d, e, f, g 1 2 [3, 4] 5 6 [7, 8] [9, 10] A chained operation would need to be be done in this next example. Works form left to right. >>> data = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] >>> a, b, c, d = ",,,*" %% "[,[],,]" %% data >>> print a, b, c, d [1, 2, 3, 4] 5 6 [7, 8, 9, 10] Possibly the repack specifiers would be pushed onto a stack then pulled back off to do the actual repacking at assignment time. (?) These are just examples to illustrate a concept. The point here is to allow for the separation of the data structure knowledge from assignments while still being an operation that can happen at the destination. That may avoid creating intermediate objects. This type of abstraction may make it easier to interface different types of objects and data structures dynamically. Of course a function could be made to do this, but it would likely be much much slower. a, b, c = repack(data, repack_specifier) Ron
On 3/7/07, Ron Adam <rrr@ronadam.com> wrote:
...
...
This type of abstraction may make it easier to interface different types of objects and data structures dynamically.
I can see how this might be made efficient. I'm not seeing how I could ever maintain code that used it. -jJ
Jim Jewett wrote:
Yes, that would be a problem. (And I need to resist posting things like this because then I feel obligated to try to explain them. ie... wait 24 hours and if it still seems like a good idea, then post it.) Regarding maintaining code: For interfacing purposes you would probably define the re-packers with the data and not where you actually use them. And use in-line comments as well. Trying a different format. (This can't be a serious proposal unless it can be made simple to understand.) '[]' for unpack items, these can be nested. '.' a single unchanged item '.n' for next n unchanged items '*n' for packing next n items '*' pack the rest of the items, use at the end only. '' Null, don't change anything * Doing it in two steps is the easy way, unpack+repack. * Both unpacking/repacking can be done in one step if the items are aligned. * partial unpacking/repacking is perfectly ok. (if it does what you want) data_source_v1 = [[1, 2, 3, 4], [5, 6, 7, 8], 9, 10] unpack_v1 = "[[][]..]" repack_to_v2 = "..*2..*2*" # 1,2,[3,4],5,6,[7,8],[9,10] data_source_v2 = [1, 2, [3, 4], 5, 6, [7, 8], [9, 10]] unpack_v2 = "[..[]..[][]]" repack_to_v1 = "*4*4.." # [1,2,3,4][5,6,7,8],9,10 def interface_v1(data, unpack='', repack=''): a, b, c, d = repack %% unpack %% data # Do something with a thru d. def interface_v2(data, unpack='', repack=''): a, b, c, d, e ,f, g = repack %% unpack %% data # do something with a thru g # use data sources with interface v1 interface_v1(data_source_v1) # use v1 data as is interface_v1(data_source_v2, unpack_v2, repack_to_v1) # use data sources with interface V2 interface_v2(data_source_v2) # use v2 data as is interface_v2(data_source_v1, upack_v1, repack_to_v2) Decorators probably currently fit this use better I think. Cheers, Ron
Ron Adam wrote:
Then I still don't know what you meant by your original comment. What kind of nested item unpacking would you like to do that the * syntax wouldn't handle?
Symmetry is not always the best solution. Sometimes asymmetry is good because it can communicate a different context more clearly.
Perhaps, but why do you think that the symmetry we already have between packing and unpacking is okay, but a new symmetry involving * wouldn't be okay? -- Greg
Greg Ewing wrote:
This was what I was that originally referring to. data = [1, 2, [3, 4], 5] a, b, c, d, e = data # can't unpack [3,4] here with * a, b, [c, d], e = data # must use [] on the left side instead
The * is used mostly with names and they tend to look more alike than the equivalent packing or unpacking using () or [] in more situations. The () and [] are much more explicit in both packing and unpacking operations. I like the packing and unpacking features of python very much, it's just I would like it a bit more if the '*' symbol for packing and unpacking were different in this particular case. And especially so if '*' packing and unpacking features are used in a more general way. def foo(*args, **kwds): # packs here bar(&args, &&kwds): # unpacks here a, b, *c = a, b, c, d # packs here a, b, c = &items # unpacks here It would just be easier for me to see and keep in my head while I'm working with it. I'm not sure I can explain it better than that, or say exactly why as it probably has more to do with how my brain works than weather it is okay or not okay in any programing sense. Is that clearer? (I don't expect this to be changed) Ron
Brett Cannon wrote:
As mentioned in the recipe, the original discussion was here: http://mail.python.org/pipermail/python-dev/2002-November/030380.html The last message posted on the thread was from GvR, who was against it: http://mail.python.org/pipermail/python-dev/2002-November/030437.html Cheers, /larry/
On 3/5/07, Brett Cannon <brett@python.org> wrote:
It skips in the middle?!? Yuck.
Are you assuming variable-length skips, so that [a,,b] = [1,2,3,4,5] would mean a=1;b=5 ? I had read it is just not requiring a name for the unused dummy variable. It doesn't really seem worse than [a, _junk, b] = [1,2,3] or less explicit than [a,_,b] = [1,2,3] -jJ
On 3/6/07, Jim Jewett <jimjjewett@gmail.com> wrote:
Yep, that's how I read it.
Right, but why the ends? And what if that example had three variables to unpack to, e.g., a, b, and c? With a = 1 and c = 5, what does b get? 2, 4, 3? It can be intrepreted in so many ways its ambiguous without referencing the documentation. -Brett
To me, the interesting development on the JavaScript front is Tamarin, the new JavaScript VM contributed by Adobe. Tamarin contains a just-in-time compiler. I don't know how many people here have seriously looked at the JavaScript engine, but it's not *that* different from Python. I know compiling to machine code has been discussed here, and the consensus is that it's not worth it. I'm wondering: how can this be right for JavaScript and wrong for Python? Is Mozilla making a mistake? -j
Jason Orendorff wrote:
Javascript is a much simpler language than Python, with far fewer potential data types. Maybe that makes it easier to compile efficiently. Most likely it makes the task of writing a compiler much easier. Or, who knows, maybe it isn't right for Javascript either. Just because someone does something doesn't necessarily mean it's a good idea. -- Greg
participants (8)
-
Brett Cannon -
Greg Ewing -
Jason Orendorff -
Jim Jewett -
Josiah Carlson -
Larry Hastings -
Ron Adam -
Talin