By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,813 Members | 1,121 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,813 IT Pros & Developers. It's quick & easy.

"is" and ==

P: n/a
Can someone please explain to me the difference between the "is"
keyword and the == boolean operator. I can't figure it out on my own
and I can't find any documentation on it.

I can't understand why this works:

if text is None:

and why this always returns false:

if message is 'PING':

even when message = 'PING'.

What's the deal with that?

May 30 '07 #1
Share this Question
Share on Google+
81 Replies


P: n/a
BlueJ774 wrote:
Can someone please explain to me the difference between the "is"
keyword and the == boolean operator. I can't figure it out on my own
and I can't find any documentation on it.

I can't understand why this works:

if text is None:

and why this always returns false:

if message is 'PING':

even when message = 'PING'.

What's the deal with that?
`x is y` means the same thing as:

id(x) == id(y)

You use the `is` operator for when you're testing for _object identity_,
not value. `None` is a special object sentinel that is not only a value
but a special _object_, and so if you're testing whether or not an
object is `None`, you do so with the `is` operator.

If you're testing whether an object is equal to the string "PING" then
you do not want to do so by identity, but rather value, so you use the
`==` operator, not `is`.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
You could have another fate / You could be in another place
-- Anggun
May 30 '07 #2

P: n/a
On May 30, 12:57 am, Erik Max Francis <m...@alcyone.comwrote:
BlueJ774 wrote:
Can someone please explain to me the difference between the "is"
keyword and the == boolean operator. I can't figure it out on my own
and I can't find any documentation on it.
I can't understand why this works:
if text is None:
and why this always returns false:
if message is 'PING':
even when message = 'PING'.
What's the deal with that?

`x is y` means the same thing as:

id(x) == id(y)

You use the `is` operator for when you're testing for _object identity_,
not value. `None` is a special object sentinel that is not only a value
but a special _object_, and so if you're testing whether or not an
object is `None`, you do so with the `is` operator.

If you're testing whether an object is equal to the string "PING" then
you do not want to do so by identity, but rather value, so you use the
`==` operator, not `is`.

--
Erik Max Francis && m...@alcyone.com &&http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
You could have another fate / You could be in another place
-- Anggun
Thanks. That's exactly what I was looking for.

May 30 '07 #3

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

#------------------------------------------
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
>>[i() for i in c] # too long and ...huh?
a
b
[None,None]
#------------------------------------------

Why? Because I want to make Python calls from a cell phone.
Every keystroke is precious; even list comprehension is too much.

Is there something obvious that I'm missing?

Warren

Today's quote: "HELLO PARROT! wakey wakey!"

May 30 '07 #4

P: n/a
On Wed, 2007-05-30 at 11:48 -0700, Warren Stringer wrote:
I want to call every object in a tupple, like so:

#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)
>>c[:]() # i wanna
[...]
Is there something obvious that I'm missing?
Yes: Python is not Perl.

Python is based on the principle that programmers don't write computer
code for the benefit of the computer, but for the benefit of any
programmer who has to read their code in the future. Terseness is not a
virtue. To call every function in a tuple, do the obvious:

for func in funcs: func()

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net
May 30 '07 #5

P: n/a
Hmmm, this is for neither programmer nor computer; this is for a user. If I
wanted to write code for the benefit for the computer, I'd still be flipping
switches on a PDP-8. ;-)

This is inconsistent:

why does c[:][0]() work but c[:]() does not?
Why does c[0]() has exactly the same results as c[:][0]() ?
Moreover, c[:][0]() implies that a slice was invoked

So, tell me, for scheduling a lot of asynchronous events, what would be more
readable than this:

bidders = [local_members] + [callin_members]
bidders[:].sign_in(roster)
...

\~/
-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Carsten Haese
Sent: Wednesday, May 30, 2007 12:55 PM
To: py*********@python.org
Subject: Re: c[:]()

On Wed, 2007-05-30 at 11:48 -0700, Warren Stringer wrote:
I want to call every object in a tupple, like so:

#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)
>>>c[:]() # i wanna
[...]
Is there something obvious that I'm missing?

Yes: Python is not Perl.

Python is based on the principle that programmers don't write computer
code for the benefit of the computer, but for the benefit of any
programmer who has to read their code in the future. Terseness is not a
virtue. To call every function in a tuple, do the obvious:

