c[:]()

[Warren Stringer]

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

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

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?