Re: Tuple assignment
On 2015-05-10 10:14, Oren Tirosh wrote: I think it should work for any two structs as long their fields are public and individually assignment-compatible. Just for the record, tupleof bypasses protection. -- /Jacob Carlborg
Re: Tuple assignment
On 5/10/2015 1:18 AM, Russel Winder via Digitalmars-d wrote: Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. This is what makes D's ranges+algorithms so attractive. They are easier to write correct code in, and when optimized produce the same code.
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: On 5/9/2015 10:16 AM, Russel Winder via Digitalmars-d wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); I am assuming this is horrendously inefficient at run time compared to having the intermediate value explicit: auto t = next; next = current + next; current = t; or is it? It probably depends on the compiler. The way to find out is to look at the generated assembler. Using LDC, the tuple version generates more code unoptimized, but with optimization, the exact same assembly language code is generated for the two cases. Win. Albeit the D syntax is not as nice as the Python syntax. -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Sun, 2015-05-10 at 08:47 +, Oren Tirosh via Digitalmars-d wrote: […] tuple(current, next) = tuple(next , current +next); […] Works for me. If this is version or compiler dependent this definitely needs investigation. It does not for me using rdmd 2.067. My implementation of nth Fibonacci Number leads to success for my version but not for yours. Maybe we should exchange codes offlist? -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: […] TypeTuple!(current, next) = tuple(next , current +next); This works. This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. […] -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. pedant-modeassembly language file, not assembler (which is the program to do the transformation)/pedant-mode ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. Tuples are implemented as structs. I know that ldc is capable of slicing structs into register-sized pieces and optimizing them independently, dmd does not. So ldc would very possibly generate the kind of code for that that you'd like. I shall investigate with gdc as well as ldc. Though, sadly, whilst gdc is in Debian it is not in Fedora. :-( -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@winder.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
On Saturday, 9 May 2015 at 20:07:00 UTC, Walter Bright wrote: It probably depends on the compiler. The way to find out is to look at the generated assembler. fwiw, I tried to look at this earlier and found out a single tuple generates too much assembly for asm.dlang.org to display ;)
Re: Tuple assignment
On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); Note, however, that this is not a tuple assignment. It is assignment of a misleadingly-named anonymous struct type that is implemented in the standard library. This is an actual tuple assignment as supported by the compiler: a.tupleof = b.tupleof; I think it should work for any two structs as long their fields are public and individually assignment-compatible. I believe it is as efficient as individual assignments on all D implementations. A lot of people seem to want better sugar for tuple or tuple-like things in D and do not consider std.typecons sufficient (or at least find the names it uses confusing). Such a feature would work very nicely with D's auto types, return and lambda argument type inference, etc. See LINQ.
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:28:24 UTC, Russel Winder wrote: On Sun, 2015-05-10 at 08:14 +, Oren Tirosh via Digitalmars-d wrote: On Saturday, 9 May 2015 at 17:16:58 UTC, Russel Winder wrote: […] TypeTuple!(current, next) = tuple(next , current +next); This works. I did not mean imply that it doesn't, just that what I wrote is not some proposed syntax for tuple assignment but something that actually works now. This works right now and is quite aesthetically pleasing: tuple(current, next) = tuple(next , current +next); This does not. At least the tests fail with this where they do not with the previous. Works for me. If this is version or compiler dependent this definitely needs investigation.
Re: Tuple assignment
On 5/10/2015 1:07 AM, Russel Winder via Digitalmars-d wrote: ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. http://www.digitalmars.com/ctg/obj2asm.html
Re: Tuple assignment
On Sunday, 10 May 2015 at 08:07:38 UTC, Russel Winder wrote: On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. pedant-modeassembly language file, not assembler (which is the program to do the transformation)/pedant-mode ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. What's wrong with objdump?
Re: Tuple assignment
On 10 May 2015 at 21:41, John Colvin via Digitalmars-d digitalmars-d@puremagic.com wrote: On Sunday, 10 May 2015 at 08:07:38 UTC, Russel Winder wrote: On Sat, 2015-05-09 at 13:07 -0700, Walter Bright via Digitalmars-d wrote: […] It probably depends on the compiler. The way to find out is to look at the generated assembler. pedant-modeassembly language file, not assembler (which is the program to do the transformation)/pedant-mode ldc2 and gdc have options to write the assembly language file, maybe I am missing it but dmd appears not to advertise such an option. What's wrong with objdump? Assembly has more information, such as .align and .loc directives. ;-)
Re: Tuple assignment
On 5/9/2015 10:16 AM, Russel Winder via Digitalmars-d wrote: Python has tuple assignment so you see things like: previous, current = current, previous + current especially if you are doing silly things like calculating Fibonacci Sequence values. Translating this to D, you end up with: TypeTuple!(current, next) = tuple(next , current +next); I am assuming this is horrendously inefficient at run time compared to having the intermediate value explicit: auto t = next; next = current + next; current = t; or is it? It probably depends on the compiler. The way to find out is to look at the generated assembler. Tuples are implemented as structs. I know that ldc is capable of slicing structs into register-sized pieces and optimizing them independently, dmd does not. So ldc would very possibly generate the kind of code for that that you'd like.
Re: Tuple assignment
Juanjo Alvarez wrote:
On Thu, 07 Oct 2010 15:14:12 -0400, bearophile
bearophileh...@lycos.com wrote:
This is false both in Python2 and Python3.
What is exactly false on what I said?
python
Python 2.6.5 (r265:79063, Apr 1 2010, 05:28:39)
[GCC 4.4.3 20100316 (prerelease)] on linux2
Type help, copyright, credits or license for more information.
a, b, c, _ = ('tuple', 'of', 'three')
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: need more than 3 values to unpack
Jerome
--
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr
signature.asc
Description: OpenPGP digital signature
Re: Tuple assignment
On Fri, 08 Oct 2010 16:11:53 -0400, bearophile
bearophileh...@lycos.com wrote:
This syntax you have explained doesn't do what you think it does:
a, b, c, _ = ('tuple', 'of', 'three')
That was a typo, I meant to write:
a, b, _ = ('tuple', 'of', 'three')
Re: Tuple assignment
Juanjo Alvarez, el 9 de octubre a las 04:02 me escribiste:
On Fri, 08 Oct 2010 16:11:53 -0400, bearophile
bearophileh...@lycos.com wrote:
This syntax you have explained doesn't do what you think it does:
a, b, c, _ = ('tuple', 'of', 'three')
That was a typo, I meant to write:
a, b, _ = ('tuple', 'of', 'three')
Even then, the _ identifier is not special all :)
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
Me encanta el éxito; por eso prefiero el estado de progreso constante,
con la meta al frente y no atrás.
-- Ricardo Vaporeso. Punta del Este, Enero de 1918.
Re: Tuple assignment
On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote: If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; being equivalent to: auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $]; You can also do this with arrays, such that: float[3] xyz; auto (x, y, z) = xyz; The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; Python may be the best base to compare things to as tuple assignment has been in there for years. Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple: x = t then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and: a , b , c = t or ( a , b , c ) = t is tuple assignment where now t is required to be a tuple of length 3. cf. | python Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41) [GCC 4.4.3] on linux2 Type help, copyright, credits or license for more information. t = ( 1 , 'fred' , 2.0 ) x = t print x (1, 'fred', 2.0) a , b , c = t print a , b , c 1 fred 2.0 a , b = t Traceback (most recent call last): File stdin, line 1, in module ValueError: too many values to unpack a , b , c , d = t Traceback (most recent call last): File stdin, line 1, in module ValueError: need more than 3 values to unpack -- Russel. = Dr Russel Winder t: +44 20 7585 2200 voip: sip:russel.win...@ekiga.net 41 Buckmaster Roadm: +44 7770 465 077 xmpp: rus...@russel.org.uk London SW11 1EN, UK w: www.russel.org.uk skype: russel_winder signature.asc Description: This is a digitally signed message part
Re: Tuple assignment
Russel Winder wrote: Python may be the best base to compare things to as tuple assignment has been in there for years. Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple: x = t then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and: a , b , c = t or ( a , b , c ) = t is tuple assignment where now t is required to be a tuple of length 3. cf. The first thought was to make it an exact match approach. Andrei thought that the car/cdr one was better, though, and I find it intuitively appealing, too. Perhaps Python missed an important use case? Or perhaps the ambiguity as to whether the last item gets to be a value or another tuple is too much.
Re: Tuple assignment
Russel Winder wrote: Python may be the best base to compare things to as tuple assignment has been in there for years. Too segue this into the previous thread, how does Python treat (1)? Is it a floor wax or a dessert topping? http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/
Re: Tuple assignment
On Thu, 07 Oct 2010 10:43:18 +0400, Russel Winder rus...@russel.org.uk
wrote:
On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
If expr represents a tuple, we (Andrei and I) were thinking about the
syntax:
auto (a, b, c, d) = expr;
being equivalent to:
auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
You can also do this with arrays, such that:
float[3] xyz;
auto (x, y, z) = xyz;
The Lithpers among you will notice that this essentially provides a
handy
car,cdr shortcut for tuples and arrays:
auto (car, cdr) = expr;
Python may be the best base to compare things to as tuple assignment has
been in there for years.
Pythons choice is not a car/cdr approach but an exact match approach.
so if t represents a tuple datum or a function returning a tuple:
x = t
then x is a tuple -- remembering that variables are all just references
to objects implemented via keys in a dictionary, and:
a , b , c = t
or
( a , b , c ) = t
is tuple assignment where now t is required to be a tuple of length 3.
cf.
| python
Python 2.6.5 (r265:79063, Apr 16 2010, 13:57:41)
[GCC 4.4.3] on linux2
Type help, copyright, credits or license for more
information.
t = ( 1 , 'fred' , 2.0 )
x = t
print x
(1, 'fred', 2.0)
a , b , c = t
print a , b , c
1 fred 2.0
a , b = t
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: too many values to unpack
a , b , c , d = t
Traceback (most recent call last):
File stdin, line 1, in module
ValueError: need more than 3 values to unpack
That's because Python is not a strictly typed language. With proper type
propagation compiler helps you writing code the way in meant to be. E.g.
the following:
(a, b, c, d) = ('tuple', 'of', 'three')
could be statically disabled, but there is nothing wrong with allowing it
either: d would be just a no-op, you will know it for sure the moment you
try using it.
Re: Tuple assignment
On 10/6/2010 11:58 PM, Walter Bright wrote: Russel Winder wrote: Python may be the best base to compare things to as tuple assignment has been in there for years. Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple: x = t then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and: a , b , c = t or ( a , b , c ) = t is tuple assignment where now t is required to be a tuple of length 3. cf. The first thought was to make it an exact match approach. Andrei thought that the car/cdr one was better, though, and I find it intuitively appealing, too. Perhaps Python missed an important use case? Or perhaps the ambiguity as to whether the last item gets to be a value or another tuple is too much. I think the ambiguity should be avoided. There was one language I used ages ago that used a token to signal the use of the last arg as a 'rest' usage. If I remember right, it used: (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$] It also allowed: (a, @aggregate) = aggregate; // essentially a pop operation. That said, it was a weakly typed language, so it's application to D has to be taken with an appropriate dose of salt. For D, I think using the @ would clash badly with the attribute syntax, so an alternative that's not horrid: (a, b...) = aggregate; Later, Brad
Re: Tuple assignment
On Thu, 07 Oct 2010 11:42:06 +0400, Brad Roberts bra...@puremagic.com wrote: On 10/6/2010 11:58 PM, Walter Bright wrote: Russel Winder wrote: Python may be the best base to compare things to as tuple assignment has been in there for years. Pythons choice is not a car/cdr approach but an exact match approach. so if t represents a tuple datum or a function returning a tuple: x = t then x is a tuple -- remembering that variables are all just references to objects implemented via keys in a dictionary, and: a , b , c = t or ( a , b , c ) = t is tuple assignment where now t is required to be a tuple of length 3. cf. The first thought was to make it an exact match approach. Andrei thought that the car/cdr one was better, though, and I find it intuitively appealing, too. Perhaps Python missed an important use case? Or perhaps the ambiguity as to whether the last item gets to be a value or another tuple is too much. I think the ambiguity should be avoided. There was one language I used ages ago that used a token to signal the use of the last arg as a 'rest' usage. If I remember right, it used: (a, @b) = aggregate; // a = aggregate[0], b = aggregate[1..$] It also allowed: (a, @aggregate) = aggregate; // essentially a pop operation. That said, it was a weakly typed language, so it's application to D has to be taken with an appropriate dose of salt. For D, I think using the @ would clash badly with the attribute syntax, so an alternative that's not horrid: (a, b...) = aggregate; Later, Brad Interesting idea, I like it!
Re: Tuple assignment
On 10/7/10 1:43 CDT, Russel Winder wrote: On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote: If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; being equivalent to: auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $]; You can also do this with arrays, such that: float[3] xyz; auto (x, y, z) = xyz; The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; Python may be the best base to compare things to as tuple assignment has been in there for years. Pythons choice is not a car/cdr approach but an exact match approach. So then we'd have the proposed notation not work with dynamic arrays - only with static arrays and tuples. Andrei
Re: Tuple assignment
On 10/07/2010 09:03 AM, Walter Bright wrote: Russel Winder wrote: Python may be the best base to compare things to as tuple assignment has been in there for years. Too segue this into the previous thread, how does Python treat (1)? Is it a floor wax or a dessert topping? http://www.nbc.com/saturday-night-live/video/shimmer-floor-wax/1056743/ (1) == 1 (1,) == tuple([1])
Re: Tuple assignment
On 10/07/2010 08:08 AM, Walter Bright wrote: If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; being equivalent to: auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $]; You can also do this with arrays, such that: float[3] xyz; auto (x, y, z) = xyz; The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; Python 3 uses: car, *cdr = expr a, *b, c = [1,2,3,4,5] # leaves a=1, b=[2,3,4], c=5 I would like D to have (car, cdr...) = expr (a, b..., c) = [1,2,3,4,5] for the equivalent. Our varargs syntax is b..., theirs is *b. So it mirrors a bit, there. :-)
Re: Tuple assignment
Denis Koroskin Wrote:
That's because Python is not a strictly typed language. With proper type
propagation compiler helps you writing code the way in meant to be. E.g.
the following:
(a, b, c, d) = ('tuple', 'of', 'three')
could be statically disabled, but there is nothing wrong with allowing it
either: d would be just a no-op, you will know it for sure the moment you
try using it.
Python has the special symbol _ which is used exactly as a no-op (you could
call it foo it you wanted, but _
doesn't create new memory assignments) so you can expand arbitrary tuples
without creating new symbols:
a, b, c, _ = ('tuple', 'of', 'three')
I like the proposal for D, but I fear it could be a source of bugs (you expect
the tuple to expand to 4 values
but silently is expanding to only 3, leaving the fourth unchangued).
Re: Tuple assignment
On 10/7/10 3:55 CDT, Pelle wrote: On 10/07/2010 08:08 AM, Walter Bright wrote: If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; being equivalent to: auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $]; You can also do this with arrays, such that: float[3] xyz; auto (x, y, z) = xyz; The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; Python 3 uses: car, *cdr = expr a, *b, c = [1,2,3,4,5] # leaves a=1, b=[2,3,4], c=5 I would like D to have (car, cdr...) = expr (a, b..., c) = [1,2,3,4,5] for the equivalent. Our varargs syntax is b..., theirs is *b. So it mirrors a bit, there. :-) Excellent idea! Andrei
Re: Tuple assignment
Andrei Alexandrescu, el 7 de octubre a las 03:20 me escribiste:
On 10/7/10 1:43 CDT, Russel Winder wrote:
On Wed, 2010-10-06 at 23:08 -0700, Walter Bright wrote:
If expr represents a tuple, we (Andrei and I) were thinking about the
syntax:
auto (a, b, c, d) = expr;
being equivalent to:
auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $];
I guess d being missing is a typo, right?
You can also do this with arrays, such that:
float[3] xyz;
auto (x, y, z) = xyz;
The Lithpers among you will notice that this essentially provides a handy
car,cdr shortcut for tuples and arrays:
auto (car, cdr) = expr;
Python may be the best base to compare things to as tuple assignment has
been in there for years.
Pythons choice is not a car/cdr approach but an exact match approach.
So then we'd have the proposed notation not work with dynamic arrays
- only with static arrays and tuples.
Unless you add a dynamic bound check as when accessing a dynamic array
item, something like:
auto t = expr; assert (t.lenght == 4); auto a = t[0]; auto b = t[1];
auto c = t[2]; auto d = t[3];
I like the idea of having exact match approach and the explicit syntax
for getting the rest as Brad said. But in all the years I used Python,
I never needed that syntax, maybe because most of the times when I use
the tuple expansion I know the size or I want to truncate, or I use
something to generate the data, like split(), that takes an extra
parameter to do that:
l = [1, 2, 3]
a, b, c = l # known lenght
a, b = l[:2] # truncation (like l[0..2] in D)
a, b = '1,2,3'.split(',', 1) # get the rest in b (but it will be a string)
car, cdr = l[0], l[1:] # just a little more verbose
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
--
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
--
careful to all animals (never washing spiders down the plughole),
keep in contact with old friends (enjoy a drink now and then),
will frequently check credit at (moral) bank (hole in the wall),
Re: Tuple assignment
Walter Bright napisał: If expr represents a tuple, we (Andrei and I) were thinking about the syntax: auto (a, b, c, d) = expr; being equivalent to: auto t = expr; auto a = t[0]; auto b = t[1]; auto c = t[2 .. $]; Typo? If not, what is 'd'? Either way, I'd like mismatching tuple lengths to fail, not assign the tail to the last variable. Or, as pelle brought up: auto (a, b..., c) = expr, where b = expr[1..2] and you may have only one ... in the lhs. It's not bad. You can also do this with arrays, such that: float[3] xyz; auto (x, y, z) = xyz; The Lithpers among you will notice that this essentially provides a handy car,cdr shortcut for tuples and arrays: auto (car, cdr) = expr; Nice. It's all nice but as my colleague once said: put it on the todo list right after 'learn Portugese'. -- Tomek
Re: Tuple assignment
Juanjo Alvarez:
Python has the special symbol _ which is used exactly as
a no-op (you could call it foo it you wanted, but _
doesn't create new memory assignments) so you can expand
arbitrary tuples without creating new symbols:
a, b, c, _ = ('tuple', 'of', 'three')
This is false both in Python2 and Python3.
In Python3 there is the syntax:
a, *bc = ('tuple', 'of', 'three')
That's semantically similar to the proposed D syntax:
auto record(a, bc...) = record('tuple', 'of', 'three')
Bye,
bearophile
Re: Tuple assignment
On Thu, 07 Oct 2010 15:14:12 -0400, bearophile
bearophileh...@lycos.com wrote:
This is false both in Python2 and Python3.
What is exactly false on what I said?
a, *bc = ('tuple', 'of', 'three')
Yes, that's the syntax for assignment of the remainder, I was
speaking about *ignoring* the remainder without having it assigned to
the last element which was one of the proposed effects in the message
before mine's.