for func in funcs: func()

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net
--
http://mail.python.org/mailman/listinfo/python-list

May 30 '07 #6

P: n/a
On May 31, 12:31 am, "Warren Stringer" <war...@muse.comwrote:
This is inconsistent:

why does c[:][0]() work but c[:]() does not?
Why does c[0]() has exactly the same results as c[:][0]() ?
Moreover, c[:][0]() implies that a slice was invoked
It's not inconsistent, but [:] probably does something different than
you think it does. All it does is create a copy (not in general, but
at least if c is a list or a tuple). Since in your example c is a
tuple and tuples are immutable, making a copy of it is essentially
useless. Why not just use the original? I.e. instead of c[:] you could
just write c. That's why c[:][0]() has exactly the same effect as c[0]
(), although the former is likely to be slightly slower.

c[:]() tries to call the copied tuple. Tuples aren't callable.
c[:][0]() calls the first element in the copied tuple, and that
element happens to be callable.

May 30 '07 #7

P: n/a
Warren Stringer said unto the world upon 05/30/2007 05:31 PM:
Hmmm, this is for neither programmer nor computer; this is for a user. If I
wanted to write code for the benefit for the computer, I'd still be flipping
switches on a PDP-8. ;-)

This is inconsistent:

why does c[:][0]() work but c[:]() does not?
c[:][0]() says take a copy of the list c, find its first element, and
call it. Since c is a list of functions, that calls a function.

c[:]() says take a copy of the list c and call it. Since lists are not
callable, that doesn't work.
Why does c[0]() has exactly the same results as c[:][0]() ?
Because c[0] is equal to c[:][0].
Moreover, c[:][0]() implies that a slice was invoked
Yes, but the complete slice.
So, tell me, for scheduling a lot of asynchronous events, what would be more
readable than this:

bidders = [local_members] + [callin_members]
bidders[:].sign_in(roster)
...
for bidder in [local_members] + [callin_members]:
bidder.sign_in(roster)

Best,

Brian vdB
\~/
>-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Carsten Haese
Sent: Wednesday, May 30, 2007 12:55 PM
To: py*********@python.org
Subject: Re: c[:]()

On Wed, 2007-05-30 at 11:48 -0700, Warren Stringer wrote:
>>I want to call every object in a tupple, like so:

#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)

>c[:]() # i wanna
[...]
Is there something obvious that I'm missing?
Yes: Python is not Perl.

Python is based on the principle that programmers don't write computer
code for the benefit of the computer, but for the benefit of any
programmer who has to read their code in the future. Terseness is not a
virtue. To call every function in a tuple, do the obvious:

for func in funcs: func()

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net
--
http://mail.python.org/mailman/listinfo/python-list

May 30 '07 #8

P: n/a
Hey many thanks for the replies!

Ah, so is seems that c[:][:][:][:][:][:][:][:][:][:][:][0]()
also work ...

Ah well, can't have everything. Guess I was inspired by the alphabetically
adjacent message "Call for Ruby Champion". Would have been nice for it work
- a more elegant iterator would be hard to come by. A PEP, perhaps? Maybe
not; am still a bit new - am probably missing something obvious why this
isn't an easy fix.

Pretty cool that I can override the list class.

Cheers,

\~/
-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Brian van den Broek
Sent: Wednesday, May 30, 2007 3:00 PM
To: py*********@python.org
Subject: Re: c[:]()

Warren Stringer said unto the world upon 05/30/2007 05:31 PM:
Hmmm, this is for neither programmer nor computer; this is for a user.
If I
wanted to write code for the benefit for the computer, I'd still be
flipping
switches on a PDP-8. ;-)

This is inconsistent:

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

c[:][0]() says take a copy of the list c, find its first element, and
call it. Since c is a list of functions, that calls a function.

c[:]() says take a copy of the list c and call it. Since lists are not
callable, that doesn't work.
Why does c[0]() has exactly the same results as c[:][0]() ?

Because c[0] is equal to c[:][0].
Moreover, c[:][0]() implies that a slice was invoked

Yes, but the complete slice.
So, tell me, for scheduling a lot of asynchronous events, what would be
more
readable than this:

