Pythonification of the asterisk-based collection packing/unpacking syntax

[Neal Becker]

I agree with the OP that the current syntax is confusing. The issue is, the
meaning of * is context-dependent.

Why not this:

Func (*args) == Func (unpack (args))

def Func (*args) == Func (pack (args))

That seems very clear IMO

 

[Steven D'Aprano]

I agree with the OP that the current syntax is confusing. The issue is,
the meaning of * is context-dependent.

Here you are complaining about an operator being "confusing" because it
is context-dependent, in a post where you strip all context except the
subject line and expect us to still understand what you're talking about.
There's a lesson there, I'm sure.


* is context dependent. You know what else is context dependent? Well,
most things. But in particular, parentheses. Clearly they must be
"confusing" too. So how about we say:

class MyClass superclasslist A, B C:
def method argumentlist self, x, y:
t = tuple 1, 2 tuple 3, 4 endtuple endtuple
return group x + y endgroup * group x - y endgroup


Much less confusing!

 

[Chris Angelico]

class MyClass superclasslist A, B C:
   def method argumentlist self, x, y:
       t = tuple 1, 2 tuple 3, 4 endtuple endtuple
       return group x + y endgroup * group x - y endgroup


Much less confusing!

A definite improvement. However, I fear that the numerals "1", "2",
etc are far too vague. In some contexts, the abuttal of two such
numerals results in a larger number by a factor of 10, while in
others, the factor is 8, or 16, or 2. This must not be. We need an
unambiguous representation of integers.

Also, I think we should adopt an existing standard [1]. This is
generally a good idea.

class MyClass superclasslist A, B C:
def method argumentlist self, x, y:
t = tuple summer's day, proud pony tuple
sum of honest purse and fellow, large proud town
endtuple endtuple
return product of group sum of x and y endgroup and group
difference between x and y endgroup

You will find this a vast improvement.

ChrisA

[1] http://shakespearelang.sourceforge..../shakespeare.html#SECTION00045000000000000000
or http://tinyurl.com/6sycv

 

[Hans Mulder]

Here you are complaining about an operator being "confusing" because it
is context-dependent, in a post where you strip all context except the
subject line and expect us to still understand what you're talking about.
There's a lesson there, I'm sure.


* is context dependent. You know what else is context dependent? Well,
most things. But in particular, parentheses. Clearly they must be
"confusing" too. So how about we say:

class MyClass superclasslist A, B C:
def method argumentlist self, x, y:
t = tuple 1, 2 tuple 3, 4 endtuple endtuple
return group x + y endgroup * group x - y endgroup


Much less confusing!

How about:

<class name="MyClass" superclasses="A, B, C">
<def name="method" arguments="self, x, y">
<let target="t">
<tuple>
<te>1</te>
<te>2</te>
<te><tuple><te>3</te><te>4</te></tuple></te>
</tuple>
</let>
<return>
<multiply>
<add><var>x</var><var>x</var></add>
<subtract><var>x</var><var>x</var></subtract>
</multiply>
</return>
</def>
</class>

More more readable! And it's a standard!



-- HansM

 

[Chris Angelico]

How about:

<class name="MyClass" superclasses="A, B, C">
...
</class>

More more readable!  And it's a standard!

Unfortunately it's not Pythonic, because indentation is insignificant.
We need to adopt a more appropriate form. Eliminate all the </spam>
tags and use indentation to mark the ends of elements.

ChrisA
PS. Brilliant, sir, brilliant! I take off my cap to you.

 

[Mel Wilson]

Unfortunately it's not Pythonic, because indentation is insignificant.

Easy-peasy:

<def name="method" arguments="self, x, y">
<indent> </indent><let target="t">

Mel.

 

[Eelco]

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

This is really going to be the last time I waste any words on this:

The sentence 'collection unpacking is a type constraint' is entirely
nonsensical. A type constraint is a linguistical construct that can be
applied in many ways; typically, to narrow down the semantics of use
of the symbol to which the type constraint is applied.

In case of python, collection PACKING (not unpacking) is signaled by a
construct that can be viewed as a type constraint. But if you dont
want to fortify your view of the syntax by looking at what it is
actually going on, ill repeat again; lets keep things simple, and not
analyze it in detail.

So here it is again, in terms every 5 year old can understand. Id like
to do the exact same thing python is already doing. Except with a few
more, and different symbols, to enable one to express a few different
variants of behavior. Clear enough?

 

[Eelco]

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

Im not sure why, but this feels like something entirely different to
me.

I suppose because these are compositions of keywords. Can you give an
example of a whitespaced composition of identifiers being a valid
construct anywhere else in Python?

 

[Eelco]

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.

Can you give an example of a construct in python where two whitespace
delimited identifiers are legal?

 

[Eelco]

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?

This has come up many times in the thread, including in my OP. More
closely unifying collection packing/unpacking is part of my goal, so
indeed, I would like to be able to write something like:

a, middle::tuple, b = ::sequence

Where I would like the extra :: before the sequence to explicitly
signal collection unpacking on the rhs, to maintain the symmetry with
collection unpacking within a function call.

 

[Eelco]

Here you are complaining about an operator being "confusing" because it
is context-dependent, in a post where you strip all context except the
subject line and expect us to still understand what you're talking about.
There's a lesson there, I'm sure.

* is context dependent. You know what else is context dependent? Well,
most things. But in particular, parentheses. Clearly they must be
"confusing" too. So how about we say:

class MyClass superclasslist A, B C:
    def method argumentlist self, x, y:
        t = tuple 1, 2 tuple 3, 4 endtuple endtuple
        return group x + y endgroup * group x - y endgroup

Much less confusing!

Context dependence is not something to be avoided at all costs, but
all else being equal, less is certainly more. The general concept of
grouping thing together which parenthesis is an extremely pervasive
one in programming, and thus deserves its own set of context-dependent
rules. Packing and unpacking collections is far, far more rare, and
thus a form that requires you to write more but remember less is
certainly relatively favorable.

 

[Chris Angelico]

a, middle::tuple, b = ::sequence

Then it ought to be

:a, middle::tuple, b) = ::sequence

