"is" and ==

[Marc 'BlackJack' Rintsch]

Re: c[:]()

In <1180886141.096 451.68060@k79g2 000hse.googlegr oups.com>,
Stebanoid@gmail .com wrote:

>>[using `map()`]

>And has the same issue as a list comprehension if all you want is the side
>effect of the calls: a useless temporary list full of `None`\s is build.

>
functoins can return a values, and you get it. I don't think that it
is bad side effect.

I don't either. By definition it's not a side effect at all. Side effects
are the "things that happen" besides the return values.

Warren Stringer wanted to call the functions just for the side effects
without interest in the return values. So building a list of return
values which is immediately thrown away is a waste of time and memory.

When you write simple

>>>def a(): print "From Russia with love."
>>>a()

you have side effect too - returning "None".

No, the side effect is the printing of 'From Russia with love.'

IMHO there's a difference between this single `None` that can't be
prevented and abusing a list comprehension or `map()` just for side
effects and not for building a list with meaningful content.

Ciao,
Marc 'BlackJack' Rintsch

[Warren Stringer]

RE: c[:]()

Anyway, the code below defines a simple "callable" list; it just calls
each contained item in turn. Don't bother to use [:], it won't work.
>
pyclass CallableList(li st):
... def __call__(self):
... for item in self:
... item()
...
pydef a(): print "a"
...
pydef b(): return 4
...
pydef c(): pass
...
pydef d():
... global z
... z = 1
...
pyz="A"
pyx = CallableList([a,b,c,d])
pyx()
a
pyz
1

I just ran this example. I think the class is simpler than Mikael's example:

class CallableList(li st):
def __call__(self,* args,**kwargs):
return [f(*args,**kwarg s) for f in self]

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

Though Mikael's returns a list containing all the returns of each item,
which comes in handy for some use cases. So, your examples with Mikael's
CallableList, yields a list [None,4,None,Non e]

Mikael's shows how such a construct could simplify homogenous lists. Yours
shows how it might obfuscate heterogeneous lists.

Your example is less of an edge condition than ["string", func], as these
are all funcs. It best shows why supporting a general case of c[:]() might
lead to more obscure code.

My use case is very homogenous. I am porting a C++ parsed script that
contain 1000's of calls with no return value. So, I'll probably be using a
cross between your version and Mikael's.

There is another incentive for a callable list. Much of my script has deep
nested namespaces, like a.b.c.d(). In C++, deep nesting is cheap, but in
python, it is expensive because each dot is, in its own right, a function
call to __getattr__. Collecting all the calls into list preprocesses all of
the dots.

Thanks for the example

I begin to think you are some kind of Eliza experiment with Python
pseudo-knowledge injected.

BTW, my favorite Eliza implementation of all time is the one written by
Strout, Eppler, and Higgins ... in Python, of course.

[Terry Reedy]

Re: c[:]()


"Marc 'BlackJack' Rintsch" <bj_666@gmx.net wrote in message
news:pan.2007.0 6.03.20.03.25.2 78011@gmx.net.. .
|| Warren Stringer wanted to call the functions just for the side effects
| without interest in the return values. So building a list of return
| values which is immediately thrown away is a waste of time and memory.

Also unnecessary: for f in callables: f()

tjr

[Warren Stringer]

RE: c[:]()

"Marc 'BlackJack' Rintsch" <bj_666@gmx.net wrote in message

news:pan.2007.0 6.03.20.03.25.2 78011@gmx.net.. .
|| Warren Stringer wanted to call the functions just for the side effects
| without interest in the return values. So building a list of return
| values which is immediately thrown away is a waste of time and memory.
>
Also unnecessary: for f in callables: f()

What do you mean?

This is very relevant to what I need to implement now. I am converting a
domain specific language script into python statements. For debugging the
script gets parsed and generates a .py file. The final bypasses the
intermediate step; instead it parses the script and does something like
this:

code = compile(_call," ParseCall",'exe c')
for coname in code.co_names:
... cleanup goes here
exec code in self._dict

I am already worried about speed. There are about 2000 macro statements that
look like this:

demo4: demo.stop()
ball.smooth()
video.live()
preset.video.st raight()
view.front3d()
luma.real()
seq[:]lock(1)

In this example, the preprocessor translates the statements into a list of
10 callable objects. That last `seq[:]lock(1)` statement generates 4 objects
on its own. All of the __getattr__ resolution is done in the preprocessor
step. For the sort term version are no return values. For the long term
version, there may be return statements, but prefer simplest, for now.

It sounds like list comprehension may be slower because it builds a list
that never gets used. I'm curious if eval statements are faster than def
statements? Any bytecode experts?

Sorry if I got sidetracked on philosophical discussion, earlier. The above
example is lifted from a working c++ version with a tweaked syntax. This is
a real problem that I need to get working in a couple weeks.

As an aside, the code base will be open source.

Much appreciated,

\~/

[Erik Max Francis]

Re: c[:]()

Warren Stringer wrote:

demo4: demo.stop()
ball.smooth()
video.live()
preset.video.st raight()
view.front3d()
luma.real()
seq[:]lock(1)

You're way off in la-la land, now.

It sounds like list comprehension may be slower because it builds a list
that never gets used. I'm curious if eval statements are faster than def
statements? Any bytecode experts?

Are you serious? Something that builds a list that never gets used is
exactly what you were proposing this whole time.

--
Erik Max Francis && max@alcyone.com && http://www.alcyone.com/max/
San Jose, CA, USA && 37 20 N 121 53 W && AIM, Y!M erikmaxfrancis
Get there first with the most men.
-- Gen. Nathan Bedford Forrest, 1821-1877

[Terry Reedy]

Re: c[:]()


"Warren Stringer" <warren@muse.co mwrote in message
news:00b301c7a6 90$25af37d0$240 110ac@Muse...
|"Marc 'BlackJack' Rintsch" <bj_666@gmx.net wrote in message
| news:pan.2007.0 6.03.20.03.25.2 78011@gmx.net.. .
| || Warren Stringer wanted to call the functions just for the side
effects
| | without interest in the return values. So building a list of return
| | values which is immediately thrown away is a waste of time and
memory.
| >
| Also unnecessary: for f in callables: f()
|
| What do you mean?

That if you want to call each of a sequence of proceedures (functions
without a meaning return), as you have indicated and do so again, then the
above is the simple, direct way to do so. Using 'c' instead of
'callables', as in the subject line, would reduce the number of characters

[snip]
| It sounds like list comprehension may be slower because it builds a list
| that never gets used.

A list comprenhension is for building a list that will be used.

| I'm curious if eval statements are faster than def
| statements? Any bytecode experts?

Eval expressions (not statements) and def statements do different things
and hence comparing their speed make no sense to me. In any case, speed
comparisions that you really care about are best done on a particular
target system.

Terry Jan Reedy

[Steve Holden]

Re: c[:]()

Warren Stringer wrote:

Oops, forgot to cut and paste the point, to this:
>

>>- there is no Python error for "you
>>cannot do this with this object, but you can do it with other objects
>>of the same type".

>Yes there is:
>>
>#------------------------
>def yo(): print "yo"
>def no(): print blah
>yo()
>no()
>>
>Starting Python debug run ...
>yo
>Traceback (most recent call last):...
>NameError: global name 'blah' is not defined
>#------------------------

>
The point is that if the object is ill formed, then you get a traceback
regardless.
>
But, as this is an addendum to the other post, please read that first.
>
Now, I really am out of here.
>

Say, who *was* that masked man? ...

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 the Internet
Many services currently offer free registration
----------- Thank You for Reading -------------