bidders = [local_members] + [callin_members]
bidders[:].sign_in(roster)
...

for bidder in [local_members] + [callin_members]:
bidder.sign_in(roster)

Best,

Brian vdB
\~/
-----Original Message-----
From: py*********************************@python.org [mailto:python-
list-
bo*********************@python.org] On Behalf Of Carsten Haese
Sent: Wednesday, May 30, 2007 12:55 PM
To: py*********@python.org
Subject: Re: c[:]()

On Wed, 2007-05-30 at 11:48 -0700, Warren Stringer wrote:
I want to call every object in a tupple, like so:

#------------------------------------------
def a: print 'a'
def b: print 'b'
c = (a,b)

c[:]() # i wanna
[...]
Is there something obvious that I'm missing?
Yes: Python is not Perl.

Python is based on the principle that programmers don't write computer
code for the benefit of the computer, but for the benefit of any
programmer who has to read their code in the future. Terseness is not a
virtue. To call every function in a tuple, do the obvious:

for func in funcs: func()

HTH,

--
Carsten Haese
http://informixdb.sourceforge.net
--
http://mail.python.org/mailman/listinfo/python-list

--
http://mail.python.org/mailman/listinfo/python-list

May 30 '07 #9

P: n/a
On May 30, 5:37 pm, "Warren Stringer" <war...@muse.comwrote:
Hey many thanks for the replies!

Ah, so is seems that c[:][:][:][:][:][:][:][:][:][:][:][0]()
also work ...

Ah well, can't have everything. Guess I was inspired by the alphabetically
adjacent message "Call for Ruby Champion". Would have been nice for it work
- a more elegant iterator would be hard to come by. A PEP, perhaps? Maybe
not; am still a bit new - am probably missing something obvious why this
isn't an easy fix.

Pretty cool that I can override the list class.

Cheers,
Do a search on "python is not java" (words to live by). You can also
plug in another language you know (like Ruby), but you won't get as
many results.

May 30 '07 #10

P: n/a
Hey Dustan, very cool!

The first hit on "python is not java" turns up the dirtsimple blog, which
kicked my asp -- so, to speak (reptile not server pages - mon dieu, I'm
explain a pun, how wretched) ...

Dirtsimple mentions shallow versus deep. Damn!

First off, I love dots. They're easy to type. I like to go deep. Yet have
been finding that a.b.c.d.e.f() tends to suck __getattr__

The dirtsimple blog also mentions using hash-trees as a switch
statement...hmmmm .... I wonder which is faster:

a.b.c.d.e.f() # or
h['a.b.c.d.e.f']() # doh!

I still want my executable container though. Would love to so this

h[search('a//f')]() # where a//f is like an Xpath // search for leaves

Believe me, this is incredibly useful for executing an ontology, which
happens to be what I'm working on during every waking moment, when not on
the python list.

Cheers,

\~/
-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Dustan
Sent: Wednesday, May 30, 2007 4:14 PM
To: py*********@python.org
Subject: Re: c[:]()

On May 30, 5:37 pm, "Warren Stringer" <war...@muse.comwrote:
Hey many thanks for the replies!

Ah, so is seems that c[:][:][:][:][:][:][:][:][:][:][:][0]()
also work ...

Ah well, can't have everything. Guess I was inspired by the
alphabetically
adjacent message "Call for Ruby Champion". Would have been nice for it
work
- a more elegant iterator would be hard to come by. A PEP, perhaps?
Maybe
not; am still a bit new - am probably missing something obvious why this
isn't an easy fix.

Pretty cool that I can override the list class.

Cheers,

Do a search on "python is not java" (words to live by). You can also
plug in another language you know (like Ruby), but you won't get as
many results.

--
http://mail.python.org/mailman/listinfo/python-list

May 31 '07 #11

P: n/a
Warren Stringer wrote:
>>>>c[:]() # i wanna
TypeError: 'tupple' object is not callable
c[:] equals c (in expressions), so c[:]() is equivalent to c()
>>>>c[:][0] # huh?
a
c[:][0] is c[0] is a
>>>[i() for i in c] # too long and ...huh?
a
b
[None,None]
#------------------------------------------
[None, None] is the result of the operation.

for i in c: i()

If that is too long, reconsider what you are doing.

--

