Ellipsis (...) to be roughly synonymous with *<varname> in destructuring but without capture.
This is based on previous discussions of possible ways of matching all remaining items during destructuring but without iterating of remaining final items. This is not exactly a direct replacement for that idea though, and skipping iteration of final items might or might not be part of the goal. In this proposal, the ellipsis (...) can be used in the expression on the left side of the equals sign in destructuring anywhere that `*<varname>` can appear and has approximately the same meaning. The difference is that when the ellipsis is used, the matched items are not stored in variables. This can be useful when the matched data might be very large. ..., last_one = <expression> a, ..., z = <expression> first_one, ... = <expression> Additionally, when the ellipsis comes last and the data is being retrieved by iterating, stop retrieving items since that might be expensive and we know that we will not use them. Alternative A: Still iterate over items when the ellipsis comes last (for side effects) but introduce a new `final_elipsis` object that is used to stop iteration. The negation of `ellipsis` (e.g. `-...`) could return `final_ellipsis` in that case. Alternative B: Still iterate over items when the ellipsis comes last (for side effects) and don't provide any new means of skipping iteration over final items. The programmer can use islice to achieve that.
Steve Jorgensen wrote:
This is based on previous discussions of possible ways of matching all remaining items during destructuring but without iterating of remaining final items. This is not exactly a direct replacement for that idea though, and skipping iteration of final items might or might not be part of the goal. In this proposal, the ellipsis (...) can be used in the expression on the left side of the equals sign in destructuring anywhere that `*<varname>` can appear and has approximately the same meaning. The difference is that when the ellipsis is used, the matched items are not stored in variables. This can be useful when the matched data might be very large. ..., last_one = <expression> a, ..., z = <expression> first_one, ... = <expression> Additionally, when the ellipsis comes last and the data is being retrieved by iterating, stop retrieving items since that might be expensive and we know that we will not use them. Alternative A: Still iterate over items when the ellipsis comes last (for side effects) but introduce a new `final_elipsis` object that is used to stop iteration. The negation of `ellipsis` (e.g. `-...`) could return `final_ellipsis` in that case. Alternative B: Still iterate over items when the ellipsis comes last (for side effects) and don't provide any new means of skipping iteration over final items. The programmer can use islice to achieve that.
Correction: "are not stored in variables" should say "are not stored in a variable"
On Thu, 23 Jun 2022 at 08:56, Steve Jorgensen <stevecjor@gmail.com> wrote:
This is based on previous discussions of possible ways of matching all remaining items during destructuring but without iterating of remaining final items. This is not exactly a direct replacement for that idea though, and skipping iteration of final items might or might not be part of the goal.
In this proposal, the ellipsis (...) can be used in the expression on the left side of the equals sign in destructuring anywhere that `*<varname>` can appear and has approximately the same meaning. The difference is that when the ellipsis is used, the matched items are not stored in variables. This can be useful when the matched data might be very large.
..., last_one = <expression> a, ..., z = <expression> first_one, ... = <expression>
Additionally, when the ellipsis comes last and the data is being retrieved by iterating, stop retrieving items since that might be expensive and we know that we will not use them.
Alternative A:
Still iterate over items when the ellipsis comes last (for side effects) but introduce a new `final_elipsis` object that is used to stop iteration. The negation of `ellipsis` (e.g. `-...`) could return `final_ellipsis` in that case.
No need to have an object there - you could just define it as a syntactic construct instead. Assignment targets aren't themselves objects (although the same syntax can often be used on the RHS, when it would resolve to one).
Alternative B:
Still iterate over items when the ellipsis comes last (for side effects) and don't provide any new means of skipping iteration over final items. The programmer can use islice to achieve that.
This is exactly equivalent to using star-underscore, minus the final step of assigning. Not really very advantageous. Having a way to say "allow additional elements without iterating over them" would be useful, but creating a new way to spell the non-assignment wouldn't be of sufficiently great value to justify the syntax IMO. ChrisA
No need to have an object there - you could just define it as a syntactic construct instead. Assignment targets aren't themselves objects (although the same syntax can often be used on the RHS, when it would resolve to one).
Right. Thanks. That _should_ have been obvious. :)
Having a way to say "allow additional elements without iterating over them" would be useful, but creating a new way to spell the non-assignment wouldn't be of sufficiently great value to justify the syntax IMO.
I mostly agree. I included that option for completeness. It would still have the benefit of avoiding the memory usage of creating a list and keeping references to the items until the list itself can be collected. Come to think of it, can (or could) Python already optimize that using current syntax, noticing that the variable assigned to is never used after it is "assigned" to? If that optimization were implemented (I presume it is not implemented now) then there is actually no point to this proposal at all except to allow "..." in final positions in the expression to the left of "=" and to have that mean to not iterate.
participants (2)
-
Chris Angelico -
Steve Jorgensen