Pythonification of the asterisk-based collection packing/unpacking syntax

[Ian Kelly]

On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:

[...]

so unless you're opposed to using an editor more
advanced than Notepad, you'll type in "varargs", it'll turn purple or
whatever, and you'll go "oh that's a keyword."

Not everybody uses editors more advanced than Notepad. Even those who do
may not have an editor that understands Python keywords, or has an
obsolete list of keywords (my editor of choice doesn't know about
NotImplementedError).

Probably because NotImplementedError is not a keyword.

 

[Steven D'Aprano]

On Sun, 18 Dec 2011 13:47:46 -0600, Evan Driscoll wrote:

[...]

so unless you're opposed to using an editor more advanced than
Notepad, you'll type in "varargs", it'll turn purple or whatever, and
you'll go "oh that's a keyword."

Not everybody uses editors more advanced than Notepad. Even those who
do may not have an editor that understands Python keywords, or has an
obsolete list of keywords (my editor of choice doesn't know about
NotImplementedError).

Probably because NotImplementedError is not a keyword.

Poor choice of words on my part. My editor colours built-ins like
ValueError, TypeError, len, sum, etc., but not NotImplementedError.

 

[Chris Angelico]

Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
constraint. I propose that:

   args = @set list(args)

Will coerce args into a list and then give me a set in return.

Point to note:

list,set = set,list # Request a death sentence from the next maintainer

is perfectly legal code. Now, what does your "args=" line do?

ChrisA

 

[Eelco]

And if you _did_, then one of the first lines in your function would
be:

    args = list(args)

Which is obvious to everyone, doesn't modify existing behaviour,
doesn't force everyone without a fetish for change to add unnecessary
cruft to their function signature...

Its obvious you end up with a list (assuming args is an iterable);
knowing what args was to begin with suffers from the same problems.

Except, OMG, list() is RETURNING A LIST, which is an OBVIOUS type
constraint. I propose that:

    args = @set list(args)

Will coerce args into a list and then give me a set in return.

?
What does that have to do with collection packing/unpacking?

 

[Eelco]

+1. I will second that! Eelco has the CORRECT idea, but the WRONG
syntax!

Thanks, your opinion is noted.

Personally im impartial between identifier::collectiontype and
identifier@collectiontype, but that order is something I think is
rather important.

Having two seperate symbols seperated by whitespace, as in @list args
strikes me as a terrible break of normal python lexical rules. Plus,
identifier@collectiontype as a collection-type annotation would be
consistent with the existing general function annotation syntax. Many
non-C-family languages postfix the type declaration.

Also, we want to use the same symbol for collection unpacking as we
use for collection packing. Saying foo(@argslist) really does look a
tad much like a decorator, even though it can be unambigiously
distinguished from it by context.

 

[Andrew Berg]

And they have no excuse for NOT using a better one. Well, except for a
"foolish consistency" that is!

But what about the example he gave about being logged into a customer's
machine with only ed available? I suppose such fools would not be worthy
of your business.

 

[Roy Smith]

But what about the example he gave about being logged into a customer's
machine with only ed available? I suppose such fools would not be worthy
of your business.

The customer is always right. Especially when the support contract is
big enough to make or break your quarter.

 

[Andrew Berg]

Sorry, I wasn't meaning to imply support for the syntax proposal. Just
reacting to the (seemingly unrelated) comment that a customer with
foolish access policies would not be worthy of your business.

It was directed at Rick, and by "your", I was referring to him
specifically, as that is the kind of attitude I might expect him to show.

 

[alex23]

What does that have to do with collection packing/unpacking?

It's mocking your insistance that collection unpacking is a type
constraint.

 

[alex23]

Point to note:

list,set = set,list  # Request a death sentence from the next maintainer

is perfectly legal code. Now, what does your "args=" line do?

ChrisA

Why are you directing this at my mocking of the OPs idea when the same
issue is present in his proposal?

 

[alex23]

Having two seperate symbols seperated by whitespace, as in @list args
strikes me as a terrible break of normal python lexical rules.

You mean like 'is not'? And the upcoming 'yield from'?

 

[alex23]

But what about the example he gave about being logged into a customer's
machine with only ed available? I suppose such fools would not be worthy
of your business.

Do you mean directly editing the source code on a production machine?
Because that's pretty much the only scenario I can come up with where
that's plausible.

If I was doing that, _I_ wouldn't be worth doing business with.

So you only have ssh & ed: at the very least you should be making
changes against your local copy, TESTING THEM, and then copy&paste
directly onto the remote box.

 

[Andrew Berg]

Do you mean directly editing the source code on a production machine?
Because that's pretty much the only scenario I can come up with where
that's plausible.

You'd have to ask Steven D'Aprano; it was his scenario.

 

[Chris Angelico]

Why are you directing this at my mocking of the OPs idea when the same
issue is present in his proposal?

Because it was after reading your post that I saw reason to write
that, and it tied in better with your post than any other. No other
reason.

ChrisA

 

[Steven D'Aprano]

You mean like 'is not'? And the upcoming 'yield from'?

Also "not in".

Space-delimited tokens are hardly rare in Python, e.g.:

import module as name
for x in sequence
if flag
elif condition
while condition
with obj
del name


Nevertheless, I think the suggested syntax "@list args" is awful.

 

[alex23]

Nevertheless, I think the suggested syntax "@list args" is awful.

Yep, and it's the least awful part of the entire proposal.

 

[Serhiy Storchaka]

20.12.11 07:47, Steven D'Aprano напиÑав(ла):

Space-delimited tokens are hardly rare in Python, e.g.:

import module as name
for x in sequence
if flag
elif condition
while condition
with obj
del name

return to_be or not to_be if this is question else None

 

[Steven D'Aprano]

Do you mean directly editing the source code on a production machine?
Because that's pretty much the only scenario I can come up with where
that's plausible.

If I was doing that, _I_ wouldn't be worth doing business with.

So you only have ssh & ed: at the very least you should be making
changes against your local copy, TESTING THEM, and then copy&paste
directly onto the remote box.

Come on guys, you're treating a throw-away example *way* too seriously.

If we're going to hypothesis a customer so insane to only have ed
installed on their system[1], chances are they've specified some crazy
rule like "You May Not Copy Our Precious, Precious Source Code Onto
Another Machine Because That's Copyright Theft". Or whatever. Spend 15
minutes on The Daily WTF and you'll see war stories far more crazy than
that.

The point I was making is that in the real world, sometimes you don't
have the luxury of using the right tool for the job, but have to make do
with whatever you have. Languages shouldn't depend on advanced editor
features or special keyboards -- that way leads to ColorForth and APL.



[1] Possibly because ed is the standard Unix editor.
http://www.gnu.org/fun/jokes/ed.msg.html

 

[Neal Becker]

Clarification: where can packing/unpacking syntax be used?

It would be great if it were valid essentially anywhere (not limited to
parameter passing).

What about constructs like:

a, @tuple tail, b = sequence?

 

[Ethan Furman]

Clarification: where can packing/unpacking syntax be used?

It would be great if it were valid essentially anywhere (not limited to
parameter passing).

What about constructs like:

a, @tuple tail, b = sequence?

You mean like Python 3's:

a, *middle, b = sequence

?