Regards,
Tijs
May 31 '07 #12

P: n/a
Oops! guess I should have tested my rather hasty complaint about executable
containers. This is nice:

def a(): return 'b'
def b(): print 'polly! wakey wakey'
c = {}
c['a'] = b
c[a()]() #works!
c[a()]() is a switch statement with an amorphous selector- very handy in its
own right. But, using a() as a generator would be more expressive. This
seems to work:

c = [a,a]
[d() for d in c]

But that still isn't as simple or as direct as:

c[:]()

Which would you rather explain to a 12-year-old writing code for the first
time?
I still want my executable container though. Would love to so this

h[search('a//f')]() # where a//f is like an Xpath // search for leaves

May 31 '07 #13

P: n/a
ir****@gmail.com wrote:
On May 31, 12:31 am, "Warren Stringer" <war...@muse.comwrote:
>This is inconsistent:

why does c[:][0]() work but c[:]() does not?
Why does c[0]() has exactly the same results as c[:][0]() ?
Moreover, c[:][0]() implies that a slice was invoked

It's not inconsistent, but [:] probably does something different than
you think it does. All it does is create a copy (not in general, but
at least if c is a list or a tuple). Since in your example c is a
tuple and tuples are immutable, making a copy of it is essentially
useless. Why not just use the original? I.e. instead of c[:] you could
just write c. That's why c[:][0]() has exactly the same effect as c[0]
(), although the former is likely to be slightly slower.
An extremely minor point (and implementation specific), but while [:] will
copy a list it won't copy a tuple. Likewise 'list(aList)' will always copy
a list, 'tuple(aTuple)' won't copy a tuple. So in this particular example
the slice is completely redundant.
>>c is c[:] is c[:][:][:][:] is tuple(c)
True
May 31 '07 #14

P: n/a
On Wed, 30 May 2007 23:23:22, Warren Stringer <wa****@muse.comwrote
>
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
,----
| c['a']() #works!
`----

--
Doug Woodrow

May 31 '07 #15

P: n/a
On Thu, 31 May 2007 08:57:56, Douglas Woodrow
<ne********@nospam.demon.co.ukwrote
>On Wed, 30 May 2007 23:23:22, Warren Stringer <wa****@muse.comwrote
>>
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
,----
| c['a']() #works!
`----
Oh no, I get it, you meant...
,----
| c['b'] = b
| c[a()]() #works!
`----

....or was it?:-
,----
| def a(): return 'a'
`----

--
Doug Woodrow

May 31 '07 #16

P: n/a
In <ma***************************************@python. org>, Warren Stringer
wrote:
Oops! guess I should have tested my rather hasty complaint about executable
containers. This is nice:

def a(): return 'b'
def b(): print 'polly! wakey wakey'
c = {}
c['a'] = b
c[a()]() #works!
c[a()]() is a switch statement with an amorphous selector- very handy in its
own right. But, using a() as a generator would be more expressive. This
seems to work:

c = [a,a]
[d() for d in c]
If you are using the list comprehension just for the side effect of
calling `d` then consider this bad style. You are building a list of
`None` objects just to have a "cool" one liner then.
But that still isn't as simple or as direct as:

c[:]()

Which would you rather explain to a 12-year-old writing code for the first
time?
for func in funcs:
func()

Because it is explicit and readable and matches the english description
"for every function in functions: call that function" very closely while a
list comprehension or your "perlish" line noise is much more magic to
explain and harder to remember.

Ciao,
Marc 'BlackJack' Rintsch
May 31 '07 #17

P: n/a
Warren Stringer wrote:
I want to call every object in a tupple, like so:
[snip examples]
Why? Because I want to make Python calls from a cell phone.
Every keystroke is precious; even list comprehension is too much.
If you are going to do this just a few times in your program, I cannot
help. But: If you want to do it several times, perhaps you have space
for an initial class definition, like so:

class CallableList(list):
def __call__(self,*args,**kwargs):
return [f(*args,**kwargs) for f in self]

def a(): return 'a called'
def b(): return 'b called'
c = CallableList([a,b])()

You might want to trim the class to fit your needs, perhaps use a
shorter name, and perhaps you don't need to handle arguments. Can the
class be placed in a module, so that it only needs to be typed once in
your application?

