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
81  3537 
In <ma***************************************@python. org>, Warren Stringer
wrote:
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.
What does "enabling c[:]()" mean? Do you expect after "enabling it"
``c()`` and ``c[:]()`` to be different for the same list or tuple `c`?
My use case is this:
do(orchestra(score)).pickle()
do(orchestra(conductor)).sequence()
This isn't a use case unless you also say what the involved objects are
and what semantic you expect from this source snippet. Just guessing,
but might the following do what you want without the need to make lists
and tuples callable?
def do(iterable, func):
for item in iterable:
func(item)
do(orchestra(score), pickle)
do(orchestra(conductor), sequence)
Ciao,
Marc 'BlackJack' Rintsch
In <ma***************************************@python. org>, Warren Stringer
wrote:
>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."
Yes you are right, "pythonic" is not a hard fact. But one indicator is
consistency and no surprising behavior if possible. And that your
insisting on ``c[:]()`` instead of just ``c()`` seems to indicate you want
a change that is quite surprising. It would mean that a slice of a list
returns an other type with the __call__ method implemented.
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?
Grok The Zen of Python (``import this`` at the interpreter prompt)?
Write "pythonic" code?
I don't see how writing other languages and Python parsers and translators
into other representations tells you much about the spirit and idiomatic
*usage* of a language. Your proposal is not about syntax, it's about
semantics. ``obj[:]()`` is basically syntactic sugar for:
``obj.__getitem__(slice(None)).__call__()`` and you want a change in the
implementation of `list.__getitem__()` and `tuple.__getitem__()`.
Ciao,
Marc 'BlackJack' Rintsch
Grant Edwards <gr****@visi.comwrote:
[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.]
One example of such a container is any folderish content in Zope:
subscripting gets you the contained pages, calling renders the default
view.
On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:
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.
Then why do have your users typing code into a cell phone?
--
Carsten Haese http://informixdb.sourceforge.net
On Fri, 2007-06-01 at 08:39 -0400, Carsten Haese wrote:
On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:
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.
Then why do have your users typing code into a cell phone?
_.replace("do", "do you")
self.drink(coffee)
--
Carsten Haese http://informixdb.sourceforge.net
On 2007-06-01, Carsten Haese <ca*****@uniqsys.comwrote:
On Fri, 2007-06-01 at 02:19 -0700, Warren Stringer wrote:
>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.
Then why do have your users typing code into a cell phone?
I've decided the guy is trolling. Most of what he says is just
nonsense.
--
Grant Edwards grante Yow! Xerox your lunch
at and file it under "sex
visi.com offenders"!
On 2007-06-01, Warren Stringer <wa****@muse.comwrote:
I like your use case. Am I correct in assuming that `y = x[:];
y()` is NOT to be found in working code?
No, you may not assume that.
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.
I've already explained such a use case.
You still seem to be operating under the delusion that c[:] is
somehow different than c.
--
Grant Edwards grante Yow! I'm imagining a surfer
at van filled with soy sauce!
visi.com
This discussion has gone in more circles than Earth has gone 'round
the Sun, but it seems you should consider the following:
1) Sequences and functions serve fundamentally different purposes in
Python. One is for containing objects, the other is for executing an
action. (And yes, I'm aware that these concepts can differ in other
contexts. But we're talking about Python.)
2) It seems--at least to me--a bit dubious to change an entire general
purpose programming language to suit a very limited--and frankly
strange--use case.
3) You'd probably be better off making a very simple and concise
domain specific language.
You could do whatever you want with syntax--in the case of a cell
phone, I would think the less punctuation you have, the better. Your
main goal seems to be speed or ease of input, so perhaps a very
abbreviated syntax would be more important than being able to read the
code as if it were English, as is the case in Python--the tradeoff
here being more time spent reading documentation and more time spent
learning syntax. You also might stand to benefit from this move if you
ever decide to implement this software in something other than Python.
Specifically, not requiring parentheses for function calls would
probably be a nice start, and very short built-in names might also be
helpful. Again, this is a tradeoff between readability and speed of
input.
You'd also have to spend more time implementing a parser of some sort.
This could very well outweigh any benefits involved, depending on your
time frame.
But to reiterate the most obvious point: in your context, [:] is just
notation for copying a sequence, so c[:]() would have *exactly* the
same effect as c(). If it helps, you can think of [:] being just like
writing .copy() for dictionaries: it makes a shallow copy, nothing
more. Now think about that while remembering that sequences and
functions serve different purposes in Python and thus have different
semantics. There's a reason this isn't implemented in Python: it would
be confusing beyond belief at first sight. And there's already
perfectly good syntax for this: "for func in funcs: func()"
Being able to write code quickly on a cell phone is not a goal of
Python. That's your goal.
On 5/30/07, Warren Stringer <wa****@muse.comwrote:
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?
And that your
insisting on ``c[:]()`` instead of just ``c()`` seems to indicate you want
a change that is quite surprising. It would mean that a slice of a list
returns an other type with the __call__ method implemented.
I am not insisting on anything. I use ``c[:]()`` as shorthand way of saying
"c() for c in d where d is a container"
Having c() support containers seems obvious to me. It jibes with duck
typing. Perhaps the title of this thread should have been: "Why don't
containers quack?"
A change is surprising only if it breaks something. I still haven't seen any
code that breaks by making such a change. Seeing such code would teach a
great deal.
Grok The Zen of Python (``import this`` at the interpreter prompt)?
I think this is incredibly cool.
Write "pythonic" code?
Probably not yet; I'm still learning - I have yet to perfect my silly walk. http://grampyshouse.net/cliches/images/sillywalk.jpg
[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.]
One example of such a container is any folderish content in Zope:
subscripting gets you the contained pages, calling renders the default
view.
Cool. Could you point me to some example code?
On 6/1/07, Warren Stringer <wa****@muse.comwrote:
And that your
insisting on ``c[:]()`` instead of just ``c()`` seems to indicate you want
a change that is quite surprising. It would mean that a slice of a list
returns an other type with the __call__ method implemented.
I am not insisting on anything. I use ``c[:]()`` as shorthand way of saying
"c() for c in d where d is a container"
The problem people are having with that is that c[:]() *already* means
something in python, and it doesn't mean "c() for c in d where d is a
container". In today's python c[:]() means "return a slice of object
c, then call that slice". Since most container objects don't have a
__call__() method, it doesn't do what you want, but it is currently
valid syntax.
--
Jerry
Thanks, Dakz for taking the time to reply:
This discussion has gone in more circles than Earth has gone 'round
the Sun, but it seems you should consider the following:
Yes, I've been feeling a bit dizzy
1) Sequences and functions serve fundamentally different purposes in
Python. One is for containing objects, the other is for executing an
action. (And yes, I'm aware that these concepts can differ in other
contexts. But we're talking about Python.)
I guess I've been arguing for fewer semantics, not more
2) It seems--at least to me--a bit dubious to change an entire general
purpose programming language to suit a very limited--and frankly
strange--use case.
Agreed.
3) You'd probably be better off making a very simple and concise
domain specific language.
Hence: http://muse.com/tr3/Tr3%20Overview.pdf
I'm going to take Steve Holden's advice and hang out at c.l.py
Cheers,
\~/
On 2007-06-01, Warren Stringer <wa****@muse.comwrote:
>And that your insisting on ``c[:]()`` instead of just ``c()``
seems to indicate you want a change that is quite surprising.
It would mean that a slice of a list returns an other type
with the __call__ method implemented.
I am not insisting on anything. I use ``c[:]()`` as shorthand
way of saying "c() for c in d where d is a container"
Once again, that's gibberish. Where does "d" come from? c[:]()
and c() _ARE_THE_SAME_THING_. c[:]() is another way of saying
c() PERIOD. "d" doesn't enter into it, and by no stretch of
the imagination is c[:]() "shorthand" for c() since it's
_twice_as_long_.
Having c() support containers seems obvious to me.
Again, that sentence appears to me to be meaningless. "c()"
doesn't "support" anything. "c()" is just syntax that says to
invoke the __call__ method of the object to which the name "c"
is bound.
It jibes with duck typing.
To what does "it" refer?
Perhaps the title of this thread should have been: "Why don't
containers quack?"
I'm not sure where you're getting your vocabularly, but it
seems to be completely foreign.
A change is surprising only if it breaks something. I still
haven't seen any code that breaks by making such a change.
Seeing such code would teach a great deal.
If I show you some, will that make you happy?
--
Grant Edwards grante Yow! Where does it go when
at you flush?
visi.com
On 2007-06-01, Warren Stringer <wa****@muse.comwrote:
>This discussion has gone in more circles than Earth has gone
'round the Sun, but it seems you should consider the
following:
Yes, I've been feeling a bit dizzy
No comment.
>1) Sequences and functions serve fundamentally different purposes in
Python. One is for containing objects, the other is for executing an
action. (And yes, I'm aware that these concepts can differ in other
contexts. But we're talking about Python.)
I guess I've been arguing for fewer semantics, not more
What does that mean? The words you type are English, and the
grammar is OK, but the sentences don't seem to _mean_ anything.
>2) It seems--at least to me--a bit dubious to change an entire general
purpose programming language to suit a very limited--and frankly
strange--use case.
Agreed.
>3) You'd probably be better off making a very simple and concise
domain specific language.
Hence: http://muse.com/tr3/Tr3%20Overview.pdf
I'm going to take Steve Holden's advice and hang out at c.l.py
Oh, for Pete's sake, you ARE in c.l.py. [You may be reading it
via an e-mail gateway, but reading it via an NNTP server isn't
going to make any difference.]
--
Grant Edwards grante Yow! MY income is ALL
at disposable!
visi.com
En Fri, 01 Jun 2007 14:22:29 -0300, Warren Stringer <wa****@muse.com>
escribió:
I am not insisting on anything. I use ``c[:]()`` as shorthand way of
saying
"c() for c in d where d is a container"
I begin to think you are some kind of Eliza experiment with Python
pseudo-knowledge injected.
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(list):
.... 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
--
Gabriel Genellina
On 2007-06-02, Gabriel Genellina <ga*******@yahoo.com.arwrote:
En Fri, 01 Jun 2007 14:22:29 -0300, Warren Stringer <wa****@muse.com>
escribió:
>I am not insisting on anything. I use ``c[:]()`` as shorthand
way of saying "c() for c in d where d is a container"
I begin to think you are some kind of Eliza experiment with
Python pseudo-knowledge injected.
I wish I'd said that.
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(list):
... def __call__(self):
... for item in self:
... item()
Now all we need are user-definable
matched-pair-delimiter-constructors for anonymous user-classed
objects. ;)
--
Grant Edwards grante Yow! I smell a RANCID
at CORN DOG!
visi.com
Gabriel wrote:
I begin to think you are some kind of Eliza experiment with Python
pseudo-knowledge injected.
Tell me more about your feelings that I am an Eliza experiment with Python
with pseudo knowledge injected.
Thanks for the code example.
2007/6/1, Warren Stringer <wa****@muse.com>:
I am not insisting on anything. I use ``c[:]()`` as shorthand way of saying
"c() for c in d where d is a container"
Having c() support containers seems obvious to me. It jibes with duck
typing. Perhaps the title of this thread should have been: "Why don't
containers quack?"
A change is surprising only if it breaks something. I still haven't seen any
code that breaks by making such a change. Seeing such code would teach a
great deal.
I think it very much bites duck typing. Currently, if I try to execute
a string or a list or whatever, I get:
TypeError: 'str' object is not callable
But under your proposed semantics, suppose a is a list with some
executable and some non-executable elements. What should
a()
now give? It cannot be a TypeError, because a list (in your semantics)
is callable. Whatever error it gives, and whether or not the preceding
executables are executed first, it will not be an existing error
acting the way it normally does - 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". And that does not seem to be a case of "We have
never needed it yet" - the join method seems to have been specifically
tailored so that no such error is needed.
--
Andre Engels, an*********@gmail.com
ICQ: 6260644 -- Skype: a_engels
I am a relative newbie to Python and certainly to this mailing list. I
have watched this thread with interest. After the first few exchanges I
thought it would prove interesting and it has.
Warren Stringer is one of two things:
A joker having some fun at your expense.
An intellectually pretentious person who is so self absorbed that he is
mentally incapable of seeing the hollowness of his ideas.
Either way it's probably not worth spending any more time on him. All
that needs to be said has been. This thread is bare.
Exit
Bruce Coram
2007/6/1, Warren Stringer <wa****@muse.com>:
>I am not insisting on anything. I use ``c[:]()`` as shorthand way of saying
"c() for c in d where d is a container"
Having c() support containers seems obvious to me. It jibes with duck
typing. Perhaps the title of this thread should have been: "Why don't
containers quack?"
A change is surprising only if it breaks something. I still haven't seen any
code that breaks by making such a change. Seeing such code would teach a
great deal.
I think it very much bites duck typing. Currently, if I try to execute
a string or a list or whatever, I get:
TypeError: 'str' object is not callable
But under your proposed semantics, suppose a is a list with some
executable and some non-executable elements. What should
a()
now give? It cannot be a TypeError, because a list (in your semantics)
is callable. Whatever error it gives, and whether or not the preceding
executables are executed first, it will not be an existing error
acting the way it normally does - 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". And that does not seem to be a case of "We have
never needed it yet" - the join method seems to have been specifically
tailored so that no such error is needed.
Andre Engels wrote:
I am not insisting on anything. I use ``c[:]()`` as shorthand way of
saying
"c() for c in d where d is a container"
Having c() support containers seems obvious to me. It jibes with duck
typing. Perhaps the title of this thread should have been: "Why don't
containers quack?"
A change is surprising only if it breaks something. I still haven't seen
any
code that breaks by making such a change. Seeing such code would teach a
great deal.
I think it very much bites duck typing. Currently, if I try to execute
a string or a list or whatever, I get:
TypeError: 'str' object is not callable
But under your proposed semantics, suppose a is a list with some
executable and some non-executable elements. What should
a()
now give? It cannot be a TypeError, because a list (in your semantics)
is callable. Whatever error it gives, and whether or not the preceding
executables are executed first, it will not be an existing error
acting the way it normally does ...
Since `a()` translates to `a() for a in b` then the error would be the exact
same `TypeError: 'str' object is not callable`
- 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
#------------------------
And that does not seem to be a case of "We have
never needed it yet" - the join method seems to have been specifically
tailored so that no such error is needed.
The join example is pretty cool - I want to study it a bit more - maybe I'm
missing your point?
There are two domain discussions, here:
1) is c[:]() is a good idea for python
2) is c[:]() a good idea in general
Where c[:]() symbolizes [c() for c in a]
In my opinion:
1a) might break something in Python 2.x -
1b) may or may not be a good idea for Python 3K
2a) is a great idea for a specific range of applications
2b) should attempt to coincide with existing idioms
Pragmatically speaking:
I'm not interested in 1a because it may break something. There may be an
edge case where catching a `TypeError: 'str' object is not callable` may
change the behavior of existing code.
I am somewhat interested in 1b but intend to lurk on the python.ideas and
python3k lists before entering a discussion. I tend to shy away from
proposing changes from ignorance. This is QUITE DIFFERENT from asking WHY
something works a certain way. Consider people who ask dumb questions, like
me, to be an opportunity to discover what isn't obvious.
I am intensely interested in 2a. Specifically visual music performances over
the web. I have spent 7 full years and my life's savings on developing a
platform. This particular application will involve millions of simultaneous
events that get passed around as objects. Two of those years have been spent
on developing a domain specific language that needs a very fast `c[:]()` --
which relates to 1b.
I am very interested in 2b. The two most inspiring languages to me are
Python and Occam (a now defunct language Transputers) Both use lexical
indentation. Although I am building a domain specific language I want make
it seamlessly integrate with Python. So that a 12-year-old may start by
patching performances, but ultimately, she may become inspired in writing
python script.
So, this thread has been of keen interest to me, mostly because of 2b. 1b is
of interest because extending Python with C has historically required
separate distributions between various versions of 2.x
So, Andre, you and others have a point, in regards to 1a. I find your post
particularly interesting, because it points out some history with join,
which helps me better understand how to approach 2b.
It wasn't my intent to ruffle feathers, but that in its own regard is
instructive, both in the topic, at hand, and in regard to the Python
community.
Meanwhile, I have written very little code, in the last couple days. It
means that I've taken everyone's suggestions very seriously, often leading
me to blogs and blogs of blogs. Looking back, there have been a couple of
helpful suggestions that I didn't respond to directly. So, for them, my
apologies and thanks!
For now, I am out of here!
Cheers,
\~/
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.
On Sat, 02 Jun 2007 11:25:04 -0700, Warren Stringer wrote:
Since `a()` translates to `a() for a in b` then the error would be the exact
same `TypeError: 'str' object is not callable`
Not in any language called Python I know of.
Supposedly 28 years programming experience, and you can't even see the
_serious_ problems with "a()" --"a() for a in b". Well, that explains a
lot about the lousy state of so many programming projects.
What's b? Given "a()", how does the compiler identify which b is the one
to look at? How does the recursive reference to a() terminate?
[snip]
For now, I am out of here!
Please don't come back until you have a clue.
--
Steven.
On 30 , 22:48, "Warren Stringer" <war...@muse.comwrote:
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]
#------------------------------------------
bla-bla-bla......
you can write:
>>map(lambda x: x(), c)
I think that it is good idea to use "map()" function for doing
somethimg with each element of a sequence, if the order of a actions
not important.
it is easy to read and understandable.
P.S. sorry my bad English
In <11**********************@q75g2000hsh.googlegroups .com>, St*******@gmail.com wrote:
On 30 , 22:48, "Warren Stringer" <war...@muse.comwrote:
>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]
#------------------------------------------
bla-bla-bla......
you can write:
>>>map(lambda x: x(), c)
I think that it is good idea to use "map()" function for doing
somethimg with each element of a sequence, if the order of a actions
not important.
it is easy to read and understandable.
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.
Ciao,
Marc 'BlackJack' Rintsch
On 3 , 18:44, Marc 'BlackJack' Rintsch <bj_...@gmx.netwrote:
In <1180878080.630213.258...@q75g2000hsh.googlegroups .com>,
bla-bla-bla
it is easy to read and understandable.
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.
Ciao,
Marc 'BlackJack' Rintsch
functoins can return a values, and you get it. I don't think that it
is bad side effect.
When you write simple
>>def a(): print "From Russia with love."
a()
you have side effect too - returning "None".
In <11*********************@k79g2000hse.googlegroups. com>, St*******@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
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(list):
... 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(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])()
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,None]
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.
"Marc 'BlackJack' Rintsch" <bj****@gmx.netwrote in message
news:pa****************************@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
"Marc 'BlackJack' Rintsch" <bj****@gmx.netwrote in message
news:pa****************************@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",'exec')
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.straight()
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,
\~/
Warren Stringer wrote:
demo4: demo.stop()
ball.smooth()
video.live()
preset.video.straight()
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 && ma*@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
"Warren Stringer" <wa****@muse.comwrote in message
news:00b301c7a690$25af37d0$240110ac@Muse...
|"Marc 'BlackJack' Rintsch" <bj****@gmx.netwrote in message
| news:pa****************************@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
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 ------------- This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: Bjorn |
last post by:
Hi,
I need to determine the hightest date between e.g. "8/3/2004" and
"8/4/2004".
With this code, i get 'dat2' , which means that "8/4/2004" is higher than
"8/3/2004". That 's right.
But with...
|
by: Phil |
last post by:
Hi everybody,
I am a XSLT beginner and the following problem really makes me crazy !
I have a main "contacts.xml" document which contains references to
several contact data XML files.
My aim...
|
by: Ajax Chelsea |
last post by:
can not the "static const int" be replaced by "static enum" anywhere?
is it necessary that define special initialization syntax for "static const int"?
|
by: Joseph Turian |
last post by:
Fellow hackers,
I have a class BuildNode that inherits from class Node.
Similarly, I have a class BuildTree that inherits from class Tree.
Tree includes a member variable:
vector<Node>...
|
by: hjbortol |
last post by:
Hi!
Is the expression "a >= b" equivalent to "a - b >= 0" in C/C++?
Is this equivalence an IEEE/ANSI rule? Or is this machine/compiler
dependent?
Any references are welcome!
Thanks in...
|
by: Bobby C. Jones |
last post by:
Is there an advantage to either of these methods, or is it simply a matter
of style? I used to use the "as" method, but later gave it up for the "is"
method as the intent of the code seems a...
|
by: jht5945 |
last post by:
For example I wrote a function:
function Func()
{
// do something
}
we can call it like:
var obj = new Func(); // call it as a constructor
or
var result = Func(); // call it as...
|
by: craigkenisston |
last post by:
I can't believe what is happening on my computer right now.
I have a web project, file-system based on something like
c:\Projects\ProjectX\www\.
I had to make some changes and testing in a...
|
by: Dullme |
last post by:
i can hardly know what is the code for this. I have researched palindromes, but unfortunately, I only have read about integers not for characters..I need some help..
|
by: Zytan |
last post by:
In VB, you use ControlChars.CrLf (or better, ControlChars.NewLine).
In C/C++, we are used to using merely "\n" (or at least I am). It
appears "\n" is good enough for RichTextBoxes. Does it...
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: emmanuelkatto |
last post by:
Hi All, I am Emmanuel katto from Uganda. I want to ask what challenges you've faced while migrating a website to cloud.
Please let me know.
Thanks!
Emmanuel
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
