RE: c[:]()

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?


.

Relevant Pages

  • Re: c[:]()
    ... worried about saving keystrokes, yet you use cinstead of c. ... cholds many behaviors that change dynamically. ... visual music performance. ... So c can contain wrapped MIDI events ...
    (comp.lang.python)
  • Re: c[:]()
    ... cholds many behaviors that change dynamically. ... I've absolutely no clue what that sentence means. ... visual music performance. ... So c can contain wrapped MIDI events ...
    (comp.lang.python)