/MiO
May 31 '07 #18

P: n/a
Il Wed, 30 May 2007 11:48:47 -0700, Warren Stringer ha scritto:

[cut]
>>c[:] is c
True

BTW, I couldn't understand your concern. Are you sure you really need many
functions, and not just one function with different parametrs? In such a
case you could just use the builtin func map() to achieve the very same
result.

Or you could define a function of your own like:

def call_elems(iterable):
for elem in iterable:
elem()

and just do call_elems(c) when needed.


--
Alan Franzoni <al***************@gmail.com>
-
Togli .xyz dalla mia email per contattarmi.
Remove .xyz from my address in order to contact me.
-
GPG Key Fingerprint (Key ID = FE068F3E):
5C77 9DC3 BD5B 3A28 E7BC 921A 0255 42AA FE06 8F3E
May 31 '07 #19

P: n/a
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()]()
even more interesting is a

,----------------------------------------
| def judge(contestants):
| for contestant in contestants:
| ...
| if answersQuestionToSatisfaction:
| yield semiFinalist
|
| beauty[judge(beauty)]()

hmmmm, I suppost you could just call

judge(beauty)

and have the judge call the contestant personally.
But that may be *too* personal. Moreover, what about
the other judges? Wouldn't it be best to simply state:

beauty[judges[:](beauty)].thankyouForThisOpportunity()

This allows each judge to choose differently while all
the contestants behave consistently. It kind of like an
off the cuff decorator for generators, where

beauty[...].decoration()

Maybe there's a better way of doing this? I don't know.
>
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
,----
| c['a']() #works!
`----

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

...or was it?:-
,----
| def a(): return 'a'
`----

--
Doug Woodrow

--
http://mail.python.org/mailman/listinfo/python-list

May 31 '07 #20

P: n/a
On 2007-05-31, Warren Stringer <wa****@muse.comwrote:
Oops! guess I should have tested my rather hasty complaint about executable
containers. This is nice:

def a(): return 'b'
def b(): print 'polly! wakey wakey'
c = {}
c['a'] = b
c[a()]() #works!
c[a()]() is a switch statement with an amorphous selector- very handy in its
own right. But, using a() as a generator would be more expressive. This
seems to work:

c = [a,a]
[d() for d in c]

But that still isn't as simple or as direct as:

c[:]()
Why do you always use a _copy_ of c in your examples? As long
as you're wishing, why not just

c()

--
Grant Edwards grante Yow! I'm meditating on
at the FORMALDEHYDE and the
visi.com ASBESTOS leaking into my
PERSONAL SPACE!!
May 31 '07 #21

P: n/a
Cool! Yes. By the way, I've discovered that [] are quite difficult on cell
phones. But periods and parens are easy. So, I'm using your approach for
creating a dot operator for {}

-----Original Message-----
From: py*********************************@python.org [mailto:python-list-
bo*********************@python.org] On Behalf Of Mikael Olofsson
Sent: Thursday, May 31, 2007 1:52 AM
To: py*********@python.org
Subject: Re: c[:]()

Warren Stringer wrote:
I want to call every object in a tupple, like so:
[snip examples]
Why? Because I want to make Python calls from a cell phone.
Every keystroke is precious; even list comprehension is too much.

If you are going to do this just a few times in your program, I cannot
help. But: If you want to do it several times, perhaps you have space
for an initial class definition, like so:

class CallableList(list):
def __call__(self,*args,**kwargs):
return [f(*args,**kwargs) for f in self]

def a(): return 'a called'
def b(): return 'b called'
c = CallableList([a,b])()

You might want to trim the class to fit your needs, perhaps use a
shorter name, and perhaps you don't need to handle arguments. Can the
class be placed in a module, so that it only needs to be typed once in
your application?

/MiO
--
http://mail.python.org/mailman/listinfo/python-list

May 31 '07 #22

P: n/a
Hey Marc,
[d() for d in c]

If you are using the list comprehension just for the side effect of
calling `d` then consider this bad style. You are building a list of
`None` objects just to have a "cool" one liner then.
Yep, you're right
for func in funcs:
func()

