Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Python > Pythonification of the asterisk-based collection packing/unpacking syntax

Reply
Thread Tools

Pythonification of the asterisk-based collection packing/unpacking syntax

 
 
Eelco
Guest
Posts: n/a
 
      12-28-2011
On Dec 28, 12:07*am, Steven D'Aprano <steve
(E-Mail Removed)> wrote:
> On Mon, 26 Dec 2011 13:51:50 -0800, Eelco wrote:
>
> [...]
>
> >> If your point is that parens are used more often than
> >> packing/unpacking, that's almost certainly true, since function calls
> >> (including method invocations) are so prevalent in pretty much any
> >> code. But what does that prove?

>
> > That proves the original point of contention: that the below* is
> > suboptimal language design,

>
> Well duh.


This is where the referee should interrupt you for snipping someones
citation right before a 'but'

> I was mocking the idea that the meaning of * is context-dependent is a
> bad thing by pointing out that we accept context-dependent meaning for
> round brackets () without any difficulties. Of course it is "suboptimal
> language design" -- it couldn't fail to be. Context-dependency is not
> necessarily a bad thing.


You know, so you dont end up simply restating my point while trying to
make it seem like you disagree.

> > not because terseness always trumps
> > verbosity, but because commonly-used constructs (such as parenthesis or
> > round brackets or whatever you wish to call them)

>
> Parentheses are not a construct. They are symbols (punctuation marks)
> which are applied to at least three different constructs: grouping,
> function calls, class inheritance lists.


Parenthesis encompass a class of constructs. Happy now?

> > are more deserving of
> > the limited space in both the ascii table and your reflexive memory,
> > than uncommonly used ones.

>
> Right. And since sequence packing and unpacking is a common idiom, it
> deserves to be given punctuation. That's my opinion.


Its a valid opinion. But if we are going to be quantitative about
terms such as 'common', you know that there will be at least an order
of magnitude difference between these constructs in commonality, if
not two. Thats what makes your example a poor one. If you could
verbosify a construct of the same commonality and arrive at equally
absurd code, you would have a point.
 
Reply With Quote
 
 
 
 
Eelco
Guest
Posts: n/a
 
      12-28-2011
On Dec 28, 2:11*am, Rick Johnson <(E-Mail Removed)> wrote:
> On Dec 27, 5:10*pm, Steven D'Aprano <steve
>
> (E-Mail Removed)> wrote:
> > On Sun, 25 Dec 2011 07:47:20 -0800, Eelco wrote:
> > Your original use-case, where you want to change the type of tail from a
> > list to something else, is simply solved by one extra line of code:

>
> > head, *tail = sequence
> > tail = tuple(tail)

>
> i wonder if we could make this proposal a bit more "Pythonic"? Hmm...
>
> head, tuple(tail) = sequence
>
> ...YEP!


That has been considered; it was my first thought too, but this
requires one to break the symmetry between collection packing and
unpacking.
 
Reply With Quote
 
 
 
 
Eelco
Guest
Posts: n/a
 
      12-28-2011
On Dec 28, 8:08*am, Chris Angelico <(E-Mail Removed)> wrote:
> On Wed, Dec 28, 2011 at 5:25 PM, Steven D'Aprano
>
>
>
>
>
>
>
>
>
> <(E-Mail Removed)> wrote:
> > On Wed, 28 Dec 2011 15:06:37 +1100, Chris Angelico wrote:

>
> >> ... suppose you have a huge
> >> set/frozenset using tuples as the keys, and one of your operations is to
> >> shorten all keys by removing their first elements. Current Python
> >> roughly doubles the cost of this operation, since you can't choose what
> >> type the tail is made into.

>
> > The First Rule of Program Optimization:
> > - Don't do it.

>
> > The Second Rule of Program Optimization (for experts only):
> > - Don't do it yet.

>
> > Building syntax to optimize imagined problems is rarely a good idea. The
> > difference between 2 seconds processing your huge set and 4 seconds
> > processing it is unlikely to be significant unless you have dozens of
> > such huge sets and less than a minute to process them all.

>
> > And your idea of "huge" is probably not that big... it makes me laugh
> > when people ask how to optimize code "because my actual data has HUNDREDS
> > of items!". Whoop-de-doo. Come back when you have a hundred million
> > items, then I'll take your question seriously.

>
> > (All references to "you" and "your" are generic, and not aimed at Chris
> > personally. Stupid English language.)

>
> And what you're seeing there is the _best possible_ situation I could
> think of, the strongest possible justification for new syntax.
> Granted, that may say more about me and my imagination than about the
> problem, but the challenge is open: Come up with something that
> actually needs this.
>
> ChrisA


I personally feel any performance benefits are but a plus; they are
not the motivating factor for this idea. I simply like the added
verbosity and explicitness, thats the bottom line.
 
Reply With Quote
 
Lie Ryan
Guest
Posts: n/a
 
      12-28-2011
On 12/28/2011 11:08 PM, Eelco wrote:
> I personally feel any performance benefits are but a plus; they are
> not the motivating factor for this idea. I simply like the added
> verbosity and explicitness, thats the bottom line.


Any performance benefits are a plus, I agree, as long as it doesn't make
my language looks like Perl. Now get off my lawn!

 
Reply With Quote
 
Eelco
Guest
Posts: n/a
 
      12-29-2011
On Dec 28, 11:29*pm, Lie Ryan <(E-Mail Removed)> wrote:
> On 12/28/2011 11:08 PM, Eelco wrote:
>
> > I personally feel any performance benefits are but a plus; they are
> > not the motivating factor for this idea. I simply like the added
> > verbosity and explicitness, thats the bottom line.