or something, because you're doing the same thing on both sides.

ChrisA

 

[Chris Angelico]

Can you give an example of a construct in python where two whitespace
delimited identifiers are legal?

What do you mean? Two identifiers, separated only by whitespace and no
keyword or operator?

def foo():
asdf
qwer

Perfectly legal, two statements that probably don't do anything useful though.

ChrisA

 

[Eelco]

Then it ought to be

:a, middle::tuple, b) = ::sequence

or something, because you're doing the same thing on both sides.

ChrisA

Thats a fair point; something to think about. It all depends on how
you define the rules of course; im trying to stay as close as possible
to the original python rules, where the (un)packing of comma-seperated
identifiers is implicit. Probably best to keep it that way, from the
looks of it .

 

[Eelco]

What do you mean? Two identifiers, separated only by whitespace and no
keyword or operator?

def foo():
    asdf
    qwer

Perfectly legal, two statements that probably don't do anything useful though.

ChrisA

Thats not a fair point, but more nitpicking. Yes, I should have been
more precise: in python, 'whitespace' is not a single beast like in
most languages, but newlines have a special meaning. I was obviously
not talking about those. Want to try again?

 

[Chris Angelico]

Thats not a fair point, but more nitpicking. Yes, I should have been
more precise: in python, 'whitespace' is not a single beast like in
most languages, but newlines have a special meaning. I was obviously
not talking about those. Want to try again?

In that case I can't think of any, but at least now you've clarified
the question (by not denying the rest of it). It was somewhat
ambiguous.

ChrisA

 

[alex23]

This is really going to be the last time I waste any words on this

Oh hey, don't feel you actually have to justify the bullshit you're
talking for my sake.

In case of python, collection PACKING (not unpacking) is signaled by a
construct that can be viewed as a type constraint.

_But no one does view it that way because it isn't_. No more so than
[] taking a string separated list of arguments and return a list is a
type constraint. _That's it's behaviour_.

We have a language construct that returns a tuple, because in the
context of what tuples are in Python, that makes sense. There are
_plenty_ of such constructs. You have still yet to show what adding
all of this ridiculous shit to a function signature provides that
coercing the resulting tuple to your own type doesn't.

So here it is again, in terms every 5 year old can understand. Id like
to do the exact same thing python is already doing. Except with a few
more, and different symbols, to enable one to express a few different
variants of behavior. Clear enough?

That you're a condescending douchebag with nothing of value to
contribute?

Crystal.

 

[Rick Johnson]

That you're a condescending douchebag with nothing of value to
contribute?

Crystal.

Take it from me Eelco. Once Alex drops into your thread and starts
name calling, it's over my friend.

 

[Steven D'Aprano]

Context dependence is not something to be avoided at all costs, but all
else being equal, less is certainly more. The general concept of
grouping thing together which parenthesis is an extremely pervasive one
in programming, and thus deserves its own set of context-dependent
rules. Packing and unpacking collections is far, far more rare,

Not in Python, where it is a very common idiom.

and thus
a form that requires you to write more but remember less is certainly
relatively favorable.

Not in Python, where iteration is a fundamental idiom and packing/
unpacking is a basic syntax construct precisely because the designer of
the language expects it to be common and encourages its use. There are
built-in functions designed to be used with unpacking operations, e.g.
enumerate and zip:

for i, obj in enumerate(sequence): ...
for a, b in zip(obj, range(100)): ...

 

[Steven D'Aprano]

Can you give an example of a construct in python where two whitespace
delimited identifiers are legal?

Not apart from the trivial case of two identifiers separated by newlines.

What's your point?