Because it is explicit and readable and matches the english description
"for every function in functions: call that function" very closely while a
list comprehension or your "perlish" line noise is much more magic to
explain and harder to remember.
Hmmmm... the reason what I use the list comprehension was the description
"call that thing for every thing in those things" The first time I something
saw this I though, in my C befuddled head 'huh? that's backwards!' But,
then the more I thought about it I recall that this is how some people
speak.

Still I prefer

funcs[:]()

Because, I can describe it in English as "call everything that funcs has"

(BTW, I have yet to write my first line of Perl. It that good thing or a bad
thing?)

May 31 '07 #23

P: n/a

But that still isn't as simple or as direct as:

c[:]()

Why do you always use a _copy_ of c in your examples? As long
as you're wishing, why not just

c()
Oh hey Grant, yes, I misunderstood your question for a bit. I thought you
meant the difference between List comprehension [...] and generator
expressions (...) where the first returns the whole list and the second
iterates the whole list.

But, yes, good point if I was only using [:]. For more expressiveness, I
could using the alternative, to the example in my reply to Douglas

def beauty(judge): ...

As an alternative to my reply to Douglas ... and is more cell phone
friendly, due to lack of cumbersome [], which I just mentioned to Mikael,
who came up with an really cool [] solution ... hmmm ...

Translating Mikael's solution to the original c[:]() with some tweaks:

class do(list):
def __call__(self,*args,**kwargs):
return [f(*args,**kwargs) for f in self]

def a(): print 'a called'
def b(): print 'b called'
c = [a,b]
do(c[:])() # close but with cell phone gnarly []

do(c)() # woo hoo!

In recalling Marc's reply about a cool one liner, such a statement
translates in English, as "do everything in c" <insert evil laughter>

Cheers,

\~/

May 31 '07 #24

P: n/a
On 2007-05-31, Warren Stringer <wa****@muse.comwrote:
But that still isn't as simple or as direct as:

c[:]()

Why do you always use a _copy_ of c in your examples? As long
as you're wishing, why not just

c()

Oh hey Grant, yes, I misunderstood your question for a bit. I
thought you meant the difference between List comprehension
[...] and generator expressions (...) where the first returns
the whole list and the second iterates the whole list.

But, yes, good point if I was only using [:]. For more
expressiveness,
How is it more expressive? In the context you're concerned
with, c[:] is the exactly same thing as c. You seem to be
worried about saving keystrokes, yet you use c[:] instead of c.

It's like having an integer variable i and using ((i+0)*1)
instead of i.

--
Grant Edwards grante Yow! I want to read my new
at poem about pork brains and
visi.com outer space ...
May 31 '07 #25

P: n/a
On Thu, 31 May 2007 07:59:35 -0700, Warren Stringer wrote:
Still I prefer

funcs[:]()

Because, I can describe it in English as "call everything that funcs has"
But that's not what it says. It says, "call a copy of funcs".

The simplest, most straightforward way of calling everything that funcs
has is simply:

for func in funcs: func()
By the way... if you're worried about saving keystrokes on your mobile
phone, why don't you do your development on a PC and upload it to the
phone when it is done? Or have I misunderstood?

--
Steven.

May 31 '07 #26

P: n/a
On May 31, 5:59 pm, "Warren Stringer" <war...@muse.comwrote:
Still I prefer

funcs[:]()

Because, I can describe it in English as "call everything that funcs has"
Wouldn't funcs() be even better? It's shorter, and it seems like
that's the only thing you're striving for. Why do you want to put the
[:] in there all the time?

May 31 '07 #27

P: n/a
How is it more expressive? In the context you're concerned
with, c[:] is the exactly same thing as c. You seem to be
worried about saving keystrokes, yet you use c[:] instead of c.

It's like having an integer variable i and using ((i+0)*1)
instead of i.
Nope, different.

c[:] holds many behaviors that change dynamically. So c[:]() -- or the more
recent go(c)() -- executes all those behaviors. This is very useful for many
performers. 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.

May 31 '07 #28

P: n/a
On 2007-05-31, Warren Stringer <wa****@muse.comwrote:
>How is it more expressive? In the context you're concerned
with, c[:] is the exactly same thing as c. You seem to be
worried about saving keystrokes, yet you use c[:] instead of c.

It's like having an integer variable i and using ((i+0)*1)
instead of i.

