c[:]()

[Erik Max Francis]

Warren Stringer wrote:

> As mentioned a while back, I'm now predisposed towards using `do(c)()`
> because square brackets are hard with cell phones. The one mitigating factor
> for more general use, outside of cell phones, is speed.

The speed at which you can type code is almost _never_ a valid reason to 
make something brief.  Code gains readability from verbosity.  (That can 
be taken too far, of course, but that certainly doesn't apply here.)

Either way, something like `do(c)()` to do what you want is easily 
implementable in Python, and always has been.  Same thing with your 
`c()` or `c[:]()` solutions (though the latter makes no semantic sense); 
just use custom sequence types.

> The questions about implementing a working c[:]() are:
> 	1) Does it break anything?
> 	2) Does it slow anything down?
> 	3) Could it speed anything up?
> 	4) Does it make code easier to read?
>  	5) What question(s) did I forget to ask?

You keep sticking the slice in there.  That still makes no sense.

The fundamental reason it does not make logical sense to make a list 
callable (which would then call its elements) is that lists can contain 
objects that aren't callable.  So then, if you want lists to be 
callable, the question becomes, what should it do with the elements that 
aren't callable?  Choke on the first one?  Ignore them?  Abort entirely 
and not call any of them?

This kind of a design question can go every possible way depending on 
what particular application you're using the calling syntax for, so the 
proper design question from a language perspective is not to choose any. 
  If you want a callable sequence (which calls its elements and has any 
or all of the above behaviors), it is _trivial_ to make one.  There is 
no need for support for this, because what it should do is not clear.

> I use `c[:]()` because it is unambiguous about using a container

There are containers that don't support slicing (a stack, for instance), 
so you're not using the right terminology here.  If you do mean general 
containers, then your slicing violates duck typing since it effectively 
enforces a constraint that may not be desired.  _If_ one were to have 
callable containers, then callable containers should be usable in _any_ 
context in which an object is called, not just ones where slices were done.

If you intend `c[:]()` to have different semantics than `c()` -- it 
isn't clear from your comments whether you mean it to or not, but you 
keep nonsensically mentioning the slicing notation -- then you're 
_really_ out in left field.  Now that requires operations to behave 
differently in different contexts, which is a huge can of worms and 
rapidly makes code unreadable.

In short, your repeated use of `c[:]()` indicates a fundamental 
misunderstanding about Pythonic style _and_ substance.

>> If you're not willing to do that, but still insisting that `c[:]()`
>> makes sense, then perhaps it would be more advisable to learn more about
>> Python rather than try to suggest profound changes to the language and
>> its conventions.
> 
> You're right. At the same time, version 3 is coming up soon. There is a
> short window of opportunity for profound changes. 

Soon isn't all that soon.  Furthermore, it is very unlikely that someone 
is going to be able to suggest profound and useful changes to Python 
without first being familiar with it.  So stabbing in the dark is not 
going to be very constructive for either learning Python, or suggesting 
useful improvements.  That's just the way the ball bounces, unfortunately.

-- 
Erik Max Francis && max at alcyone.com && http://www.alcyone.com/max/
  San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
   To endure what is unendurable is true endurance.
    -- (a Japanese proverb)