c[:]()

[Steve Holden]

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. 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:
> 	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?
> 
> 1) No? The fact that c() currently fails on a container implies that
> enabling it would not break existing client code. Would this break the
> language definition? 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. 
> 
> 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?
> 
> 3) Maybe? Does overriding __call__ create any extra indirection? If yes,
> then I presume that `do(c)()` would be slower the `c[:]()`. I am writing
> rather amorphous code. This may speed it up.
> 
> 4) I posit yes. Am I missing something? What idiom does would c[:]() break?
> This correlates with whether `c[:]()` breaks the language definition, in
> question 1)
> 
> 
> Erik Max Francis wrote:
>> Warren Stringer wrote:
>>
>>> I'm still a bit new at this, was wondering why c[:]() doesn't work, and
>>> implicitly wondering why it *shouldn't* work.
>> It does work.  It means "make a sliced copy of `c`, and then call it
>> with no arguments."  Functionally that is _no different_ from `c()`,
>> which means "take `c` and call it with no arguments," because presuming
>> `c` is a list, `c[:]` makes a shallow copy.
>>
>> 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
>  
Unfortunately nothing in your proposal addresses the issue that the 
container object needs to contain only callable objects.

The general rule in Python is that you provide the right objects and 
expect error tracebacks if you do something wrong. So I don't really see 
why you feel it's necessary to "[be] unambiguous about using a 
container" when you don't appear to feel the same about its containing 
only functions.

>> 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. 
> 
Which closed at the end of April as far as PEPs affecting the initial 
implementation of version 3 was concerned. The python3000 and 
python-ideas lists are the correct forum for those issues, though you 
will of course get all sorts of opinions on c.l.py.

> Also, my audacious suggestion has spawned illuminating replies. For this
> instance, I have read about shallow copy, before, but haven't been told
> where it is used, before now. Other posts led to insights about closures,
> and yielding a real solution. This is incredibly useful. I've learned a lot.
> 
That's good.

regards
  Steve
-- 
Steve Holden        +1 571 484 6266   +1 800 494 3119
Holden Web LLC/Ltd           http://www.holdenweb.com
Skype: holdenweb      http://del.icio.us/steve.holden
------------------ Asciimercial ---------------------
Get on the web: Blog, lens and tag your way to fame!!
holdenweb.blogspot.com        squidoo.com/pythonology
tagged items:         del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------