Nope, different.

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.
So c[:]() -- or the more recent go(c)() -- executes all those
behaviors.
Still no clue.
This is very useful for many performers.
What are "performers"?
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.

--
Grant Edwards grante Yow! TONY RANDALL! Is YOUR
at life a PATIO of FUN??
visi.com
May 31 '07 #29

P: n/a
Grant Edwards wrote:
On 2007-05-31, Warren Stringer <wa****@muse.comwrote:
>>How is it more expressive? In the context you're concerned
with, c[:] is the exactly same thing as c. You seem to be
worried about saving keystrokes, yet you use c[:] instead of c.

It's like having an integer variable i and using ((i+0)*1)
instead of i.
Nope, different.

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.
>So c[:]() -- or the more recent go(c)() -- executes all those
behaviors.

Still no clue.
>This is very useful for many performers.

What are "performers"?
>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.

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

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

May 31 '07 #30

P: n/a
On 2007-05-31, Steve Holden <st***@holdenweb.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?
May 31 '07 #31

P: n/a
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?
May 31 '07 #32

P: n/a
On Thu, 31 May 2007 07:49:22, Warren Stringer <wa****@muse.comwrote
>>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

May 31 '07 #33

P: n/a
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 ----------------

May 31 '07 #34

P: n/a
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).pickle()
do(orchestra(conductor)).sequence()
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
May 31 '07 #35

P: n/a
On 5/31/07, Warren Stringer <wa****@muse.comwrote:
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: <11**********************@q66g2000hsg.googlegroups .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
May 31 '07 #36

P: n/a
On 2007-05-31, Jerry Hill <ma*********@gmail.comwrote:
On 5/31/07, Warren Stringer <wa****@muse.comwrote:
>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!!!
May 31 '07 #37

P: n/a
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 && ma*@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.
May 31 '07 #38

P: n/a
Warren Stringer wrote:
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).pickle()
do(orchestra(conductor)).sequence()
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: <11**********************@q66g2000hsg.googlegroups .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.blogspot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

Jun 1 '07 #39

P: n/a
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: <11**********************@q66g2000hsg.googlegroups .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,

\~/

Jun 1 '07 #40

P: n/a
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: <11**********************@q66g2000hsg.googlegroups .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 miscommunication
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.blogspot.com squidoo.com/pythonology
tagged items: del.icio.us/steve.holden/python
All these services currently offer free registration!
-------------- Thank You for Reading ----------------

Jun 1 '07 #41

P: n/a
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,

\~/

Jun 1 '07 #42

P: n/a
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 ----------------

Jun 1 '07 #43

P: n/a
On 2007-06-01, Warren Stringer <wa****@muse.comwrote:
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
Jun 1 '07 #44

P: n/a
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
Jun 1 '07 #45

P: n/a
On 2007-06-01, Warren Stringer <wa****@muse.comwrote:
>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'?
comp.lang.python: the Usenet news group in which this
discussion is taking place.

--
Grant Edwards grante Yow! Is it clean in other
at dimensions?
visi.com
Jun 1 '07 #46

