c[:]()

[Grant Edwards]

On 2007-06-01, Warren Stringer <warren at muse.com> wrote:

> As mentioned a while back, I'm now predisposed towards using
> `do(c)()` because square brackets are hard with cell phones.

Yet you insist on adding gratuitous instances of [:] in your
code.  Methinks you're being disingenuous.

> The one mitigating factor for more general use, outside of
> cell phones, is speed. If a PEP enables a much faster solution
> with c[selector()]() then it may be worthwhile. But, I feel a
> bit circumspect about suggesting a change as I haven't looked
> at Python source, nor have I looked at the BNF, lately. I
> think Martelli's recent post on implantation may be relevant:
>
>> Tuples are implemented as compact arrays of
>> pointer-to-PyObject (so are lists, BTW).  So, for example, a
>> 10-items tuple takes 40 bytes (plus a small overhead for the
>> header) on a 32-bit build, not 80 as it would if implemented
>> as a linked list of (pointer-to-object, pointer-to-next)
>> pairs; addressing sometuple[N] is O(1), NOT O(N); etc, etc.
>
> The questions about implementing a working c[:]() are:

Again, _why_ the [:] ???

> 	1) Does it break anything?

Not if you do it in a class of your own.

> 	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?
>
> 1) No? The fact that c() currently fails on a container
>    implies that enabling it would not break existing client
>    code.

No, it doesn't.  I can think of several cases where somebody
might depend on the fact that lists and tuples are not
callable.  It's quite common in Python to write a function that
accepts a variety of argument types (e.g. accepting either a
file object or a file name).  It's not unimaginable that
somebody might write a fuction that will accept either a
function or a list and expect that a list isn't callable.

[Please quit saying "a container" if you mean lists and tuples.
"A container" is way too general.  There most probably _are_
containers for which c() does not fail.]

> Would this break the language definition?

That depends on what you mean by "a container".  If it's a
container class that you or somebody else wrote, then no, it
doesn't break the language definition.  If you mean the builtin
list or tuple types, then yes, it breaks the language
definition because the language is currently defined such that
lists and tuples aren't callable.

> A couple years ago, I hand transcribed the BNF of version 2.2
> to an alternative to BNF. I would love to know if c[:]() would
> break the BNF in a fundamental way. 

No, the syntax is fine.  It's just that the containers you seem
to have chosen don't do what you want.  

For pete's sake, use one that does.

> 2) I don't know. I've always assumed that Python objects are
>    hash table entries. How would this change? Would it change?
>    Does the message "TypeError: 'list' object is not callable"
>    guarantee a short path between bytecode and hash table? Is
>    there some other mitigating factor?

I don't see why you think this has to be built into the
language when it would only take a few lines of code to define
such a class.  IIRC, somebody already has.  Your problem has
been solved for you.  The whole point of having user-defined
classes/types is so that the language doesn't have to have
built-in every conceivable data type and behavior that anybody
will ever want.

>> So if you think `c()` and `c[:]()` should do something
>> different in this case, you are profoundly confused about
>> Python's semantics of what objects are, what it means to
>> shallow copy a list, and what it means to make a function
>> call.  That you keep including the slice suggests that there's
>> something about its meaning that's not yet clicking.
>
> I use `c[:]()` because it is unambiguous about using a
> container

That makes no sense.

>> If you really want syntax where a function call on a container
>> calls all of its elements, then that is trivially easy to do
>> by creating such an object and overriding its `__call__`
>> method.
>> 
>> 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. 
>
> Also, my audacious suggestion

The suggestion that containers broadcast a "call" operation
isn't audacious.  It's not going to happen, but there's nothing
wrong with the suggestion.

You just choose to write a lot of audacious nonsense along with
it.

-- 
Grant Edwards                   grante             Yow!  Someone is DROOLING
                                  at               on my collar!!
                               visi.com