Re: c[:]()

Warren Stringer wrote:
c[:] holds many behaviors that change dynamically.
I've absolutely no clue what that sentence means. If c[:] does
behave differently than c, then somebody's done something
seriously weird and probably needs to be slapped around for
felonious overriding.

I'm still a bit new at this, was wondering why c[:]() doesn't work, and
implicitly wondering why it *shouldn't* work.

So c[:]() -- or the more recent go(c)() -- executes all those
behaviors.

No it doesn't. See below.


Oops meant to say do(c)(), not "go", which matches a prior post.

Still no clue.

This is very useful for many performers.
What are "performers"?

Real people, like musicians, and their proxies in code that passes around
real-time events that may be rendered, recorded, and played back.

The real world example that I'm working one is a collaborative
visual music performance. So c can contain wrapped MIDI events
or sequencer behaviors. c may get passed to a scheduler to
execute those events, or c may get passed to a pickler to
persist the performance.
I still don't see how c[:] is any different from c.

It isn't. The OP is projecting a wish for a function call on a list to
be interpreted as a call on each member of the list with the same
arguments. The all-members slice notation is a complete red herring.

Just looked up "red herring wiki" hope I wasn't being misleading -- at least
not intentionally. c[:] is the simplest case for a broad range of behaviors.
Perhaps, I should have said c[selector()]() ??? but, no, that makes the
question more complex ... still

It would require a pretty fundamental re-think to give such a construct
sensible and consistent semantics, I think.

What do you mean?

If c[:]() works, the so does this, using real world names
orchestra[:].pickle()
orchestra[conductor()].sequence()

Though, I'm already starting to prefer:

do(orchestra).pickle() do(orchestra(conductor)).sequence()

Yes, dammit, but c[:]() *DOESN'T WORK* unless you have made some pretty crufty changes to the underlying object.

Perhaps, this is what you mean by "sensible and consistent semantics"

I just read Alex Martelli's post in the "rats! Varargs" thread about how
list and tupples are implemented. I want to understand implementation before
suggesting changes. Maybe c[:]() isn't so simple to fix, after all?


This is what I'm having difficulty understanding. You said, in your original post (which, by the way, hijacked another thread about something completely different):

I want to call every object in a tupple, like so:

[By the way, that's "tuple", not "tupple"]
#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)

>>>c[:]() # i wanna
TypeError: 'tupple' object is not callable

>>>c[0]() # expected
a
>>>c[:][0] # huh?
a

This is what I just don't believe. And, of course, the use of "tupple" above tells us that this *wasn't" just copied and pasted from an interactive session.

>>> [i() for i in c] # too long and ...huh?
a
b
[None,None]
#------------------------------------------
This is also clearly made up.

In a later email you say:

why does c[:][0]() work but c[:]() does not?

The reason for this is that c[:][0] is a function, a single item from a tuple of functions. c[:], however, is a tuple of functions, and cannot be called as a function itself. No matter how much you would like it to be. Python's chief virtue is obviousness, and this behavior would be very non-obvious. You also don't explain when Python should do if you happen to have something other than a function (say a string or a floating-point number) in the tuple.

You also said:

Why does c[0]() has exactly the same results as c[:][0]() ?

The reason for this is that c is exactly the same as c[:]. The slicing notation "[:]" tells the interpreter to use a tuple consisting of everything in the tuple to which it's applied. Since the interpreter knows that tuples are immutable (can't be changed), it just uses the same tuple -- since the immutability there's no way that a difference could arise between the tuple and a copy of the tuple, Python doesn't bother to make a copy.

This behavior is *not* observed with lists, because lists are mutable.

I realise you are trying to find ways to make Python more productive for you, and there's nothing wrong with that. But consider the following, which IS copied and pasted:

>>> def a():
.... print "A"
....
>>> def b():
.... print "B"
....
>>> c = (a, b)
>>> c
(<function a at 0x7ff4f764>, <function b at 0x7ff4f64c>)
>>> c[:]
(<function a at 0x7ff4f764>, <function b at 0x7ff4f64c>)
>>> c[0]()
A
>>> c[1]()
B
>>> c()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object is not callable
>>> c[:]()
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
TypeError: 'tuple' object is not callable
>>>

I think the fundamental mistake you have made is to convince yourself that

c[:]()

is legal Python. It isn't, it never has been.

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 ----------------

.

Relevant Pages

  • Re: why cannot assign to function call
    ... I'm going to follow up here at the risk of annoying Mark, ... helpful in explaining things to Python beginners. ... it becomes a namespace mapping names to objects. ... to the list itself, while Steven held that Python lists ...
    (comp.lang.python)
  • python-dev Summary for 2003-10-16 through 2003-11-15
    ... This is the twenty-eighth and twenty-ninth summaries written by Brett ... The in-development version of the documentation for Python can be found ... If you have ever wanted to see linked lists used in Python in a rather ... Contributing threads: ...
    (comp.lang.python)
  • TOC of Python Cookbook now online (was Re: author index for Python Cookbook 2?)
    ... Processing a String One Character at a Time ... Finding a File on the Python Search Path ... Constructing Lists with List Comprehensions ... Looping over Items and Their Indices in a Sequence ...
    (comp.lang.python)
  • chapter4
    ... The for statement in Python differs a bit from what you may be used to ... list or a string), in the order that they appear in the sequence. ... (this can only happen for mutable sequence types, such as lists). ... The keyword def introduces a function definition. ...
    (Ubuntu)
  • Re: More pythonic shell sort?
    ... So I decided to tackle this old school problem with the python mindset. ... for gap in self.gapSeq: ... I didn't really think of pop and insert as advanced features. ... that they are python lists, ...
    (comp.lang.python)