P: n/a
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.
The speed at which you can type code is almost _never_ a valid reason to
make something brief. Code gains readability from verbosity. (That can
be taken too far, of course, but that certainly doesn't apply here.)

Either way, something like `do(c)()` to do what you want is easily
implementable in Python, and always has been. Same thing with your
`c()` or `c[:]()` solutions (though the latter makes no semantic sense);
just use custom sequence types.
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?
You keep sticking the slice in there. That still makes no sense.

The fundamental reason it does not make logical sense to make a list
callable (which would then call its elements) is that lists can contain
objects that aren't callable. So then, if you want lists to be
callable, the question becomes, what should it do with the elements that
aren't callable? Choke on the first one? Ignore them? Abort entirely
and not call any of them?

This kind of a design question can go every possible way depending on
what particular application you're using the calling syntax for, so the
proper design question from a language perspective is not to choose any.
If you want a callable sequence (which calls its elements and has any
or all of the above behaviors), it is _trivial_ to make one. There is
no need for support for this, because what it should do is not clear.
I use `c[:]()` because it is unambiguous about using a container
There are containers that don't support slicing (a stack, for instance),
so you're not using the right terminology here. If you do mean general
containers, then your slicing violates duck typing since it effectively
enforces a constraint that may not be desired. _If_ one were to have
callable containers, then callable containers should be usable in _any_
context in which an object is called, not just ones where slices were done.

If you intend `c[:]()` to have different semantics than `c()` -- it
isn't clear from your comments whether you mean it to or not, but you
keep nonsensically mentioning the slicing notation -- then you're
_really_ out in left field. Now that requires operations to behave
differently in different contexts, which is a huge can of worms and
rapidly makes code unreadable.

In short, your repeated use of `c[:]()` indicates a fundamental
misunderstanding about Pythonic style _and_ substance.
>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.
Soon isn't all that soon. Furthermore, it is very unlikely that someone
is going to be able to suggest profound and useful changes to Python
without first being familiar with it. So stabbing in the dark is not
going to be very constructive for either learning Python, or suggesting
useful improvements. That's just the way the ball bounces, unfortunately.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
To endure what is unendurable is true endurance.
-- (a Japanese proverb)
Jun 1 '07 #47

P: n/a
Warren Stringer wrote:
`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.
>>c = 'not quite'
c[:]
'not quite'
>>c[:]()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable

You also seem to be under the impression that `x[:]()` is somehow
special syntax that is treated differently than `y = x[:]; y()`. It is not.

Besides, _ambiguity_ was never the problem. _Functionality_ is the problem.

--
Erik Max Francis && ma*@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
To endure what is unendurable is true endurance.
-- (a Japanese proverb)
Jun 1 '07 #48

P: n/a
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.

The speed at which you can type code is almost _never_ a valid reason to
make something brief. Code gains readability from verbosity. (That can
be taken too far, of course, but that certainly doesn't apply here.)
There is code that you type which persists and code that you type from a
command line. Two completely different idioms. A credo inside the cell phone
game industry is that you lose half your audience with each menu keystroke.
That's how precious keystrokes are.

What may be confusing is speaking about both idioms at once.

<snip>
In short, your repeated use of `c[:]()` indicates a fundamental
misunderstanding about Pythonic style _and_ substance.
Please define Pythonic. Is this like a certain US senator who defined porn
as "I know it when I see it."

28 years ago, I wrote a hierarchical DBMS that used lexical indentation. 15
years ago I wrote a multimedia script language that used lexical indentation
and automatic garbage collection - it was deployed on millons of clients. 2
years ago I hand coded every line of the Python 2.2 BNF into another style
of language description. Up until last month, I had tokenized a subset of
said definition in C++, using templates to manage cardinality. Recently, I
decided to forgo the C++ parser and am now rewriting it in Python. This is a
risk. So, what hoop does one jump though to earn that oh so coveted
"pythonic" merit badge?

Your other post responds with working examples. So, I'll jump over to that
one.

Jun 1 '07 #49

P: n/a
Warren Stringer wrote:
>
`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.
>>c = 'not quite'
>>c[:]
'not quite'
>>c[:]()
Traceback (most recent call last):
File "<stdin>", line 1, in ?
TypeError: 'str' object is not callable

Interesting example. By extension
#-------------------------
>>def c(): print 'yo'
....
>>c
<function c at 0x00B867F0>
>>c(bad)
Traceback (most recent call last):
File "<stdin>", line 1, in ?
NameError: name 'bad' is not defined
#-------------------------

Both your example and mine show well formed and ill formed statements at the
command line.
You also seem to be under the impression that `x[:]()` is somehow
special syntax that is treated differently than `y = x[:]; y()`. It is
not.
No; I was under the impression that `x[:]()` didn't work and the reason why
it didn't work wasn't obvious.

I like your use case. Am I correct in assuming that `y = x[:]; y()` is NOT
to be found in working code? If that is the case, then nothing gets broken.
It would be instructive to have a use case where enabling c[:]() would break
existing code.
Besides, _ambiguity_ was never the problem. _Functionality_ is the
problem.
Ambiguity is one of many parameters. It was a problem with another poster. I
wish I had McConnel's Code Complete book handy. Let's see ... a search
yields: debugging, testing, performance, portability, design, interfaces,
style, and notation.

My use case is this:

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

And so now, that I can, I am happy. Life is good. Time to sleep.

Jun 1 '07 #50

81 Replies

This discussion thread is closed

Replies have been disabled for this discussion.