RE: c[:]()
> >> c[:] holds many behaviors that change dynamically. > > > > I've absolutely no clue what that sentence means. If c[:] does > > behave differently than c, then somebody's done something > > seriously weird and probably needs to be slapped around for > > felonious overriding. I'm still a bit new at this, was wondering why c[:]() doesn't work, and implicitly wondering why it *shouldn't* work. > >> So c[:]() -- or the more recent go(c)() -- executes all those > >> behaviors. Oops meant to say do(c)(), not "go", which matches a prior post. > > Still no clue. > > > >> This is very useful for many performers. > > > > What are "performers"? Real people, like musicians, and their proxies in code that passes around real-time events that may be rendered, recorded, and played back. > >> The real world example that I'm working one is a collaborative > >> visual music performance. So c can contain wrapped MIDI events > >> or sequencer behaviors. c may get passed to a scheduler to > >> execute those events, or c may get passed to a pickler to > >> persist the performance. > > > > I still don't see how c[:] is any different from c. > > > It isn't. The OP is projecting a wish for a function call on a list to > be interpreted as a call on each member of the list with the same > arguments. The all-members slice notation is a complete red herring. Just looked up "red herring wiki" hope I wasn't being misleading -- at least not intentionally. c[:] is the simplest case for a broad range of behaviors. Perhaps, I should have said c[selector()]() ??? but, no, that makes the question more complex ... still > It would require a pretty fundamental re-think to give such a construct > sensible and consistent semantics, I think. What do you mean? If c[:]() works, the so does this, using real world names orchestra[:].pickle() orchestra[conductor()].sequence() Though, I'm already starting to prefer: do(orchestra).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? -- http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Wildemar Wildenburger wrote:
> This may be a nice
> idea for the Next Overwhelming Programming Escapade (Codename: NOPE)
> ...
> You may want to elaborate on the "new way to think about names". Maybe
> you have a point which I just don't see.
Is it considered pythonic to LOL?
Nietzsche would love NOPE ... and so would his psychiatrist.
Nope, I'm proposing: "Yo! Extend that Python" (Codename: YEP)
I'm treating classes as nested dictionaries. Not *all* classes; only the
ones that I want to use and code from a cell phone.
I've been porting a scripting language, that was written in C++ to Python.
It allows declare a structure like this:
mouse
position x,y
button
left x,y
right x,y
and pipe the whole tree to a recorder, like this:
record << mouse//
which is like doing this:
record << [mouse.position.x,
mouse.position.y,
mouse.button.left.x,
mouse.button.left.y,
mouse.button.right.y,
mouse.button.right.y]
So, how is this related to the addinfourl example? It isn't. At least, not
for rewriting old API. But for fresh APIs, add.info.url() forces you to
think about names, and functionality in a fine grained way. This translates
roughly to:
class add(object)...
class info(object)...
class url(object)...
or as a dict:
{'add' : { 'info': 'url' { ...
Then it becomes easier to think about decorators, generators, and closures
in a way that is quite amorphous. (Though slow?)
Tschüs,
\~/
--
http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
Quotes out of context with mistaken assumptions, now follow: > So c[:]() -- or the more recent go(c)() -- executes all those > behaviors. > > No it doesn't. See below. > > > > If c[:]() works, the so does this, using real world names > > > > orchestra[:].pickle() > > orchestra[conductor()].sequence() > > > > Though, I'm already starting to prefer: > > > > do(orchestra).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 > (, ) > >>> c[:] > (, ) > >>> c[0]() > A > >>> c[1]() > B > >>> c() > Traceback (most recent call last): >File "", line 1, in > TypeError: 'tuple' object is not callable > >>> c[:]() > Traceback (most recent call last): >File "", line 1, in > 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 -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> > What?!? I started this thread. > > > No you didn't. Your original post was a reply to a message whose subject > line was 'Re: "is" and ==', and included the header > > In-Reply-To: <[EMAIL PROTECTED]> 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, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> > I did not hijack another thread > > You really did. In the first message you sent, we see the following > header: > > > In-Reply-To: <[EMAIL PROTECTED]> ... Damn! I suck. Outlook as a newsreader sucks. I need to use something else. > 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] > > > 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 They were copied from working code. Copied *badly*? Yes. Running python via: Windows -> start -> run -> python doesn't allow cut and paste Here is what I tested, now cut and past from visual studio IDE # def a(): print 'a' def b(): print 'b' c = (a,b) c[:]() # typeError c[0]() # expected c[:][0]() # huh? [i() for i in c] # too long and ...huh? #-- Now, I'm extremely annoyed at my own original post, for misleading typos. Yeah, Mikael's example is really cool! And I followed his suggestion of making it cellphone friendly by shorting the name, like so: #-- 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 = do() c = [a,b] do(c[:])() do(c)() #-- I prefer that last line, because [:] is very expensive to type from a cell phone. In summary: Sorry about the hijacked thread Sorry about the typos Outlook is an odd newsreader Mikael's solution works No PEP needed for this example Now, if I could only could do this: do(orchestra(conductor)).play() Cheers, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
As mentioned a while back, I'm now predisposed towards using `do(c)()` because square brackets are hard with cell phones. The one mitigating factor for more general use, outside of cell phones, is speed. If a PEP enables a much faster solution with c[selector()]() then it may be worthwhile. But, I feel a bit circumspect about suggesting a change as I haven't looked at Python source, nor have I looked at the BNF, lately. I think Martelli's recent post on implantation may be relevant: > Tuples are implemented as compact arrays of pointer-to-PyObject (so are > lists, BTW). So, for example, a 10-items tuple takes 40 bytes (plus a > small overhead for the header) on a 32-bit build, not 80 as it would if > implemented as a linked list of (pointer-to-object, pointer-to-next) > pairs; addressing sometuple[N] is O(1), NOT O(N); etc, etc. The questions about implementing a working c[:]() are: 1) Does it break anything? 2) Does it slow anything down? 3) Could it speed anything up? 4) Does it make code easier to read? 5) What question(s) did I forget to ask? 1) No? The fact that c() currently fails on a container implies that enabling it would not break existing client code. Would this break the language definition? A couple years ago, I hand transcribed the BNF of version 2.2 to an alternative to BNF. I would love to know if c[:]() would break the BNF in a fundamental way. 2) I don't know. I've always assumed that Python objects are hash table entries. How would this change? Would it change? Does the message "TypeError: 'list' object is not callable" guarantee a short path between bytecode and hash table? Is there some other mitigating factor? 3) Maybe? Does overriding __call__ create any extra indirection? If yes, then I presume that `do(c)()` would be slower the `c[:]()`. I am writing rather amorphous code. This may speed it up. 4) I posit yes. Am I missing something? What idiom does would c[:]() break? This correlates with whether `c[:]()` breaks the language definition, in question 1) Erik Max Francis wrote: > Warren Stringer wrote: > > > I'm still a bit new at this, was wondering why c[:]() doesn't work, and > > implicitly wondering why it *shouldn't* work. > > It does work. It means "make a sliced copy of `c`, and then call it > with no arguments." Functionally that is _no different_ from `c()`, > which means "take `c` and call it with no arguments," because presuming > `c` is a list, `c[:]` makes a shallow copy. > > So if you think `c()` and `c[:]()` should do something different in this > case, you are profoundly confused about Python's semantics of what > objects are, what it means to shallow copy a list, and what it means to > make a function call. That you keep including the slice suggests that > there's something about its meaning that's not yet clicking. I use `c[:]()` because it is unambiguous about using a container > If you really want syntax where a function call on a container calls all > of its elements, then that is trivially easy to do by creating such an > object and overriding its `__call__` method. > > If you're not willing to do that, but still insisting that `c[:]()` > makes sense, then perhaps it would be more advisable to learn more about > Python rather than try to suggest profound changes to the language and > its conventions. You're right. At the same time, version 3 is coming up soon. There is a short window of opportunity for profound changes. Also, my audacious suggestion has spawned illuminating replies. For this instance, I have read about shallow copy, before, but haven't been told where it is used, before now. Other posts led to insights about closures, and yielding a real solution. This is incredibly useful. I've learned a lot. Thanks, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
Steve Holden Wrote > The general rule in Python is that you provide the right objects and > expect error tracebacks if you do something wrong. So I don't really see > why you feel it's necessary to "[be] unambiguous about using a > container" when you don't appear to feel the same about its containing > only functions. Give that everything is a first class object "Look ma! I'm an object"() # causes Traceback (most recent call last) ... TypeError: 'str' object is not callable def funky(): lookma() funky() # causes Traceback (most recent call last)... NameError: global name 'lookma' is not defined Means that any exception can be caught, thus equal. `c[:]()` is unambiguous because: def c(): print 'yo' c() # works, but c[:]() # causes: Traceback (most recent call last)... c[:]() # causes: TypeError: unsubscriptable object There are many `c()` to be found in the wild and no `c[:]()`, thus unambiguous. To be honest, I wasn't sure, until testing this, just now. > > You're right. At the same time, version 3 is coming up soon. There is a > > short window of opportunity for profound changes. > > > Which closed at the end of April as far as PEPs affecting the initial > implementation of version 3 was concerned. The python3000 and > python-ideas lists are the correct forum for those issues, though you > will of course get all sorts of opinions on c.l.py. Oh well. Perhaps I can relax and actually write functioning code ;-) What do you mean by 'c.l.py' ? The first thing that comes to mind is 'clippy' that helpful little agent in Word that helped pay for Simonyi's trip into space. Ching ching, Warren -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> 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 "", line 1, in ? > TypeError: 'str' object is not callable Interesting example. By extension #- >>> def c(): print 'yo' ... >>> c >>> c(bad) Traceback (most recent call last): File "", 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. -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> Warren Stringer wrote: > > > As mentioned a while back, I'm now predisposed towards using `do(c)()` > > because square brackets are hard with cell phones. The one mitigating > factor > > for more general use, outside of cell phones, is speed. > > 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. > 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. -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> 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 -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> > [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? -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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. -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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. -- http://mail.python.org/mailman/listinfo/python-list
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. > > py> class CallableList(list): > ... def __call__(self): > ... for item in self: > ... item() > ... > py> def a(): print "a" > ... > py> def b(): return 4 > ... > py> def c(): pass > ... > py> def d(): > ... global z > ... z = 1 > ... > py> z="A" > py> x = CallableList([a,b,c,d]) > py> x() > a > py> z > 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. -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> "Marc 'BlackJack' Rintsch" <[EMAIL PROTECTED]> wrote in message > news:[EMAIL PROTECTED] > || 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, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
Roland Puntaier [mailto:[EMAIL PROTECTED] > Warren, can you please restate your point. Hey Roland, where were you a few days ago ;-) I think most suggestions were valid, in their own context. Only yesterday, was I finally able to get it in perspective, so here goes: There are two idioms: a domain specific language, called Tr3 http://muse.com/tr3/Tr3%20Overview.pdf , and Python. The idioms both complement each other and conflict. Most of this thread has explored that conflict. Tr3 has three main components: a namespace tree, a directed graph of inputs and a directed graph of outputs. By analogy: the namespace functions like XML, inputs function like callbacks, and outputs function like standard procedures. The precursor to Tr3 was written C++. The inputs were script while the outputs were in C++. So, any changes in procedure required a recompile. The new version still allows C++ plugins, but the procedures can be written in Python. Inputs to Tr3 are queries to other parts of the namespace. By analogy, inputs behave like an Xpath query. So `a//z` searches for all descendants of `a` named `z`. The results of a query yields a list that can change state for the node on the tree which made the query. Another example, more in line with the title of this thread, is the query `a[:4]b`, which returns a list `[a[0].b, a[1].b, a[2].b, a[3].b]` Outputs are Python. This thread was my way of exploring to what degree that the `a[:4]b` of inputs could be applied to outputs as `a[:4]b()`. It would be idiomatic to Tr3 but not as idiomatic to Python. Here's why: What should this mean? if a[:4]b(): . Should it mean: if a[0].b() and a[1].b() and a[2].b() and a[3].b(): . or if a[0].b() or a[1].b() or a[2].b() or a[3].b(): . or if a[0].b(): . if a[1].b(): . if a[2].b(): . if a[3].b(): . Each interpretation could be justified. Thus, the implicit iteration is ambiguous. I am porting code that only uses this form a[:4]b() Which translates to: for i in range(4): a[i].b() There is only one interpretation and thus unambiguous. I have also explored writing client code that interprets `a[:4]b` as: if a[0].b() and a[1].b() and a[2].b() and a[3].b(): . A few algorithms, like Huffman codes, wind up looking much simpler, with implicit iterators. Be that as it may, making such algorithms easier to read may not be worth the cost of adding ambiguity to a general purpose procedural language. So, you're all right. Relax. Get outdoors. Fall in love. Make someone happy. And thanks again, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
': .' means ': ...' (its an outlook thing) -- http://mail.python.org/mailman/listinfo/python-list
Hooking exceptions outside of call stack
Here is what I would like to do: # a = Tr3() # implements domain specific language a.b = 1# this works, Tr3 overrides __getattr__ a.__dict__['b'] = 2# just so you know that b is local a[b] = 3 # I want to resolve locally, but get: Traceback (most recent call last): ... exec cmd in globals, locals ... NameError: global name 'b' is not defined # So far, I've tried capturing exceptions in __getattr__, __setitem__, and __setattr__, with no luck. I do NOT want to put `a[b]=3` inside a try...except block because I want to enable a command line `>>>a[b]=3` Is there a way to hook a NameError exception outside of the call stack? Perhaps, inside Tr3.__init__ ? Is there a way of putting back unhandled NameError exceptions, so that they unwind the stack normally? This is intended for production code. Many thanks! Warren -- http://mail.python.org/mailman/listinfo/python-list
RE: Hooking exceptions outside of call stack
Am still trying to hook a NameError exception and continue to run. After a
few more hours of searching the web and pouring over Martelli's book, the
closest I've come is:
>>> import sys
>>> def new_exit(arg=0):
... print 'new_exit called'
... #old_exit(arg)
...
>>> def hook(type, value, tb):
... print 'hook called with', type
... return
...
>>> sys.excepthook = hook
>>> old_exit = sys.exit
>>> sys.exit = new_exit
>>> a[b]=1 # would like to get new_exit called
hook called with exceptions.NameError
>>>
>>> def test():
... sys.exit()
...
>>> test()
new_exit called
The interactive session is different from running in the IDE (am using
ActiveState's Visual Python) which exits just after the `a[b]=1` without
calling hook.
Am I missing something? Perhaps this is the wrong approach? I want Python to
check a specific set of locals first, before checking globals. For instance:
a.b[c]
will call:
a.__getattr__('b')
but an exception is thrown before:
a.b.__getitem__(c)
Is there a way of intervening as `exec cmd in globals, locals` attempts to
translate 'c' into an object? I thought that trapping a NameError might
work. But now, I'm not so sure.
Many thanks,
\~/
> Here is what I would like to do:
>
> #
> a = Tr3() # implements domain specific language
> a.b = 1# this works, Tr3 overrides __getattr__
> a.__dict__['b'] = 2# just so you know that b is local
> a[b] = 3 # I want to resolve locally, but get:
>
> Traceback (most recent call last): ...
> exec cmd in globals, locals ...
> NameError: global name 'b' is not defined
> #
>
> So far, I've tried capturing exceptions in __getattr__, __setitem__, and
> __setattr__, with no luck. I do NOT want to put `a[b]=3` inside a
> try...except block because I want to enable a command line `>>>a[b]=3`
>
> Is there a way to hook a NameError exception outside of the call stack?
> Perhaps, inside Tr3.__init__ ? Is there a way of putting back unhandled
> NameError exceptions, so that they unwind the stack normally?
>
> This is intended for production code.
--
http://mail.python.org/mailman/listinfo/python-list
RE: Hooking exceptions outside of call stack
> Yes. Python doesn't have restartable exceptions. Perhaps you would like > to take a look at CL or Smalltalk? > > Jean-Paul Hmmm, I wonder if anyone suggest to Philippe Petit, as stepped out 110 stories off the ground, that perhaps he would like to take a look at a different tightrope? Oddly enough, you suggestion regarding "restartable exceptions" turn up a solution: http://www.chneukirchen.org/blog/archive/2005/03/restartable-exceptions.html Oops, wrong language. \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: Ableton Live Python API is out!
Alia Khouri Write > I have been waiting for this ages and it's finally happened! Python > meet Live, Live meet Python! Wow. This is very cool; thanks for the announcement! > I rushed to update http://wiki.python.org/moin/PythonInMusic but lo Thanks for this link, as well. Very useful. -- http://mail.python.org/mailman/listinfo/python-list
RE: Hooking exceptions outside of call stack
Josiah Carlson wrote:
> >>> foo = type(foo)(foo.func_code, d, foo.func_name, foo.func_defaults,
> foo.func_closure)
Wow! I've never seen that, before. Is there documentation for `type(n)(...)`
somewhere? I did find a very useful "Decorator for Binding Constants, by
Raymond Hettinger", that uses this technique.
The calls are made from embedded classes that are constructed on the fly:
class a(object): ...
class b(object): ...
class c(object): ...
for `a.b[c]=1`, a.__getattr__('b') is called but 'c' need to be resolved as
an object before a.b.__getitem__(c) is called. Could a.b.__init__ set
globals so that 'c' gets resolved? Is this global namespace the same as the
`globals()` namespace?
Cheers,
\~/
--
http://mail.python.org/mailman/listinfo/python-list
RE: Hooking exceptions outside of call stack
Hey Josiah,
I just spent a couple hours with your example, and it explains a lot. Some
of your interactive session got garbled, so am reposting your
merged_namespace example, with tweaks:
#-
def merged_namespace(*ns):
try:
__builtins__
namespaces = ns + (globals(),__builtins__.__dict__)
except NameError:
namespaces = ns + (globals(),__builtin__)
ns = {}
for i in reversed(namespaces):
ns.update(i)
return ns
def foo():
print type(globals())
print a.b[c] #works!
return
#--
# was having trouble with embedded classes
# so, I tried this to track down the problem
class a(object):
def __init__(self): print 'init a'
class b(object):
def __init__(self): print 'init b'
class c(object):
def __init__(self): print 'init c'
pass
aa = a() # only prints 'init a', oops
# so, starting with this:
class A(dict):
def __getattr__(self, name):
# here's where a namespace resolver might go
return self[name]
def __getitem__(self,key):
return key # useless, but simple
a = A() # build from scratch
a.__dict__['b'] = A()
a.b.__dict__['c'] = A()
print a.b[a.b.c] # works as expected
#print a.b[c] # NameError: name 'c' is not defined
#-
# back to Josiah's example
ns = merged_namespace(a.b.__dict__)
foo2 = type(foo)(foo.func_code, ns, foo.func_name, foo.func_defaults,
foo.func_closure)
foo2()
#-
As I was tracing through merged_namespace, I noticed how large resulting
dict is. Too, bad there isn't an equivalent namespace resolution order, as
the there is for methods (or, is there? Am not sure where/how locals are
managed). Then a tupple could be passed to `foo2 = type(foo)(foo.func_code,
namespace, ...)`
With a mro-style namespace, __getattr__ might be able to change namespaces,
on the fly. Too much of a performance hit? Could be. Fortunately, your
example precludes the performance question. Thanks
"Restartable exceptions", as Jean-Paul Calderone called it, might have
yielded results. But searching on his specific phrase yielded a long
discussion (http://www.python.org/search/hypermail/python-1994q2/0425.html)
that illuminates the implausibility of this approach in Python.
So, am replacing `a.b[c]` with `f(a.b,'c')`. The user still can type
"a.b[c]" but, no longer at the python prompt. Oh well.
Thanks again,
\~/
--
http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Hi Eric, You make a compelling argument for underscores. I sometimes help a visually impaired friend with setting up his computers. I'm wondering about the aural output to you second example: link.set_parse_action(emit_link_HTML) Does it sound like this: link dot set under parse under action space between parens emit under link under HTML jump out Also, does how HTML read? Is it "H T M L" or "cap H cap T cap M cap L" ? How many python programmers can reconfigure their speech-to-text and text-to-speech converter? Isn't there a Python based accessibility project? Perhaps a few lines of script to add CamelBack support, using an amplitude increase for initial caps and maybe lingering on the initial phoneme for an extra 100 milliseconds. So then, the above example would read: "camel link dot set Parse Action between parens emit Link H T M L jump out" Warren Eric S. Johansson wrote or said: > link.setParseAction(emitLinkHTML) > > is spoken > > no caps link dot set no space cap parser no space cap action between > parens emit no space cap link HTML jump out > > on the other hand, > > link.set_parse_action (emit_link_HTML) > -- http://mail.python.org/mailman/listinfo/python-list
c[:]()
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!" -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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: [EMAIL PROTECTED] [mailto:python-list- > [EMAIL PROTECTED] On Behalf Of Carsten Haese > Sent: Wednesday, May 30, 2007 12:55 PM > To: [email protected] > 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
RE: c[:]()
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: [EMAIL PROTECTED] [mailto:python-list- > [EMAIL PROTECTED] On Behalf Of Brian van den Broek > Sent: Wednesday, May 30, 2007 3:00 PM > To: [email protected] > 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: [EMAIL PROTECTED] [mailto:python- > list- > >> [EMAIL PROTECTED] On Behalf Of Carsten Haese > >> Sent: Wednesday, May 30, 2007 12:55 PM > >> To: [email protected] > >> 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 -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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...h 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: [EMAIL PROTECTED] [mailto:python-list-
> [EMAIL PROTECTED] On Behalf Of Dustan
> Sent: Wednesday, May 30, 2007 4:14 PM
> To: [email protected]
> Subject: Re: c[:]()
>
> On May 30, 5:37 pm, "Warren Stringer" <[EMAIL PROTECTED]> 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.
>
> --
> http://mail.python.org/mailman/listinfo/python-list
--
http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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
>
--
http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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)]()
h, 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
--
http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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: [EMAIL PROTECTED] [mailto:python-list-
> [EMAIL PROTECTED] On Behalf Of Mikael Olofsson
> Sent: Thursday, May 31, 2007 1:52 AM
> To: [email protected]
> 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
--
http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
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. H... 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?) -- http://mail.python.org/mailman/listinfo/python-list
RE: 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() 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" Cheers, \~/ -- http://mail.python.org/mailman/listinfo/python-list
RE: Is PEP-8 a Code or More of a Guideline?
Perhaps a foot pedal? Hmmm My two cellphones don't like underbars very much. And the shift key -- while much easier -- still is cumbersome. If outlook didn't autocaps on me, this message would be in all lowercase. In fact, when communicating with friends from outlook, to their sms, I take the trouble to correct my outlook's autocorrect. underbars are more of a reach and harder to read when you use a really nice font. camelBack -- damn, I just had to correct outlook's autocorrect on camelback -- so, what was I saying, oh yes -- camelBackNames are just freaking weird. So i.prefer.dots-- no, seriously sure it's slow, but forces you the think about names in a new way. or, perhaps going deep is sacrilege? > -Original Message- > From: [EMAIL PROTECTED] [mailto:python-list- > [EMAIL PROTECTED] On Behalf Of Christophe > Sent: Thursday, May 31, 2007 6:18 AM > To: [email protected] > Subject: Re: Is PEP-8 a Code or More of a Guideline? > > Joe Riopel a écrit :>> Each requires exactly the same number of key > strokes when I do the>> math. (Too lazy to explain further...)> > foo_bar> > f, o, o, shift + underscore, b, a, r = 8> fooBar> f, o, o, shift + b, a, r > = 7 > f, o, o, _, b, a, r = 7f, o, o, shift + b, a, r = 8 > Also the shift+b is much more work than 2 keypresses IMHO. On the other > hand, the underscore is done by pressing the 8 key without any other > modifier which is very easy and accessible. Yeap, french layout rules for > that naming convention :)-- > http://mail.python.org/mailman/listinfo/python-list -- http://mail.python.org/mailman/listinfo/python-list
RE: c[:]()
> 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. -- http://mail.python.org/mailman/listinfo/python-list
