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 && [EMAIL PROTECTED] && 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) -- http://mail.python.org/mailman/listinfo/python-list