Warren said:
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.
