"is" and ==

[Grant Edwards]

Re: c[:]()

On 2007-05-31, Steve Holden <steve@holdenwe b.comwrote:

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

Yea, I got that part.

The all-members slice notation is a complete red herring.

That's what I thought, but the OP seems convinced that c[:] is
somehow behaviorally different than c (something more than just
being an exact copy of the list with a different id()).

The only thing I could think of is that he has overridden the
__getitem__ method of the class to which c belongs with
something that has some sort of side-effects which he wishes to
invoke.

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

He could just define a container class that does what he
wants...

--
Grant Edwards grante Yow! Mr and Mrs PED, can I
at borrow 26.7% of the RAYON
visi.com TEXTILE production of the
INDONESIAN archipelago?

[Warren Stringer]

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).p ickle()
do(orchestra(co nductor)).seque nce()

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?

[Douglas Woodrow]

Re: c[:]()

On Thu, 31 May 2007 07:49:22, Warren Stringer <warren@muse.co mwrote

>>def a(): return 'b'
>>def b(): print 'polly! wakey wakey'
>>c = {}
>>c['a'] = b
>>c[a()]() #works!
>
>
>(typo correction for other easily-confused newbies like myself)
>
>I think you mean

[...]

>Hey Douglas,
>
>Perhaps I was being too abstract? Here goes:
>
>,-------------------------------
>| def selector():
>| ...
>| return funcKey #get down get down
>|
>| def func():
>| ...
>| funcSwitch = {}
>| funcSwitch[funcKey] = func
>| ...
>| funcSwitch[selector()]()

Thanks Warren, I was merely pointing out the typing mistake you made in
your first example.

And yes, your abstract names made it difficult to guess the intention of
the original code. With the meaningful names you've just provided, I
can see immediately that you intended to write the 2nd working code
alternative I suggested:

>Oh no, I get it, you meant...
>,----
>| c['b'] = b
>| c[a()]() #works!
>`----

--
Doug Woodrow

[Steve Holden]

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).p ickle()
do(orchestra(co nductor)).seque nce()
>

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.blogs pot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

[Warren Stringer]

RE: c[:]()

Quotes out of context with mistaken assumptions, now follow:

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

>
No it doesn't. See below.

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).p ickle()
do(orchestra(co nductor)).seque nce()

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

I started this thread asking why c[:]() doesn't work.

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

What?!? I started this thread.

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.

Try it.

>>>[i() for i in c] # too long and ...huh?

a
b
[None,None]
#------------------------------------------

This is also clearly made up.

I repeat: try it.

In a later email you say:
>

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

>
The reason for this ...

Stated elsewhere, but thanks

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.

But neither tupples or lists work, so immutability isn't an issue.

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 never said that c() would execute a list nor did I ever say that c[:]()
would execute a list.

I think the fundamental mistake you have made is to convince yourself that
>
c[:]()
>
is legal Python. It isn't, it never has been.

In summation:
I started this thread asking why c[:]() wouldn't work
I did not hijack another thread
I posted working examples (with one typo, not quoted here)
I am extremely annoyed by this post

Tis best not to assume what other people are thinking

[Jerry Hill]

Re: c[:]()

On 5/31/07, Warren Stringer <warren@muse.co mwrote:

In summation:
I started this thread asking why c[:]() wouldn't work

Because it's not part of the language. Did you read something that
made you think it would work? Or are you proposing a change to the
language? I think you're better off providing the functionality
yourself, for your own containers. Luckily, it's pretty easy to do.
Mikael Olofsson showed you how to create a custom list that, when
called, will call each of the items it contains. Then you can use the
exact code you wrote in your first post, and it will do what you want.

I did not hijack another thread

You really did. In the first message you sent, we see the following header:

In-Reply-To: <1180504773.374 529.161740@q66g 2000hsg.googleg roups.com>

What you probably did was click 'Reply' on a message in an existing
thread, then change the Subject line and delete the quoted message.
That doesn't start a new thread. That creates a new post in the old
thread, with a new subject line and a completely unrelated message to
the rest of the thread. If you're using a reader that groups
everything by Subject line, it may even look like you started a new
thread, but anyone who relies on the rest of the headers to build
threads correctly will see differently.

I posted working examples (with one typo, not quoted here)

I retyped the code you posted in the first post, and did not get the
same results as you. Specifically:

>>def a: print 'a'

SyntaxError: invalid syntax

>>def b: print 'b'

SyntaxError: invalid syntax

those obviously were not copied from working code.

>>c[:]()

TypeError: 'tuple' object is not callable

this has the correct spelling of 'tuple' in it. Your post misspelled it.

and finally,

>>c[0]()

a

>>c[:][0]

<function a at 0x00CBB130>

I don't know how you could have gotten c[:][0] to print 'a', but it
wasn't by running all of the code you presented to us.

--
Jerry

[Grant Edwards]

Re: c[:]()

On 2007-05-31, Jerry Hill <malaclypse2@gm ail.comwrote:

On 5/31/07, Warren Stringer <warren@muse.co mwrote:

>In summation:
> I started this thread asking why c[:]() wouldn't work

>
Because it's not part of the language.

It's got nothing to do with the OP's usage, but it will work if
you define a class which returns something callable from its
__getitem__ method when passed a slice, right? It just won't
work for the built-in sequence types which always return a
sequence when you pass ':' to their __getitem__ method.

I think. Or am I not understanding how slices and __getitem__
works. In any case, that would be different that creating a
sequence class that can be called.

--
Grant Edwards grante Yow! Not SENSUOUS ... only
at "FROLICSOME " ... and in
visi.com need of DENTAL WORK ... in
PAIN!!!

[Erik Max Francis]

Re: c[:]()

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.

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.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
The quality, not the longevity, of one's life is what is important.
-- Dr. Martin Luther King, Jr.

[Steve Holden]

Re: c[:]()

Warren Stringer wrote:

Quotes out of context with mistaken assumptions, now follow:
>

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

>No it doesn't. See below.

>>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).p ickle()
>> do(orchestra(co nductor)).seque nce()
>>>

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

>
I started this thread asking why c[:]() doesn't work.
>

If you say so. Perhaps you didn't express yourself too clearly.

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

>
What?!? I started this thread.
>

No you didn't. Your original post was a reply to a message whose subject
line was 'Re: "is" and ==', and included the header

In-Reply-To: <1180504773.374 529.161740@q66g 2000hsg.googleg roups.com>

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

>
Try it.
>

>>>>>>>>[i() for i in c] # too long and ...huh?
>>a
>>b
>>[None,None]
>>#------------------------------------------

>This is also clearly made up.

>
I repeat: try it.
>

I don't need to. The function definitions contain syntax errors, and the
error message couldn't have been produced by any interpreter that ever
existed.

>In a later email you say:
>>

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

>The reason for this ...

>
Stated elsewhere, but thanks
>

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

>
But neither tupples or lists work, so immutability isn't an issue.
>

Good grief, man, c[0]() will work perfectly well as long as c is a list
or a tuple of functions. Or, come to that, a dict of functions with a
key of 0.

>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 never said that c() would execute a list nor did I ever say that c[:]()
would execute a list.
>

>I think the fundamental mistake you have made is to convince yourself that
>>
> c[:]()
>>
>is legal Python. It isn't, it never has been.

>
In summation:
I started this thread asking why c[:]() wouldn't work
I did not hijack another thread
I posted working examples (with one typo, not quoted here)
I am extremely annoyed by this post
>
Tis best not to assume what other people are thinking
>
>

Probably best not to try to help them too, if this is the response. Next
time you want assistance try to ensure that you copy and paste your
examples instead of trying to duplicate them from memory.

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.blogs pot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

[Warren Stringer]

RE: c[:]()

What?!? I started this thread.

No you didn't. Your original post was a reply to a message whose subject
line was 'Re: "is" and ==', and included the header
>
In-Reply-To: <1180504773.374 529.161740@q66g 2000hsg.googleg roups.com>

You're right, thanks.

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

that

>
c[:]()
>
is legal Python. It isn't, it never has been.

In my opinion, it is better to ask me directly what I think than to assume
what I am thinking. Describing a situation in second person -- using "you"
-- tends to have more interpretation than fact. When the interpretation is
wrong, the person who is at the receiving end of that "you" may be compelled
to reply. Sometimes that correction includes another "you"; interpretation
spawns interpretation -- soon, facts are replaced by projectiles.

In summation:
I started this thread asking why c[:]() wouldn't work
I did not hijack another thread
I posted working examples (with one typo, not quoted here)
I am extremely annoyed by this post

Tis best not to assume what other people are thinking

Probably best not to try to help them too, if this is the response.

I do appreciate your help. Responding on topic helps. Negative feedback
regarding typos helps. And, your statement:

Perhaps you didn't express yourself too clearly.

makes me feel all warm and fuzzy like ... why thank you!

Next
time you want assistance try to ensure that you copy and paste your
examples instead of trying to duplicate them from memory.

Agreed. Fortunately, others got the gist of what I was saying.

Oddly enough, as annoying as it was, your post helped my form, while other
posters have helped my content. I bet you'd make a good editor.

Cheers,

\~/

[Steve Holden]

Re: c[:]()

Warren Stringer wrote:

>>What?!? I started this thread.
>>>

>No you didn't. Your original post was a reply to a message whose subject
>line was 'Re: "is" and ==', and included the header
>>
>In-Reply-To: <1180504773.374 529.161740@q66g 2000hsg.googleg roups.com>

>
You're right, thanks.
>

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

>that

>>> c[:]()
>>>>
>>>is legal Python. It isn't, it never has been.

>
In my opinion, it is better to ask me directly what I think than to assume
what I am thinking. Describing a situation in second person -- using "you"
-- tends to have more interpretation than fact. When the interpretation is
wrong, the person who is at the receiving end of that "you" may be compelled
to reply. Sometimes that correction includes another "you"; interpretation
spawns interpretation -- soon, facts are replaced by projectiles.
>

Well I don't think there's much chance of that here. Please accept my
apologies if I misunderstood you.

>>In summation:
>> I started this thread asking why c[:]() wouldn't work
>> I did not hijack another thread
>> I posted working examples (with one typo, not quoted here)
>> I am extremely annoyed by this post
>>>
>>Tis best not to assume what other people are thinking
>>>

>Probably best not to try to help them too, if this is the response.

>
I do appreciate your help. Responding on topic helps. Negative feedback
regarding typos helps. And, your statement:
>
Perhaps you didn't express yourself too clearly.
>
makes me feel all warm and fuzzy like ... why thank you!
>

Well clearly I'd rather you were responsible for the miscommunicatio n
than I, but I don't *have* to be right about everything. And mostly I
try to help.

>Next
>time you want assistance try to ensure that you copy and paste your
>examples instead of trying to duplicate them from memory.

>
Agreed. Fortunately, others got the gist of what I was saying.
>
Oddly enough, as annoying as it was, your post helped my form, while other
posters have helped my content. I bet you'd make a good editor.
>
Cheers,
>
\~/
>

Sorry to have annoyed you. I don't always get up people's noses. Glad my
remarks were of at least *some* assistance.

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.blogs pot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

[Warren Stringer]

RE: c[:]()

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

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

Thanks,

\~/

[Steve Holden]

Re: c[:]()

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.blogs pot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

[Grant Edwards]

Re: c[:]()

On 2007-06-01, Warren Stringer <warren@muse.co mwrote:

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

[Warren Stringer]

RE: c[:]()

Steve Holden Wrote

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.

Give that everything is a first class object

"Look ma! I'm an object"() # causes
Traceback (most recent call last) ...
TypeError: 'str' object is not callable

def funky(): lookma()
funky() # causes

Traceback (most recent call last)...
NameError: global name 'lookma' is not defined

Means that any exception can be caught, thus equal.

`c[:]()` is unambiguous because:

def c(): print 'yo'

c() # works, but
c[:]() # causes:

Traceback (most recent call last)...
c[:]() # causes:
TypeError: unsubscriptable object

There are many `c()` to be found in the wild and no `c[:]()`, thus
unambiguous. To be honest, I wasn't sure, until testing this, just now.

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.

Oh well. Perhaps I can relax and actually write functioning code ;-)
What do you mean by 'c.l.py' ? The first thing that comes to mind is
'clippy' that helpful little agent in Word that helped pay for Simonyi's
trip into space.

Ching ching,

Warren