>
> Any performance benefits are a plus, I agree, as long as it doesn't make
> my language looks like Perl. Now get off my lawn!


Im no perl expert, but it says on the wikipedia page a common
criticism is its overuse of otherwise meaningless special characters;
and I would agree; I puked a little in my mouth looking at the code
samples.

I would argue that the use of single special characters to signal a
relatively complex and uncommon construct is exactly what I am trying
to avoid with this proposal.
 
Reply With Quote
 
Steven D'Aprano
Guest
Posts: n/a
 
      12-29-2011
On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:

> I would argue that the use of single special characters to signal a
> relatively complex and uncommon construct is exactly what I am trying to
> avoid with this proposal.


This would be the proposal to change the existing

head, *tail = sequence

to your proposed:

head, tail:: = ::sequence

(when happy with the default list for tail), or

head, tail::tuple = ::sequence

to avoid an explicit call to "tail = tuple(tail)" after the unpacking.

Either way, with or without an explicit type declaration on the left hand
side, you are increasing the number of punctuation characters from one to
four. If your aim is to minimize the number of punctuation characters,
you're doing it wrong.


--
Steven
 
Reply With Quote
 
Eelco
Guest
Posts: n/a
 
      12-29-2011
On Dec 29, 2:23*pm, Steven D'Aprano <steve
(E-Mail Removed)> wrote:
> On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
> > I would argue that the use of single special characters to signal a
> > relatively complex and uncommon construct is exactly what I am trying to
> > avoid with this proposal.

>
> This would be the proposal to change the existing
>
> * * head, *tail = sequence
>
> to your proposed:
>
> * * head, tail:: = ::sequence
>
> (when happy with the default list for tail), or
>
> * * head, tail::tuple = ::sequence
>
> to avoid an explicit call to "tail = tuple(tail)" after the unpacking.
>
> Either way, with or without an explicit type declaration on the left hand
> side, you are increasing the number of punctuation characters from one to
> four. If your aim is to minimize the number of punctuation characters,
> you're doing it wrong.
>
> --
> Steven


The goal is not to minimize the number of (special) characters to
type. To goal is to minimize the number of special characters which
are hard to interpret at a glance. I would prefer : over ::, but both
are a single special character construct. Adding those characters once
more on the rhs is similarly, not an increase in the number of
concepts employed; merely a more explicit form of the same construct.

And besides, I dont much like 'head, tail:: = ::sequence'. I threw
that out there to appease the terseness advocates, but to me it
largely defeats the purpose, because indeed it is hardly any different
from the original. I like the explicit mentioning of the collection
type to be constructed; that is what really brings it more towards
'for line in file' explicit obviousness to my mind.
 
Reply With Quote
 
Lie Ryan
Guest
Posts: n/a
 
      12-29-2011
On 12/30/2011 12:23 AM, Steven D'Aprano wrote:
> On Thu, 29 Dec 2011 03:55:14 -0800, Eelco wrote:
>
>> I would argue that the use of single special characters to signal a
>> relatively complex and uncommon construct is exactly what I am trying to
>> avoid with this proposal.

>
> This would be the proposal to change the existing
>
> head, *tail = sequence
>
> to your proposed:
>
> head, tail:: = ::sequence
>
> (when happy with the default list for tail), or
>
> head, tail::tuple = ::sequence
>
> to avoid an explicit call to "tail = tuple(tail)" after the unpacking.
>
> Either way, with or without an explicit type declaration on the left hand
> side, you are increasing the number of punctuation characters from one to
> four. If your aim is to minimize the number of punctuation characters,
> you're doing it wrong.


Another drawback of it is that it looks misleadingly similar to C++
namespace notation.

 
Reply With Quote
 
alex23
Guest
Posts: n/a
 
      01-03-2012
On Dec 27 2011, 8:01*pm, Eelco <(E-Mail Removed)> wrote:
> But I consider it a reasonable change for a
> 'python 4', or whatever the next major version change will be called.


You do realise there were 8 years between 2 & 3? You might be waiting
for quite some time.

Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
I sure it's progressing nicely given how long Rick has been talking it
up.

> Writing a code-conversion tool to convert from *args to args::tuple
> would be quite easy indeed.


You might want to ask people maintaining libraries in both 2.x & 3.x
via 2to3 just how well that's working out for them. If the impact of
changes was trivially obvious, the programming landscape would look
very different indeed.

 
Reply With Quote
 
Rick Johnson
Guest
Posts: n/a
 
      01-03-2012
On Jan 2, 8:38*pm, alex23 <(E-Mail Removed)> wrote:

> Conversely, you could pitch in behind Rick Johnson's Python 4000 fork,
> I sure it's progressing nicely given how long Rick has been talking it
> up.


It's NOT a fork Alex. It IS in fact the next logical step in Python's
future evolution.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
create collection of collection Hemant ASP .Net 1 10-22-2009 03:04 PM
Collection problems (create Collection object, add data to collection, bind collection to datagrid) Řyvind Isaksen ASP .Net 1 05-18-2007 09:24 AM
Sorting the Collection(java.util.Collection) of Elements Pradeep Java 2 01-24-2007 02:33 PM
Adding to collection from controlDesigner only produces end tag for the collection. Don ASP .Net Building Controls 0 07-22-2005 09:31 PM
STL - an algorithm for finding a collection within a collection? Dylan C++ 5 03-22-2005 01:31 AM



Advertisments