Home     |     .Net Programming    |     cSharp Home    |     Sql Server Home    |     Javascript / Client Side Development     |     Ajax Programming

Ruby on Rails Development     |     Perl Programming     |     C Programming Language     |     C++ Programming     |     IT Jobs

Python Programming Language     |     Laptop Suggestions?    |     TCL Scripting     |     Fortran Programming     |     Scheme Programming Language


 
 
Cervo Technologies
The Right Source to Outsource

MS Dynamics CRM 3.0

Python Programming Language

"is" and ==


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

On May 30, 12:57 am, Erik Max Francis <m@alcyone.com> wrote:

Thanks.  That's exactly what I was looking for.
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!"  

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

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

\~/

> From: Warren Stringer
> 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

c[:] is a copy of c, if c is a list, tuple, string, or other object that
supports slicing.  c[:][0] points to the same object as c[0].  If that
object is a function, then c[:][0]() and c[0]() do the same thing, because
they both point to the same function.

c[:]() does not make sense, because c is a tuple and not a function.
Similarly, c[0:1]() will not make sense because while c is a tuple of one
object, it is still a tuple and not a function.  Note that c[0] is not the
same as c[0:1]:  the former is the object pointed to by the first member of
the tuple, while the second is a tuple containing a single member pointing
to the first member of the original tuple.  There isn't an inconsistency
because the two notations mean completely different things.

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

Does bidders[:].sort() make sense?  In your scheme, would this tell the
various contents of bidders to sort their own contents, or would it do the
currently valid action of sorting a copy of the bidders list?

I think you misunderstand how the slice operator works.  A slice of a tuple
is itself a tuple.  If you want to act on the contents of that tuple, you
need to act on those contents individually either by indexing them (c[0]) or
iterating over them (for f in c:).

--
-Bill Hamilton

On May 31, 12:31 am, "Warren Stringer" <war@muse.com> wrote:

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

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

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,

\~/

On May 30, 5:37 pm, "Warren Stringer" <war@muse.com> wrote:

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

\~/

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

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?

irs@gmail.com wrote:
> On May 31, 12:31 am, "Warren Stringer" <war@muse.com> wrote:
>> 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
On Wed, 30 May 2007 23:23:22, Warren Stringer <war@muse.com> wrote

>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

On Thu, 31 May 2007 08:57:56, Douglas Woodrow
<newsgro@nospam.demon.co.uk> wrote

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

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

--
Doug Woodrow

In <mailman.8452.1180592620.32031.python-l@python.org>, Warren Stringer
wrote:

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

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

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 <alan.franzoni.@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

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.

On 2007-05-31, Warren Stringer <war@muse.com> wrote:

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

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

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

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

\~/

Add to del.icio.us | Digg this | Stumble it | Powered by Megasolutions Inc