Re: self.__dict__ tricks
On Friday, 30 October 2009 17:28:47 MRAB wrote: > Wouldn't it be clearer if they were called dromedaryCase and > BactrianCase? :-) Ogden Nash: The Camel has a single hump- The Dromedary, two; Or the other way around- I'm never sure. - Are You? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against "while True:" loops
On Monday, 19 October 2009 09:43:15 Steven D'Aprano wrote: > On Mon, 19 Oct 2009 08:51:44 +0200, Hendrik van Rooyen wrote: > > The point I was trying to make > > subliminally, was that there is a relative cost of double lookup for all > > cases versus exceptions for some cases. - Depending on the frequency of > > "some", I would expect a breakeven point. > > There is, at least according to my (long distant and only barely > remembered) tests. 8< --- > > under Python 2.5. However, catching an exception is more expensive, > approximately ten times more so. Doing a lookup twice falls somewhere > between the two, closer to the cheap side than the expensive. > > So according to my rough estimates, it is faster to use the try...except > form so long as the number of KeyErrors is less than about one in six, > give or take. If KeyError is more common than that, it's cheaper to do a > test first, say with d.has_key(). Using the `in` operator is likely to be > faster than has_key(), which will shift the break-even point. > > (The above numbers are from memory and should be taken with a large pinch > of salt. Even if they are accurate for me, they will likely be different > on other machines, and will depend on the actual keys in the dict. In > other words, your mileage may vary.) So if you want to sum stuff where there are a lot of keys, but only a few values per key - say between one and ten, then it would be faster to look before you leap. On the other hand, if there are relatively few keys and tens or hundreds of values per key, then you ask for forgiveness. And if you don't know what the data is going to look like, then you should either go into a catatonic state, or take to the bottle, as the zen of python states that you should refuse the temptation to guess. This is also known as paralysis by analysis. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against "while True:" loops
On Sunday, 18 October 2009 11:31:19 Paul Rubin wrote: > Hendrik van Rooyen writes: > > Standard Python idiom: > > > > if key in d: > > d[key] += value > > else: > > d[key] = value > > The issue is that uses two lookups. If that's ok, the more usual idiom is: > > d[key] = value + d.get(key, 0) I was actually just needling Aahz a bit. The point I was trying to make subliminally, was that there is a relative cost of double lookup for all cases versus exceptions for some cases. - Depending on the frequency of "some", I would expect a breakeven point. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against "while True:" loops
On Saturday, 17 October 2009 16:30:55 Aahz wrote: > In article , > > Tim Rowe wrote: > >The point is that an exception causes a change in program flow, so of > >course they're used for flow control. It's what they do. The question > >is in what cases it's appropriate to use them. > > Standard Python idiom: > > try: > d[key] += value > except KeyError: > d[key] = value > > Maybe you need to re-think "appropriate". Standard Python idiom: if key in d: d[key] += value else: d[key] = value Maybe you need to re-think "appropriate". - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: efficient running median
On Tuesday, 13 October 2009 17:22:55 Janto Dreijer wrote: > I'm looking for code that will calculate the running median of a > sequence, efficiently. (I'm trying to subtract the running median from > a signal to correct for gradual drift). > > My naive attempt (taking the median of a sliding window) is > unfortunately too slow as my sliding windows are quite large (~1k) and > so are my sequences (~50k). On my PC it takes about 18 seconds per > sequence. 17 of those seconds is spent in sorting the sliding windows. > > I've googled around and it looks like there are some recent journal > articles on it, but no code. Any suggestions? > Can you not use the mean instead? It is easier to calculate, as you do not have to work through all the values. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: RabbitMQ vs ApacheQpid (AMQP)
On Tuesday, 13 October 2009 11:42:03 jacopo wrote: > > Background: > I have a main machine dispatching heavy calculations to different > machines, collecting the results, performing some calculation on the > merged results and starting all over again with fresher data. I > implemented a first solution with Twisted PB, then I decided it was > more flexible to rely on an AMQP system and I started looking at > RabbitMQ with txAMQP . Now I am getting really frustrated with the > complexity of Twisted and the reactor, I am realizing that probably I > don’t need to handle asynchronicity. Some degree of asynchronicity is > already handled by the Messaging system and I don’t need to take care > of it in my components (they keep waiting for a message, when they get > it they are fully engaged in processing and they cannot do much more). Have you looked at Pyro? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: code in a module is executed twice (cyclic import problems) ?
On Sunday, 11 October 2009 02:24:34 Stephen Hansen wrote: > It's really better all around for "modules" to be considered like > libraries, that live over There, and aren't normally executed. Then you > have scripts over Here which may just be tiny and import a module and call > that module's "main" method. Okay, I'm not arguing you should never execute > a module, sometimes its useful and needful-- especially for testing or more > complex project organization. But in general... this is just gonna cause no > end of suffering if you don't at least try to maintain the "script" vs > "module" mental separation. Modules are the principle focus of code-reuse > and where most things happen, scripts are what kickstart and get things > going and drive things. IMHO. > > If not that, then at least make sure that nothing is ever /executed/ at the > top-level of your files automatically; when imported call 'module.meth()' > to initialize and/or get My_List or whatever, and when executed use the > __name__ == "__main__" block to do whatever you want to do when the file is > started as a main script. > > Otherwise, things'll get weird. > > ... gah snip huge write-up I threw in about how we organize our code around > the office. Not important! Your use-case is probably different enough that > you'd surely organize differently. But still, I really recommend treating > "modules" like static repositories of code that "scripts" call into / > invoke / execute. Even if sometimes you execute the modules directly (and > thus use a main() function to run in whatever default way you choose). I have been using the __name__== "main" part of what you call modules to do the test code for the module. So if you execute it at the top level, it does its testing, and if you import it, it is like a library. This works for me, but it is probably not of general use - the stuff we do tends to be smallish and long running. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The rap against "while True:" loops
On Saturday, 10 October 2009 22:15:21 kj wrote: > I'm coaching a group of biologists on basic Python scripting. One > of my charges mentioned that he had come across the advice never > to use loops beginning with "while True". Of course, that's one > way to start an infinite loop, but this seems hardly a sufficient > reason to avoid the construct altogether, as long as one includes > an exit that is always reached. (Actually, come to think of it, > there are many situations in which a bona fide infinite loops > (typically within a try: block) is the required construct, e.g. > when implementing an event loop.) > > I use "while True"-loops often, and intend to continue doing this > "while True", but I'm curious to know: how widespread is the > injunction against such loops? Has it reached the status of "best > practice"? Others have given various valid answers, but I have not seen this one: It is often necessary, in long running applications, to set up loops that you would really like to run until the end of time. - the equivalent of a "serve forever" construct. Then while True is the obvious way to spell it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is there a better way to code variable number of return arguments?
On Thursday, 8 October 2009 18:41:31 Dr. Phillip M. Feldman wrote: > I currently have a function that uses a list internally but then returns > the list items as separate return > values as follows: > > if len(result)==1: return result[0] > if len(result)==2: return result[0], result[1] > > (and so on). Is there a cleaner way to accomplish the same thing? Why do you not change the list into a tuple and return the tuple, and let automatic unpacking handle it? As I see it, the problem is not in the return, but in the call - how do you know now, which of the following to write: answer = thing(params) answer0,answer1 = thing(params) answer0,answer1,answer2 = thing(params) answer0,answer1,answer2,answer3 = thing(params) and so on... probably best to write: answers = thing(params) for answer in answers: do something with answer - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: No threading.start_new_thread(), useful addition?
On Thursday, 8 October 2009 13:24:14 Christian Heimes wrote: > Laszlo Nagy wrote: > > But really thread.start_new_thread is better: > > > > import thread.start_new_thread as thr > > > > thr(my_function,arg1,arg2) > > Please don't use the thread module directly, especially the > start_new_thread function. It a low level function that bypasses the > threading framework. The is no good reason to use this function in favor > of threading.Thread(). I have seen this advice a couple of times now, and I do not understand it. >From my perspective (which is admittedly jaundiced) Threading just adds a bunch of superfluous stuff like a run method and other weird things that I cannot see a need for. The simplicity of this kind of code: def this_is_a_thread(arg1,arg2): do_some_initialisation(arg1,arg2) while some_condition: do_some_stuff() which then gets started with thread.start_new_thread, does it for me. What does the Threading module buy me, other than a formal OO approach? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Tkinter -- the best way to make a realtime loop
On Thursday, 8 October 2009 00:40:42 J Wolfe wrote: > What's the best way to make a realtime loop in Tkinter? I know in > perl you can use "repeat" and it will call a function every x seconds, > in python it seems like "after" may be the equivalent though it > doesn't seem to behave like the perl repeat function. Any ideas? What do you mean by "real time"? The after method in tkinter will call the routine after the specified time. If you want to do it again, you must arrange for the routine to call itself again with a further after. So it is perfectly possible to make a stutter thread that executes periodically. In which way does this not work for you? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Skeletal animation
On Monday, 5 October 2009 00:05:21 Manowar wrote: > I am new to pyton and have asked this question several times the > answer is always not sure. > Here is my question sekeltal animation ( bone animation) is it > possible with python? What i want to develop is an aquarium in > realtime, skeletal animation, all the movements will be from > programming., no keyframes let me know if it is possible with python Sure - you can draw anything on a Tkinter canvas, and move it around. Also look at pygame, and PIL - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: creating class objects inside methods
On Sunday, 4 October 2009 08:14:08 horos11 wrote: > Saying that 'whoa, this coding error should be handled by naming > convention' may be the only practical way of getting around this > limitation, but it is a limitation nonetheless, and a pretty big one. You misunderstand the dynamic nature of python - YOU rebound the name to something else - how on earth can the interpreter know that this is not what you meant? Could you formulate a rule that the interpreter should follow to be able to flag what you have done as an error? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Thursday, 1 October 2009 00:27:02 Rhodri James wrote: > I was going to say, you want 256 bytes of RAM, you profligate > so-and-so? Here, have 32 bytes of data space and stop your > whining :-) My multi tasking is coming on nicely, but I am struggling a bit with the garbage collection. The Trash bin gets a bit tight at times, so the extra bytes help a lot when I run more than 500 independent tasks. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Wednesday, 30 September 2009 09:46:38 Paul Rubin wrote: > Getting away from python in the opposite direction, if you click > >http://cufp.galois.com/2008/schedule.html > > the second presentation "Controlling Hybrid Vehicles with Haskell" > might interest you. Basically it's about a high level DSL that > generates realtime control code written in C. From the slides: > > * 5K lines of Haskell/atom replaced 120K lines of matlab, simulink, > and visual basic. > * 2 months to port simulink design to atom. > * Rules with execution periods from 1ms to 10s all scheduled at > compile time to a 1 ms main loop. > * Atom design clears electronic/sw testing on first pass. > * Currently in vehicle testing with no major issues. > > Code is here: http://hackage.haskell.org/package/atom > > Blurb: "Atom is a Haskell DSL for designing hard realtime embedded > programs. Based on conditional term rewriting, atom will compile a > collection of atomic state transition rules to a C program with > constant memory use and deterministic execution time." Awesome! Thank you - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Wednesday, 30 September 2009 04:16:45 Grant Edwards wrote: > Assembler macros are indeed a lost art. Back in the day, I > remember seeing some pretty impressive macro libraries layered > 2-3 deep. I've done assember macros as recently as about 2-3 > years go because it was the easiest way to auto-magically > generate lookup tables for use by C programs (macro assemblers > always have a "repeat" directive, and cpp doesn't). > > > The 803x bit handling is, in my arrogant opinion, still the > > best of any processor. - jump if bit set then clear as an > > atomic instruction rocks. > > The bit-addressing mode was (and still is) cool. However, the > stack implementation hurts pretty badly now that memory is > cheap. > > I shouldn't criticize the 8051. I remember switching from the > 8048 to the 8051 (8751 actually, at about $300 each) and > thinking it was wonderful. [Anybody who remembers fighting > with the 8048 page boundaries knows what I mean.] You were lucky - I started with an 8039 and the 8048 was a step up! You are right about the stack - there are a lot of implementations now with two or more data pointers, which make a big difference. If only someone would build one with a two byte stack pointer that points into movx space, the thing would fly faster again. It would make a stunning difference to the multitasking performance if you do not have to store the whole stack. Of course, if you are mucking around in assembler, then the 128 bytes at the top of the internal memory is often enough. This is getting a bit far away from python and coroutines, though. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: How to pass a global variable to a module?
On Tuesday, 29 September 2009 20:24:53 Mars creature wrote: > >From the link Gregor posted, it seems no way to share variable between > > modules. > > I can understand the point that global variables tends to mess up > programs. > > Assume that I have 10 parameters need to pass to the function. If > these parameters are fixed, I can use another module to store these 10 > parameters, and import to the module, as suggested by jean-michel. But > what if these 10 parameters will be changed in the main program? > Passing the variable to the function as a parameter suggested by Rami > will certainly do, but I am wondering weather there are other ways. > What you'd like to code it? You can put all the 10 things in a file called say my_params.py. Then where you need it, you do either: from my_params import * to make them available where needed, or: import my_params as p and access them as: print p.my_parm_1,p.my_parm_2,p.my_parm_3,p.my_parm_4 - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Monday, 28 September 2009 16:44:48 Grant Edwards wrote: > $10 is pretty expensive for a lot of applications. I bet that > processor also uses a lot of power and takes up a lot of board > space. If you've only got $2-$3 in the money budget, 200uA at > 1.8V in the power budget, and 6mm X 6mm of board-space, your > choices are limited. > > Besides If you can get by with 256 or 512 bytes of RAM, why pay > 4X the price for a 1K part? > > Besides which, the 8032 instruction set and development tools > are icky compared to something like an MSP430 or an AVR. ;) > > [The 8032 is still head and shoulders above the 8-bit PIC > family.] I am biased. I like the 8031 family. I have written pre-emptive multitasking systems for it, as well as state-machine round robin systems. In assembler. Who needs tools if you have a half decent macro assembler? And if the macro assembler is not up to much, then you write your own pre processor using python. The 803x bit handling is, in my arrogant opinion, still the best of any processor. - jump if bit set then clear as an atomic instruction rocks. :-) Where do you get such nice projects to work on? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: os.listdir unwanted behaviour
On Tuesday, 29 September 2009 11:03:17 Tim Chase wrote: > I think Steven may be remembering the conversation here on c.l.p > a month or two back where folks were asking to turn os.listdir() > into an iterator (or create an os.xlistdir() or os.iterdir() > function) because directories with lots of files were causing > inordinate slowdown. Yes, listdir() in both 2.x and 3.x both > return lists while such a proposed iterator version could be > changed on the fly by interim file/directory creation. Is os.walk not the right thing to use for this kind of stuff? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Using String for new List name
On Monday, 28 September 2009 18:54:09 Scott wrote:
> I am new to Python but I have studied hard and written a fairly big
> (to me) script/program. I have solved all of my problems by Googling
> but this one has got me stumped.
>
> I want to check a string for a substring and if it exists I want to
> create a new, empty list using that substring as the name of the list.
> For example:
>
> Let's say file1 has line1 through line100 as the first word in each
> line.
>
> for X in open("file1"):
> Do a test.
> If true:
> Y = re.split(" ", X)
> Z = Y[0] # This is a string, maybe it is "Line42"
> Z = [] # This doesn't work, I want a new, empty
> list created called Line42 not Z.
>
> Is there any way to do this?
Yes
Look at exec and eval
But also look at using the string as a key in a dict.
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Saturday, 26 September 2009 16:55:30 Grant Edwards wrote: > On 2009-09-26, Dave Angel wrote: > > Actually even 64k looked pretty good, compared to the 1.5k of > > RAM and 2k of PROM for one of my projects, a navigation system > > for shipboard use. > > I've worked on projects as recently as the past year that had > only a couple hundred bytes of RAM, and most of it was reserved > for a message buffer. There is little reason to do that nowadays - one can buy a single cycle 8032 running at 30 MHz with 16/32/64k of programming flash and ik of RAM, as well as some bytes of eeprom for around US$10-00. - in one off quantities. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: nested structure with "internal references"
On Friday, 25 September 2009 19:11:06 Torsten Mohr wrote: > I'd like to use a nested structure in memory that consists > of dict()s and list()s, list entries can be dict()s, other list()s, > dict entries can be list()s or other dict()s. > > The lists and dicts can also contain int, float, string, ... This sounds terribly convoluted. What are you trying to do? > > But i'd also like to have something like a "reference" to another > entry. Everything and its brother in Python is an object, and things like lists and dicts reference objects automagically. > I'd like to refer to another entry and not copy that entry, i need to > know later that this is a reference to another entry, i need to find > also access that entry then. Depending on how I read this, it is either trivial or impossible: A name is bound to an object by assignment. An object can have many names bound to it. A name can, at different times, refer to different objects. An object does not know which names are bound to it, or in what sequence it was done. So you can go from name to object, but not the other way around. You can use the same name in a loop to refer to different objects, and in each iteration, use the name to store a reference to the current object in a list or dict. > Is something like this possible in Python? Not too sure what you are trying to do. > The references only need to refer to entries in this structure. > The lists may change at runtime (entries removed / added), so > storing the index may not help. You could start off with a list of lists of lists, to any level of nesting that you want. This will give you a structure like a tree with branches and twigs and leaves, but I am not sure if this is what you want or need, or if a flat structure like third normal form would suffice, or if you need a relational database. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Most "active" coroutine library project?
On Thursday, 24 September 2009 15:42:36 Antoine Pitrou wrote: > Grant Edwards invalid.invalid> writes: > > Back when I worked on one of the first hand-held cellular > > mobile phones, it used co-routines where the number of > > coroutines was fixed at 2 (one for each register set in a Z80 > > CPU). > > Gotta love the lightning-fast EXX instruction. :-) Using it in the above context is about equivalent to slipping a hand grenade in amongst the other eggs in a nest. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: easy question, how to double a variable
On Monday, 21 September 2009 22:50:31 daggerdvm wrote: > carl banks.you are a dork No mister_do_my_homework, he is not. He is actually a respected member of this little community. You, however, are beginning to look like one. Why do you not come clean - tell us what you are doing, show us what you have tried, and maybe, just maybe, some kind soul will help you, instead of mocking you. Although that is now less likely as you have started calling people derogatory names. And if you do not at least do what I have suggested, there is about a snowball's hope in hell of anybody helping you, as you come across as a parasite who wants other people to do his work. Prove you are not, or go away. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: How to change string or number passed as argument?
On Sunday 20 September 2009 03:59:21 Peng Yu wrote: > I know that strings or numbers are immutable when they passed as > arguments to functions. But there are cases that I may want to change > them in a function and propagate the effects outside the function. I > could wrap them in a class, which I feel a little bit tedious. I am > wondering what is the common practice for this problem. You can just ignore the immutability. Nothing stops you doing something like this; def reader(port,buffer): buffer += port.read() return buffer and calling it repetitively until buffer is as long as you want it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Saturday 19 September 2009 09:12:34 greg wrote: > From my own experience, I know that it's possible for me to > think about things that I don't have a word for. An example > occured once when I was developing a 3D game engine, and > I was trying to think of a name for the thing that exists > where two convex polyhedra share a face, except that the > face is missing (it's hard to explain even using multiple > words). Yikes! If I follow you, it is a bit like having a hollow dumb-bell with a hollow handle of zero length, and wanting a word for that opening between the knobs. I do not think that you are likely to find a word in *any* language for that - I would posit that it is too seldom encountered to deserve one. What does a concave polyhedrum look like? *weg* > > I couldn't think of any word that fully expressed the precise > concept I had in mind. Yet I was clearly capable of thinking > about it, otherwise I wouldn't have noticed that I was missing > a word! > > So in my humble opinion, the strong form of the Sapir-Whorf > hypothesis is bunk. :-) That is probably true, but on the other hand, it is not totally rubbish either, as it is hard to think of stuff you have never heard of, whether you have an undefined word for it or not. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re:OT - people eaters - was: An assessment of the Unicode standard
On Friday 18 September 2009 06:39:57 Dennis Lee Bieber wrote:
> A one-eyed, one-horned, flying purple people eater?
>
> {Which brings up the confusing question... Is the eater purple, or does
> it eat purple people (which is why it is so rare... it only eats people
> caught in the last stages of suffocation )}
Snap (sort of).
Does anybody know where the concept of the purple people eater comes from?
I mean is there a children's book or something?
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Thursday 17 September 2009 15:29:38 Tim Rowe wrote:
> There are good reasons for it falling out of favour, though. At the
> time of the Sapir-Whorf hypothesis, anthropologists were arguing that
> members of a certain remote tribe did not experience grief on the
> death of a child because their language did not have a word for grief.
> They showed all the *signs* of grief -- weeping and wailing and so on
> -- and sometimes used metaphors ("I feel as if my inside is being
> crushed"). But because of the conviction at the time that "if your
> language does not have a word for something, and you have never seen
> that object, then you "__cannot__" think about it" the anthropologists
> were convinced that this just looked and sounded like grief and wasn't
> actually grief.
This is kind of convincing, when applied to an emotion like that. The whole
thing is obviously a lot more complicated than the position I have taken
here - if it weren't, then there would be no way for a language to change
and grow, if it were literally true that you cannot think of something that
you have no word for.
>
> By the way, at the moment I am thinking of a sort of purple
> blob-shaped monster with tentacles and fangs, that my language doesn't
> have a word for and that I have never seen. On your theory, how come I
> am thinking about it?
I do not really believe you are thinking about a purple people eater. - you
must be mistaken.
:-)
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Are min() and max() thread-safe?
On Thursday 17 September 2009 12:57:18 Carl Banks wrote: > On Sep 17, 2:18 am, Hendrik van Rooyen > > wrote: > > When running min or max on a list of ints, there is probably no > occasion for the function to release the GIL. If a thread doesn't > release the GIL no other Python threads can run. This behavior may be > rotten, but it's totally expected. The lack of concurrency was not what I was complaining about, but the second case that just quietly freaked out when I made the list of ints large. I have subsequently seen that it is red herring in this context though, as it is some memory problem - the crash comes during the list creation, and has nothing to do with the min/max processing. One can demo it by simply trying to create a big list at the interactive prompt, and after a while you get the "Killed" message. a = range(1) does it for me on my machine. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Are min() and max() thread-safe?
On Thursday 17 September 2009 06:33:05 Steven D'Aprano wrote: > I have two threads, one running min() and the other running max() over > the same list. I'm getting some mysterious results which I'm having > trouble debugging. Are min() and max() thread-safe, or am I doing > something fundamentally silly by having them walk over the same list > simultaneously? > > My code is as follows. Is there anything obviously wrong with it? Apart from the plethora of indirection, nothing I can see. But there is something rotten. Going more basic, look at this: h...@linuxbox:~/Junk> cat jjj.py import thread as th import time a = range(1000) def worker(func,thing): start_time = time.time() print "start time is:",start_time res = func(thing) print res end_time = time.time() print "End at:",end_time,"That took:",end_time-start_time, 'seconds' t1 = th.start_new_thread(worker,(min,a)) t2 = th.start_new_thread(worker,(max,a)) while True: time.sleep(1) h...@linuxbox:~/Junk> python -i jjj.py start time is: 1253176132.64 0 End at: 1253176133.34 That took: 0.700681209564 seconds start time is: 1253176133.34 999 End at: 1253176134.18 That took: 0.84756612 seconds Traceback (most recent call last): File "jjj.py", line 18, in time.sleep(1) KeyboardInterrupt >>> No simultaneity. So when I increase the range to a hundred million to try to force some concurrency, I get: h...@linuxbox:~/Junk> python -i jjj.py Killed h...@linuxbox:~/Junk> The behaviour is that it just thrashes for some minutes and then it looks like the os kills it. SuSe Linux, dual core Intel with a gig of memory: Python 2.5.1 (r251:54863, Dec 6 2008, 10:49:39) [GCC 4.2.1 (SUSE Linux)] on linux2 I enclose the file. - Hendrik jjj.py Description: application/python -- http://mail.python.org/mailman/listinfo/python-list
Fwd: Re: How to improve this code?
>From a private email, forwarded to the list: -- Forwarded Message -- Subject: Re: How to improve this code? Date: Tuesday 15 September 2009 From: Oltmans To: hend...@microcorp.co.za On Sep 15, 1:13 pm, Hendrik van Rooyen wrote: > > (i) a True if All the elements in match are in aList, else False? > (ii) a True if any one or more of the members of match are in aList? > (iii) Something else? That's a good question because I failed miserably in explaining my problem clearly. My original question isn't what I'm trying to solve. My apologies. I will try to explain here clearly. I'm using a 3rd- party library named Selenium (used for web-automation) and it has a method named is_element_present(ele) i.e. takes one element and return true if it finds this element in the page's HTML and returns false otherwise. Given this, I'm just trying to write a method are_elements_present(aList) whose job is to return True if and only if all elements in aList are present in page's HTML. So here is how are_elements_present() looks like def are_elements_present(eleLocators): elePresent=False if not eleLocators: return False for ele in eleLocators: if selenium.is_element_present(ele): elePresent=True else: elePresent=False print 'cannot find this element= '+str(ele) break return elePresent Now suppose page HTML contains with these IDs ( ID is an attribute like ) = div1,div2,div3,div4,div5,inp1,inp2 and if I call the above method this way are_elements_present ([div1,div2,inp1,inp2]) then it should return True. If I call like are_elements_present([div1,div2,div10,inp1]) it should return False. So I hope I've explained myself. Now all I'm looking for is to write are_elements_presents() in a more Pythonic way. So please let me know if I can write are_elements_present() in more smart/shorter way. Thanks a lot for your help, in advance. Best regards, Oltmans --- -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Tuesday 15 September 2009 19:04:10 r wrote: > On Sep 15, 4:12 am, Hendrik van Rooyen > wrote: > (snip) > > > When a language lacks a word for a concept like "window", then (I > > believe :-) ), it kind of puts a crimp in the style of thinking that a > > person will do, growing up with only that language. > > Are you telling us people using a language that does not have a word > for window somehow cannot comprehend what a window is, are you mad > man? Words are simply text attributes attached to objects. the text > attribute doesn't change the object in any way. just think of is > __repr__ No - All I am asserting, is the unfashionable view that your first language forms the way you think. It goes deeper than the simple vocabulary problem you are describing, even though that is serious enough. I still assert that if your language does not have a word for something, and you have never seen that object, then you "__cannot__" think about it, because you do not have the tools in your kitbag that you need to do so. - no word, no concept, the empty set. And I would even assert that, when you meet the object, and acquire a word for it, it is painful for you to think about it, because it is a new thing for you. You then have to go through a painful process of integrating that new thing into your world view, before you are able to use and reference it easily. - did, for instance, the concept of "an abstract class" just jump into your head, and stick there immediately, complete with all its ramifications, in the minute immediately after hearing about it for the first time? Or did you need a bit of time to understand it and get comfortable? And were you able to, and did you, think about it "before" hearing of it? If you answer those questions honestly, you will catch my drift. The opposite thing is of course a continual source of trouble - we all have words for stuff we have never seen, like "dragon", "ghost", "goblin", "leprechaun", "the current King of France", "God", "Allah", "The Holy Trinity", "Lucifer", "Satan", "Griffin" - and because we have words for these things, we can, and unfortunately do, think about them, in a fuzzy fashion, to our own detriment. People even go around killing other people, based on such fuzzy thinking about stuff that can not be shown to exist. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Language wars - was :An assessment of the Unicode standard
On Tuesday 15 September 2009 18:22:30 Christopher Culver wrote: > Hendrik van Rooyen writes: > > 2) Is about as useful as stating that any Turing complete language and > > processor pair is capable of solving any computable problem, given enough > > time. So why are we not all programming in brainfuck? > > Except the amount of circumlocution one language might happen to use > over another is quite limited. This is just an opinion, and it depends on the definition of "limited". I have an example: Translate into English (from Afrikaans): "Die kat hardloop onder die tafel deur." Literally, word for word, the sense of the words are: "The cat runs under the table through." The Afrikaans conveys the meaning precisely and succinctly. I do not know of a simple way to convey the same meaning in English, to describe the action that takes place when a cat starts running well before one side of a table, dashes under it, and keeps running until it emerges at the opposite side, still running, and keeps running some more, in one smooth continuous burst of speed. When you say "The cat runs under the table" the English kind of implies that it goes there and tarries. Afrikaans would be "Die kat hardloop onder die tafel in". ( "in" = "in"). "Die kat hardloop onder die tafel uit." ( "uit" = "out" ).- Implies that the cat starts its run from under the table and leaves the shelter. The bare: "Die kat hardloop onder die tafel." implies a crazy cat that stays under the table while continuously running. None of these concepts can, as far as I know, be succinctly stated in English, because "English does not work like that" - there is no room in the syntax for the addition of a spacial qualifier word that modifies the meaning of the sentence. (not talking about words here that modify the verb - like fast or slow - that is a different dimension) So if you think the circumlocution is "quite limited", then your definition of "limited" is somehow different to mine. :-) 8< archeology - > > When a language lacks a word for a concept like "window", then (I > > believe :-) ), it kind of puts a crimp in the style of thinking that a > > person will do, growing up with only that language. > > "Window" goes back to an Anglo-Saxon compound "windeye". Even if a > word does not already exist in a given language for whatever novel > item, the language is capable of creating from its own resources. I think what normally happens is that a foreign word is assimilated into the language, at the time the concept is encountered by the culture, as a result of contact with an outside influence - That, as far as I know, (from hearsay) is what happened in the case of "window" and the N'guni languages. It also happened in Afrikaans at the time of the invention of television. - from its "own resources" (a bunch of God fearing, hypocritical, rabid English haters) came the official word "beeldradio" - "image radio" (having successfully assimilated "radio" shortly before.) You hardly ever hear the erstwhile official word now. It has been almost totally displaced by "televisie". No prizes for guessing where that came from. My opinion is that it is very difficult to avoid this borrowing when suddenly faced with a new thing. A language can only use its own resources to slowly evolve at its own pace. But then - I am probably wrong because I am not a linguist. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: str.split() with empty separator
On Tuesday 15 September 2009 14:50:11 Xavier Ho wrote:
> On Tue, Sep 15, 2009 at 10:31 PM, Ulrich Eckhardt
>
> wrote:
> > "'abc'.split('')" gives me a "ValueError: empty separator".
> > However, "''.join(['a', 'b', 'c'])" gives me "'abc'".
> >
> > Why this asymmetry? I was under the impression that the two would be
> > complementary.
>
> I'm not sure about asymmetry, but how would you implement a split method
> with an empty delimiter to begin with? It doesn't make much sense anyway.
I fell into this trap some time ago too.
There is no such string method.
The opposite of "".join(aListOfChars) is
list(aString)
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Monday 14 September 2009 14:06:36 Christopher Culver wrote: > This is the old Sapir-Whorf hypothesis, which fell out of favour among > linguists half a century ago already. 1) Language does not constrain > human thought, and 2) any two human languages are both capable of > expressing the same things, though one may already have a convenient > lexeme for the topic at hand while the other uses circumlocution. 1) Is an assumption, not a proven fact. "falling out of favour" is merely fashion amongst people who are dabbling in fuzzy areas where the hard discipline of the "scientific method" is inapplicable, because it is kind of hard to "prove" or "disprove" that my thinking and yours differ "because" my first language is different to yours. - we end up talking about our beliefs, after telling war stories. 2) Is about as useful as stating that any Turing complete language and processor pair is capable of solving any computable problem, given enough time. So why are we not all programming in brainfuck? Or speaking the language of the people who wrote linear B? When a language lacks a word for a concept like "window", then (I believe :-) ), it kind of puts a crimp in the style of thinking that a person will do, growing up with only that language. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Incremental project based programming guide
On Tuesday 15 September 2009 04:43:46 bouncy...@gmail.com wrote: > I was wondering if anyone had actually designed their programming text > around incremental parts of a project and then taken the results of the > project at each chapter and created something of value. specifically in > referwnce to python however other examples. ALl of education was around > pointless and unapplicable theory texts for which I am reaping nothing. > Surely someone has seen this in actiom to whit: ch1 design of problem ch2 > design taken out of ch1 then done in ch2 to take input/ output for a > smaller part ch3 take info from chs 1...@2 to craft an answer that is from the > same problemto a theoretical chapter say 30 with a gui or some such. > deitel and associates were unfortunately part of some of my worst > exampes--drills applenty with little to no application. much appreciated > towards python application and thanks in advance I cannot parse this. I get the idea that you are talking about a teaching text with certain characteristics. I cannot figure out if you are: (i) for the idea. (ii) against it. (ii) looking for something like it. Please elucidate. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: How to improve this code?
On Tuesday 15 September 2009 03:08:59 Oltmans wrote: > match=[1,2,3,4,5] > > def elementsPresent(aList): > result=False > if not aList: > return False > for e in aList: > if e in match: > result=True > else: > result = False > return result > elementsPresent([6,7,8,9,5]) # should return True because 5 is > present in list named match. What are you trying to do? Your code will only work if the last item in aList is in the match global. Is this what you want? or do you want: (i) a True if All the elements in match are in aList, else False? (ii) a True if any one or more of the members of match are in aList? (iii) Something else? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: NameError: name '__main__' is not defined
On Monday 14 September 2009 03:43:19 Peng Yu wrote: > Hi, > > I try the following code. I don't quite understand why __main__ is not > defined. Could somebody let me know what I am wrong about it? > > Regards, > Peng > > $ cat test.py > #!/usr/bin/env python > > if __main__ == '__main__' : > print "Hello World!\n" > $ ./test.py > Traceback (most recent call last): > File "./test.py", line 3, in > if __main__ == '__main__' : > NameError: name '__main__' is not defined You are looking for __name__ , not __main__ if __name__ == '__main__': """We are at the top of the tree so run something""" print "Goodbye Cruel World" - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: How to define a function with an empty body?
On Sunday 13 September 2009 05:37:01 Peng Yu wrote:
> Hi,
>
> I want to define a function without anything in it body. In C++, I can
> do something like the following because I can use "{}" to denote an
> empty function body. Since python use indentation, I am not sure how
> to do it. Can somebody let me know how to do it in python?
def rubbish_do_nothing():
pass
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Finite state machine in python
On Saturday 12 September 2009 22:39:10 Peng Yu wrote: > Hi, > > I have see some discussion on the implementation of finite state > machine in python. Can somebody point to me the best way in implenting > an FSM in python? > > http://code.activestate.com/recipes/146262/ You can go a long way with a far simpler model than the one in that recipe: 1) Define a routine for every state. 2) Have every state do the following: (i) Run the code to make the side effects like outputs happen. (ii) Scan the conditions for the state transitions relevant to this state. (Only the arrows leaving this state on the state diagram.) (iii) Return the next state (either the same or a different state). 3) The main loop of a long running machine then looks like this: next_state = start_state() while True: next_state = next_state() time.sleep(step_time) # if needed This simple model is surprisingly powerful, and it can be expanded to run a bundle of such machines in parallel very easily, by keeping a list of next_states and continuously cycling through and updating the list. You do not even need a dispatch dictionary. This is about the simplest model for making FSMs that I know of. Not sure if it is the "best" - best for what?. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: how to return value from button clicked by python
On Saturday 12 September 2009 06:57:26 Tim Roberts wrote: > chen tao wrote: > > I have several buttons, I want to realize: when I click first > >button, the button will call a function, and the function should > >return some parameter value, because I need this value for the other > >buttons. As Tim said - you cannot return anything, as the button command is called by the main GUI loop. If you really want to, you can set a variable global to the class, (Like self.my_passed_param) and use it in the second button - however then you have to handle cases where the user does not click the buttons in the sequence you expect. > >I tried the button.invoke() function, it almost got it...however, > >I only want it returns value when the button clicked, but because the > >program is in the class _ini_ function, so it always runs once before > >I click the button... > >Any one can give me some suggestions? > > You're thinking of your program in the wrong way. When you write a GUI, > things don't happen in order. Your __init__ function merely sets up your > window structure. The window has not actually been created or displayed at > that time. > > Later, when you call the "mainloop" function, it will start to process > messages. Your window will be displayed, and then you'll go idle while > waiting for user input. When you click a button, the mainloop will call > your handler, do a little processing, and return. > > So, your button function can't really return anything. There's nothing to > return it TO. If there is some action you need to take when the button is > clicked, then you DO that function in the button handler. This is perfectly right. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: New Tkinter windows don't get focus on OS X
On Friday 11 September 2009 09:53:56 eb303 wrote: > On Sep 11, 9:14 am, Hendrik van Rooyen > wrote: > > look for widget.focus_force() > > and look for widget.grab_set_global() > > Doesn't work. BTW, forcing the focus or setting the grab globally are > usually considered very annoying and I don't know any windowing system > or window manager honouring those. I have to confess I have never used the stuff - just remembered seeing it in the manual and pointed it out. What does it do? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: New Tkinter windows don't get focus on OS X
On Thursday 10 September 2009 18:19:09 Joshua Bronson wrote: > True, but it'll still be a lot less painful for me to test my app if I > can get it to steal focus > when launched from the command line. If anyone knows how to do this in > Tkinter, help would be much appreciated. > look for widget.focus_force() and look for widget.grab_set_global() Yahoo for: Shipman Tkinter "new mexico tech" for a nice manual, if you do not have it yet. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Output file formatting/loop problems -- HELP?
On Tuesday 08 September 2009 17:22:30 Maggie wrote:
> My code is supposed to enumerate each line of file (1, 2, 3...) and
> write the new version into the output file --
>
> #!/usr/bin/python
>
> import os.path
> import csv
> import sys
>
> #name of output file
> filename = "OUTPUT.txt"
>
>
> #open the file
> test = open ("test.txt", "r")
After this, do the following and see what you get:
for i,line in enumerate(test.readlines()):
print i, line
> my question is why the enumeration starts and stops at first line and
> doesnt go through the entire file --
It does - but it sees the entire file as one line, somehow.
> (file is saved as .txt, so hypothetically no .rtf formatting that
> would screw up the output should be present)
If it is really text, and if there are newlines at the end of the lines, then
it should JustWork...
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Monday 07 September 2009 20:26:02 John Nagle wrote: > Right. Tracking mutablity and ownership all the way down without > making the language either restrictive or slow is tough. > > In multi-thread programs, though, somebody has to be clear on who owns > what. I'm trying to figure out a way for the language, rather than the > programmer, to do that job. It's a major source of trouble in threaded > programs. I think that trying to make the language instead of the programmer responsible for this is a ball-buster. It is unlikely to be either easy or cheap. I would rather have the programmer responsible for the mental model, and give her the tools to do the job with. In any case - if you do not actually like juggling with knives, then you should not be mucking around with concurrency, and by making the language safe, you are taking the fun out. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Turn-based game - experimental economics
On Saturday 05 September 2009 12:07:59 Paolo Crosetto wrote: 8<--- > > The problem I now face is to organise turns. Players, as in Scrabble, will > play in turns. So far I have developed the server and ONE client, and > cannot get my head round to - nor find many examples of - how to simply > develop a turn-based interaction. 8<-- > > Does anyone have any hints? Why do you not just write a loop, giving each player a turn? keep a list of players. for player in players: tell_her_to_respond(player) ans = get_the_answer(player) update_all(player,ans) This is of course very basic, as it needs stuff like timeouts. But maybe it can get you started. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: The future of Python immutability
On Thursday 03 September 2009 21:07:21 Nigel Rantor wrote: > That is not the challenge, that's the easy part. The challenge is > getting useful information out of a system that has only been fed > immutable objects. Is it really that difficult? (completely speculative): class MyAnswer(object): def __init__(self) self.finished = False self.Answer = None self.collected = False Then when you start a thread, you give it an instance: ans = MyAnswer() list_of_answers.append(c) worker_thread = thread.start_new_thread(worker, (ans, immutable_stuff )) def worker(ans): ans.Answer = do_some_stuff() ans.finished = True Then to see if everybody is finished: runbool = True While runbool: finished = False runbool = False for answer in list_of_answers: if answer.finished and not answer.collected: do_something(answer.Answer) answer.collected = True else: runbool = True This scheme gives only one thread the license to make a change to the answer instance, so how can it go wrong? You can also extend it for long running threads by playing ping pong with the two booleans - the collector sets the collected boolean and clears the finished, and the worker must clear the collected boolean before starting a new cycle. ( the worker waits for not finished, then clears collected) I do similar stuff in assembler and I have no problems - Am I missing something subtle? Of course - working with immutable objects only is a bit like working with read only memory, or worse, write only memory - not easy. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: string find mystery
On Thursday 03 September 2009 07:10:37 Helvin wrote:
> Hi,
>
> I have come across this very strange behaviour. Check this code:
>
> if file_str.find('Geometry'):
> #if file_str.endswith('Data_Input_Geometry.txt'):
> print 'I found geometry'
> elif file_str.find('Material'):
> print 'I found material'
> The amazing thing is when file_str = 'C:\Qt\SimLCM\Default
> \Data_Input_Material.txt',
> the first if statement if fulfilled, that seemingly says that in this
> file_str, python actually finds the word 'Geometry'.
> I know this, because the line: 'I found geometry' is printed. However,
> if instead of using file_str.find(), I use file_str.endswith(), it
> does not exhibit this strange behaviour.
>
> Obviously, I want the elif line to be true, instead of the first if
> statement.
>
> Does anyone know why this is happening?
> Help much appreciated!
The interactive Interpreter is your friend:
s = "a;kljghkahklahdfgkjahdfhadafjd;l"
s.find("banana")
-1
bool(_)
True
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: map
On Wednesday 02 September 2009 09:38:20 elsa wrote: > > in my own defense - firstly, I was able to implement what I wanted to > do with loops, and I used this to solve the problem I needed to. My rant was not intended as a personal attack - far from it - if all the people on this list were to post such clear questions as you did, it would be an even greater pleasure to participate in than it is. > > However, by asking *why* map didn't work, I now understand how map > works, what contexts it may indeed be useful for, and what the > alternatives are. To boot, you have all given me about 10 different > ways of solving the problem, some of which use prettier (and probably > faster) code than the loops I wrote... Good. So you will soon be here answering questions too. When you do that, you really learn, as long as you do not feel slighted when people point out better (or merely different) solutions than yours. We all help each other here, and sometimes we even crack obscure (and not so obscure) jokes. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Wednesday 02 September 2009 08:52:55 Gabriel Genellina wrote: > En Tue, 01 Sep 2009 19:49:57 -0300, r escribió: > > On Sep 1, 1:52 pm, Hyuga wrote: > > (snip) > > > >> I'd say don't feel the troll, but too late for that I guess. > > > > The only trolls in this thread are you and the others who breaks into > > MY THREAD just for the knee-jerk reaction of troll calling! Even > > though you *did* offer some argument to one of the subjects of this > > thread, it was cancelled out by your trolling! > > Bueno, voy a escribir en el segundo lenguaje más hablado en el mundo > (español), después del mandarín (con más de 1000 millones de personas). El > inglés está recién en el tercer puesto, con menos de la mitad de hablantes > (500 millones). > > Si no me entendés, jodete. > > Fuente: http://www.wolframalpha.com/input/?i=languages+in+the+world What do you call someone who speaks three languages? - trilingual. What do you call someone who speaks two languages? - bilingual. What do you call someone who only speaks one language? - A stupid gringo! Nice one Gabriel - and with a link too! Looks like I am going to have to learn some Castilian, or something. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Daemon process
On Wednesday 02 September 2009 05:57:02 Shan wrote: > I have XML RPC Server listening on a port. This XML RPC Server works > fine when i run it as foreground process. All the clients are able to > connect with the XML RPC Server. But when i run it as daemon(not using > &. I am doing it in python way only), then no clients are able to > connect with the Server. I didnt got any clue where i may be wrong. > Can any help me with this? I am using python 2.4 on Redhat 5.2 64 > X86_64 What does: "(not using &. I am doing it in python way only)" mean? How are you doing it? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Executing python script stored as a string
On Tuesday 01 September 2009 11:32:29 Steven D'Aprano wrote: > Possibly there is a way to have a thread halt itself after a certain > amount of time? I'm not an expert on threads, I've hardly ever used them. Not automagically, as far as I can see. You are on your own if you want to somehow kill a thread. What I do is to wrap what I want to do in a while clause: while runbool: do_what_you_want() where runbool is a global that I set to false elsewhere when I want to stop. There is of course nothing to stop you writing a thread with something like: import time start_time = time.time() while time.time() - start_time < some_parameter: do_what_you_want() Which will have the effect of running for a while and then stop. I cannot see much use use for that as it is, as it will be bloody-minded about the time, and might chop off before the whole job is done, but one could make it more intelligent, such that it keeps track of idle time, and aborts after say a second (or a minute) of not doing anything useful. Unlike you, I am a thread and queue fanatic - use them all the time. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: map
On Monday 31 August 2009 11:31:34 Piet van Oostrum wrote: > But ultimately it is also very much a matter of taste, preference and > habit. This is true, but there is another reason that I posted - I have noticed that there seems to be a tendency amongst newcomers to the group to go to great lengths to find something that will do exactly what they want, irrespective of the inherent complexity or lack thereof of that which they are trying to do. Now I cannot understand why this is - one could say that it is caused by an eagerness to understand all the corners of the tool that is python, but somehow it does not feel like that to me - I see it almost as a crisis of confidence - as if the newbie lacks the self confidence to believe that he or she is capable of doing anything independently. So whenever I can, I try to encourage people to just do it their way, and to see what happens, and to hack using the interactive interpreter, to build confidence by experimenting and making mistakes, and realizing that when you have made a mistake, it is not the end of the world, - you can fix it and move on. Don't know if this rant makes any sense... - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: map
On Monday 31 August 2009 06:55:52 elsa wrote: 8< - map question > > (Ultimately, I want to call myFunc(myList[0], 'booHoo'), myFunc(myList > [1], 'booHoo'), myFunc(myList[2], 'booHoo') etc. However, I might want > to call myFunc(myList[0], 'woo'), myFunc(myList[1], 'woo'), myFunc > (myList[2], 'woo') some other time). Here is some heretical advice: Do not use stuff like map and reduce unless they fit what you want to do perfectly, and "JustWorks" the first time. You have a very clear idea of what you want to do, so why do you not just simply write something to do it? something like this (untested): def woofer(thefunc,thelist,thething): theanswers = [] for x in thelist: theanswers.append(thefunc(x,thething)) return theanswers And the advantage is that you do not have to remember what map does... *ducks away from the inevitable flames* - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sunday 30 August 2009 22:46:49 Dennis Lee Bieber wrote: > Rather elitist viewpoint... Why don't we just drop nukes on some 60% > of populated landmasses that don't have a "western" culture and avoid > the whole problem? Now yer talking, boyo! It will surely help with the basic problem which is the heavy infestation of people on the planet! :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Annoying octal notation
On Monday 24 August 2009 16:14:25 Derek Martin wrote: > In fact, now that I think of it... > > I just looked at some old school papers I had tucked away in a family > album. I'm quite sure that in grammar school, I was tought to use a > date format of 8/9/79, without leading zeros. I can't prove it, of > course, but feel fairly sure that the prevalence of leading zeros in > dates occured only in the mid to late 1980's as computers became more > prevalent in our society (no doubt because thousands of cobol I was one of those COBOL programmers, and the time was around the end of the sixties, running into the seventies. And the reason for leading zeroes on dates was the punched card, and its handmaiden, the data entry form, with a nice little block for every character. Does anybody remember key to tape systems other than Mohawk? > programmers writing business apps needed a way to convert dates as > strings to numbers that was easy and fit in small memory). > > Assuming I'm right about that, then the use of a leading 0 to > represent octal actually predates the prevalence of using 0 in dates > by almost two decades. Not quite - at the time I started, punch cards and data entry forms were already well established practice, and at least on the English machines, (ICL 1500/1900 series) octal was prevalent, but I don't know when the leading zero octal notation started, and where. I only met it much later in life, and learned it through hard won irritation, because it is a stupid convention, when viewed dispassionately. > And while using leading zeros in other > contexts is "familiar" to me, I would certainly not consider it > "common" by any means. Thus I think it's fair to say that when this > syntax was selected, it was a rather good choice. I think you give it credence for far more depth of design thinking than what actually happened in those days - some team working on a compiler made a decision (based on gut feel or experience, or precedent, or whim ) and that was that - lo! - a standard is born! -- We have always done it this way, here at company x. And besides, we cannot ask our main guru to spend any of his precious time mucking around with trivia - the man may leave us for the opposition if we irritate him, and systems people do not grow on trees, you know. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sunday 30 August 2009 15:37:19 r wrote: > What makes you think that diversity is lost with a single language? I am quite sure of this - it goes deeper than mere regional differences - your first language forms the way you think - and if we all get taught the same language, then on a very fundamental level we will all think in a similar way, and that loss will outweigh the normal regional or cultural differences on which you would have to rely for your diversity. Philip Larkin has explained the effect better than I can: "They f*ck you up, your mom and dad, They do not mean to, but they do. They fill you with the faults they had, And add some extra, just for you." > I > say more pollination will occur and the seed will be more potent since > all parties will contribute to the same pool. I think this effect, while it might be real, would be swamped by the loss of the real diversity. > Sure there will be > idioms of different regions but that is to be expected. But at least > then i could make international crank calls without the language > barrier ;-) You can make crank calls _now_ without a language barrier - heavy breathing is a universally understood idiom. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: An assessment of the Unicode standard
On Sunday 30 August 2009 02:20:47 John Machin wrote:
> On Aug 30, 8:46 am, r wrote:
> > Take for instance the Chinese language with it's thousands of
> > characters and BS, it's more of an art than a language. Why do we
> > need such complicated languages in this day and time. Many languages
> > have been perfected, (although not perfect) far beyond that of Chinese
> > language.
>
> The Chinese language is more widely spoken than English, is quite
> capable of expression in ASCII ("r tongzhi shi sha gua") and doesn't
> have those pesky it's/its problems.
>
> > The A-Z char set is flawless!
>
> ... for expressing the sounds of a very limited number of languages,
> and English is *NOT* one of those.
I suspect that the alphabet is not ideal for representing the sounds of _any_
language, and I would look for my proof in the plethora of things that we use
when writing, other than the bare A-Z. - Punctuation, diacritics...
But what really started me thinking, after reading this post of John's, read
with Dennis'. - on the dissimilarity of the spoken and written Chinese - was
the basic dichotomy of the two systems - a symbol for a sound vs a symbol for
a word or an idea.
I know that when I read, I do not actually read the characters, I recognize
words, and only fall back to messing with characters when I hit something
unfamiliar.
So It would seem to me that r's "utopia" could sooner be realized if the
former system were abandoned in favour of the latter. - and Horrors! The
language of choice would not be English!
Not that I agree that it would be a Utopia, whatever the language - more like
a nightmare of Orwellian proportions - because the language you get taught
first, moulds the way you think. And I know from personal experience that
there are concepts that can be succinctly expressed in one language, that
takes a lot of wordy handwaving to get across in another. So diversity would
be less, creativity would suffer due to lack of cross pollination, and
progress would slow or stop.
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Combining C and Python programs
On Saturday 29 August 2009 09:54:15 Sortie wrote: > I want to write a program that will use ode for the physics > simulation, whose python bindings are outdated. So I'm writing > the physics engine in C and want to write the drawing code in > Python. What will be the best way of making those two programs > work together? THe physics engine won't have to run concurrently > with the drawing code. It will only return some position data so > they can be drawn. Have you looked at ctypes? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: What python can NOT do?
On Saturday 29 August 2009 02:14:39 Tim Chase wrote: > I've also been sorely disappointed by Python's ability to make a > good chocolate cream silk pie. This is not pythons fault - it is yours, for failing to collaborate with a good hardware designer for the robotics. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: comparison on list yields surprising result
On Friday 28 August 2009 21:00:31 Dr. Phillip M. Feldman wrote: > In [21]: x > Out[21]: [1, 2, 3, 5] > > In [22]: x>6 > Out[22]: True > > Is this a bug? No, it is a feature, so that you can use sorted on this: [[1,2,3,4,5],6] - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Friday 28 August 2009 00:42:16 Esben von Buchwald wrote: > OK, now things starts to make sense. > > You tell me to do something like this? > > > def doCallback(self): > if self.process_busy==False: > self.process_busy=True > self.at.after(0.01,self.data_callback) This bit is allmost right - try to make the time a millisecond or less, if you can. (however that is specified - I do not know) The spelling is probably: self.at.after(1,self.data_callback, (other_stuff)) where "other stuff" comes from the event and is what is needed to do the calculation. - the event should be an argument to the doCallback thinghy too, somehow, so that you can get at what you need to do the calculation. > def doneCallback(self): > self.process_busy=False > you do not need this separate. just do this: def data_callback(self,other_stuff): calculate what must be calculated self.process_busy=False > > And the after command will cause python to spawn a new thread, which > runs self.data_callback, which measn that the doCallback will return > immediately, so the next callback from accelerometer can be processed? Yes and skipped if the calculation is not done yet. Obviously you will have to do whatever it takes to make sure the events keep coming (if anything), so it may end up a little more complex, but you basically have the idea now. The thing that happens as a result of the after is not really a new thread, it is a piece of the main loop that gets diverted for a while to do the calculation. if, in that routine, you go: while True: pass You will completely freeze up the whole bang shoot.. > > And when the self.data_callback() finishes, i'd make it call the > doneCallback() to release my busy flag, right? see above - just clear it from the called routine. > > I'm gonna try this tomorrow :) Good luck! - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: [OT] How do I reply to a thread by sending a message to python-list@python.org
On Thursday 27 August 2009 22:57:44 Terry Reedy wrote: > > Nope. I got a duplicate sent to my mailbox, which I hate. > > In particular, because there is no indication that it is an exact > duplicate of what I will also find on the list itself. Please use reply > instead of reply-all. If I do that, then the mail would go just to you, and not to the list at all, which is not what I suspect you want, in view of what you have just said. I have to do a "reply all", followed by deletion of the author, and sometimes addition of the list as a "to" too. Its a mess, and if I muck it up, the author gets a copy in his email, if he has not fudged his "reply to" It would really be nice if the "reply" would go to the list, but for the digest versions, at least, it does not. And different mail clients do not seem to make a difference. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Thursday 27 August 2009 16:50:16 Carl Banks wrote: > On Aug 27, 7:25 am, Hendrik van Rooyen > wrote: > > Its not too bad - if you crook a bit - the trick is that you iterate over > > the list backwards when you are removing stuff based on index, so that > > the remainder does not get jumbled up by losing their positions, as > > happens when you do it going forwards. > > That's only if you remove the "current item". The OP has different > threads accessing the list at the same time, so I have to assume that > item being remove is not necessarily the current iteration. Sorry - I did not pick that up - The threading screws the simple scheme up. In such a situation I would have a thread to run the list - almost like a mini data base - and link the lot together using queues. It is still a bugger, though, as one thread could try to kill something that is "checked out" to another one. Then you have to take hard decisions, and a list is the wrong structure, because you have to remember state. Better to use a dict, so you can at least mark a thing as "dead", and check for that before you update. 8< example > For the record, I use a more sophisticated system that explicitly > resolves cause and effect in my games. That's probably beyond the > scope of this thread, though. Yes - it is hairy - and there are probably as many different solutions as there are programmers, and then some. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: List iterator thread safety
On Thursday 27 August 2009 15:26:04 Carl Banks wrote: > Deleting items from a list while iterating over it is a bad idea, > exceptions or not. > > Hmm, this sounds like something someone might do for a game. You have > a list of objects, and in a given time step you have to iterate > through the list and update each object. Problem is, one of the > enemies is kill before you get to it, so you would like to remove the > object from the list while iterating. Not an easy problem. Its not too bad - if you crook a bit - the trick is that you iterate over the list backwards when you are removing stuff based on index, so that the remainder does not get jumbled up by losing their positions, as happens when you do it going forwards. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thursday 27 August 2009 11:31:41 Steven D'Aprano wrote: > > What you are calculating might actually be quite complicated to enter as > a literal. You might have something like: 8< -- Complicated Table Example --- Me? - never! I am just an assembler programmer. I would not touch a thing like that with a barge pole. Unless of course, I have to. > Clearly this is a made-up example, but the principle is sound. If Python > can calculate values for you, why not let it do so? It is easier for you, > easier to check that you've calculated them correctly, easier to debug > and read, it makes the algorithm clearer (fewer "magic constants"). Yes, > there is a run-time cost, but you only pay it once, when you import the > module, and it's likely to be not that much more expensive than parsing > the literals anyway. > > Of course, for something as big and complicated as the above table, I'd > almost certainly put the code to calculate it in a function outside of > the class, but that's a matter of style, and it will work to put it > inside the class. It is a hell of a thing if it needs recursion to calculate - If it was really that complex, I would calculate it, check it (if I can), document it and put it in a module of its own, with "This side up", "Fragile", and other warning stickers all over it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Thursday 27 August 2009 11:14:41 Steven D'Aprano wrote: > On Thu, 27 Aug 2009 08:38:29 +0200, Hendrik van Rooyen wrote: > > On Wednesday 26 August 2009 17:14:27 kj wrote: > >> As I described at length in another reply, the function in question is > >> not intended to be "callable outside the class". And yes, > > > > I think this might go to nub of your problem - It might help you to > > think as follows: > > > > A Python class, even after it has been executed, does not really exist > > except as a kind of template or pattern - it is mostly useless until an > > instance of the class is made by calling it with whatever it needs to > > set up the instance. And once you have an instance, you can do stuff > > with that particular instance. Before that time, the class is mostly > > just a promise of things to come. > > Oh my! I couldn't disagree more strongly! I think the above is totally > incorrect. It was intended to help the OP out of the mental hole he finds himself in. Most of the classes I use fall directly into such a classification - they are useless until an instance is created. And I would be so bold as to say that _all_ gui classes are like that. This is the pattern I am talking about: class thing(object): def __init__(self,foo,bar): stuff to do things with foo and bar, creating or modifying attributes of the instance. def somemethod(self,baz,bling): instance method to do further operations on the attributes of the instance Now kindly explain to me how a class like that is usefull before an instance of it is created, and I might agree with you that what I said is "totally incorrect" 8< --trivial examples showing that there is something there > Classes are themselves instances of their metaclass. By default, classes > have a metaclass of type, but you can easily change that. Metaclass > programming is advanced but very powerful. > > Because classes are themselves objects, you can (with a bit of metaclass > jiggery-pokery) make them do all sorts of interesting things. For > instance, huge amounts of effort are often put into creating a Singleton > class, a class that has a single instance. Well, okay... but why not just > use the class object itself, instead of an instance? There's already one > of those, and you can't (easily) make a copy of it, and even if you did, > it would be an independent class. Instead of this: > > singleton = SingletonClass(args) > do_something_with(singleton) > > just do this: > > do_something_with(SingletonClass) > > Of course SingletonClass needs to be designed to work that way, which > will probably need some metaclass magic. It would be interesting to see > which requires less effort. *nods* yes this would make sense - but it is not quite what either the OP or I was on about. > > When it comes to built-in classes (types), I often use the class object > itself as an object. E.g. I might do something like this: > > def convert(seq): > t = type(seq) # remember the original type > result = process(seq) # always produces a list > if t is list: > return result # don't bother making a copy of the result > elif t is str or t is unicode: > empty = t() > return empty.join(result) > else: > return t(result) # return the original type nice. now try doing it with object: thing = object() After that, thing will exist, but it is a bit like write only memory - completely useless, until you have done some more work with it. > > >> recursive functions in Python *are* restricted in ways that > >> non-recursive functions aren't. The examples I've posted prove this > >> point unambiguously. > > > > Yes and no - mostly no - your examples just illustrate the point I > > tried to make above. > > Completely no. You may have missed the examples I've given, but the > problems the Original Poster were having had nothing to do with recursion. The yes was in there to make the man feel a bit better, and because from where he stood, it _was_ the recursion that did him in. : - ) > > > Pythons object model, and its classes, are different from what you are > > used to. A bare class is mostly useless without an instance, which is > > ultimately why accessing a function in a class from itself like you are > > doing, without reference to an instance, does not work - the function > > does not exist yet to a degree that it can be referenced. > > That is incorrect. What's going on is more subtle. > Right - I can see that you are reading that to mean that there must be an instance. That i
Re: Python for professsional Windows GUI apps?
On Wednesday 26 August 2009 22:47:23 David C Ullrich wrote: > That's great. But do you know of anything I can use as a > visual form design tool in wxPython? Boa Constructor - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Wednesday 26 August 2009 22:06:01 Esben von Buchwald wrote: > > I don't really get it... > > I can see that I should put a t.after(...) around the function that does > the work, when calling it. That delays each call for the given period. I > just tried it out, the console keeps saying > - > Traceback (most recent call last): >File "c:\resource\python25\python25.zip\sensorfw.py", line 499, in > data_cb >File "c:\resource\python25\python25.zip\sensorfw.py", line 160, in > custom_cb >File "e:\python\r3s_contextdata.py", line 79, in acc_filter > self.acc_callback() >File "e:\python\r3s_contextdata.py", line 85, in acc_callback > self.doCallback() >File "e:\python\r3s_contextdata.py", line 47, in doCallback > self.at.after(0.05,self.data_callback) > RuntimeError: Timer pending - cancel first > > - > > It seems like i should cancel the current counting timer, when a new > call comes in - but how to determine when to cancel etc? Hmm - now I am really starting to fly by the seat of my pants - but it looks as if your problem is that your routine is basically being called faster than what it can do the processing. So what I would try is to define a global (you should really acquire a lock, but forget that for the moment) So lets call this thing running_calculation. Then you set this in the routine just before the after call, and reset it just before exiting the calculation routine, and if it is set when you get into the first routine, then you just exit, without doing the after. This should have the effect of skipping some calls, to make it all manageable. Then you should (hopefully) not have the duplication that it looks to me like you are now having. Bye the way, make the time short - like 1 - it could also be that the time is now so long before you start calculating, that you do not have a snowball's hope in hell to be finished before the next value comes in. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Wednesday 26 August 2009 17:45:54 kj wrote: > In <02a54597$0$20629$c3e8...@news.astraweb.com> Steven D'Aprano writes: > >Why are you defining a method without a self parameter? > > Because, as I've explained elsewhere, it is not a method: it's a > "helper" function, meant to be called only once, within the class > statement itself. If the sole purpose of the function is to be used to define what will become a constant, why do you not just calculate the constant on your calculator, or at the interactive prompt, and assign it to the attribute, and be done with it? Why waste run time recalculating every time the programme is called? > > Well, this is not strictly true, because the function is recursive, > so it will also call itself a few times. But still, all these > calls happen (loosely speaking) "within the class statement". Why *must* it be there? > > In fact the only reason to use a function for such initialization > work is when one needs recursion; otherwise there's no point in > defining a function that will only be invoked exactly once. Seems no point to me even when there is recursion - a number is a number is a number. If you know the arguments when you write it, and if the function is known at time of writing, storing a literal is the best solution. Conversely, if the arguments are not known at time of writing, then they should be passed at run time, when an instance is created, and assigned as part of the __init__ method. And the same is true if the function is not known at time of writing - then it must be passed to the constructor of the instance. Storm in a teacup. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need help with Python scoping rules
On Wednesday 26 August 2009 17:14:27 kj wrote: > As I described at length in another reply, the function in question > is not intended to be "callable outside the class". And yes, I think this might go to nub of your problem - It might help you to think as follows: A Python class, even after it has been executed, does not really exist except as a kind of template or pattern - it is mostly useless until an instance of the class is made by calling it with whatever it needs to set up the instance. And once you have an instance, you can do stuff with that particular instance. Before that time, the class is mostly just a promise of things to come. The other thing to bear in mind is that you cannot really hide stuff in python classes - there are no really private things. > recursive functions in Python *are* restricted in ways that > non-recursive functions aren't. The examples I've posted prove > this point unambiguously. Yes and no - mostly no - your examples just illustrate the point I tried to make above. Pythons object model, and its classes, are different from what you are used to. A bare class is mostly useless without an instance, which is ultimately why accessing a function in a class from itself like you are doing, without reference to an instance, does not work - the function does not exist yet to a degree that it can be referenced. It is kind of subtle, and different from other languages. 8<- rant against the way things are --- Welcome to python, and the newsgroup, by the way. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Reference question
On Tuesday 25 August 2009 21:32:09 Aahz wrote: > In article , > > Hendrik van Rooyen wrote: > >On Friday 21 August 2009 08:07:18 josef wrote: > >> My main focus of this post is: "How do I find and use object reference > >> memory locations?" > >> > >>>> a = [1,2,3,4] > >>>> id(a) > > > >8347088 > > Of course, that doesn't actually allow you to do anything... Well - if the OP is the sort of person who likes juggling with running chainsaws, then he can look up a thread I started about a thing I called a "can", which enabled you to get the object back from a string representation of the ID. I did not want to open that "can" of worms again, and I thought that answering half a question was better than nothing... *weg* - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Tuesday 25 August 2009 15:21:16 Esben von Buchwald wrote: > Dennis Lee Bieber wrote: > > On Mon, 24 Aug 2009 17:32:23 +0200, Esben von Buchwald > > declaimed the following in > > > > gmane.comp.python.general: > >> I'm new to python, what is an after function and an after call? Couldn't > >> find excact answer on google...? Do you have a link to some docs? > > > > They would be particular to whatever GUI/event library is in use. > > They aren't part of Python itself. > > This is how the accelerometer is accessed > http://pys60.garage.maemo.org/doc/s60/node59.html > > I found this called "after"... > http://pys60.garage.maemo.org/doc/s60/node12.html > > would that be usable? Probably > > If so, how? This is a guess, for your device, but I suspect something along these lines: t = Ao_timer() cb = t.after(100,thing_that_does_the_work(with_its_arguments)) Lots of assumptions here - the 100 should give you a tenth of a second... Don't know what the arguments look like, and if you need to pass an instance (like self) - that would depend on where you are calling it from. Play and see :-) You should also be able to cancel the callback like this: t.cancel(cb) If you do it before the time out - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Monday 24 August 2009 17:32:23 Esben von Buchwald wrote: > Hendrik van Rooyen wrote: 8< -- some stuff about an "after" call -- > > I'm new to python, what is an after function and an after call? Couldn't > find excact answer on google...? Do you have a link to some docs? The after call is common in GUI stuff. Here is a link to nice Tkinter manual - it is the first link if you google for: tkinter "new mexico tech" shipman www.nmt.edu/tcc/help/pubs/tkinter/ What after does is that it is like a normal call, except that it is not done immediately, but after some settable time, hence the "after". - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Protecting against callbacks queuing up?
On Monday 24 August 2009 02:14:24 Esben von Buchwald wrote: > Hello > > I'm using Python for S60 1.9.7 on my Nokia phone. > > I've made a program that gets input from an accelerometer sensor, and > then calculates some stuff and displays the result. > > The sensor framework API does a callback to a function defined by me, > every time new data is available. > > The problem is, that sometimes, the calculations may take longer than > others, but if the callback is called before the first calculation is > done, it seems like it's queuing up all the callbacks, and execute them > sequentially, afterwards. > > What I need, is to simply ignore the callback, if the previous call > hasn't finished it's operations before it's called again. > > I thought that this code would do the trick, but it obviously doesn't > help at all, and i can't understand why... > > def doCallback(self): > if self.process_busy==False: > self.process_busy=True > self.data_callback() > self.process_busy=False > see if there is an "after" method somewhere. What you have to do is to "break the link" between the callback and the processing. Your code above is all in the callback "thread", despite the fact that you call another function to do the processing. So if you replace the data_callback() with an after call, it should work as you expect. HTH - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Numeric literals in other than base 10 - was Annoying octal notation
On Monday 24 August 2009 01:04:37 bartc wrote: > That's a neat idea. But an even simpler scheme might be: > > .octal.100 > .decimal.100 > .hex.100 > .binary.100 > .trinary.100 > > until it gets to this anyway: > > .thiryseximal.100 Yeah right. So now I first have to type a string, which probably has a strict spelling, before a number. It is only marginally less stupid than this: 1.0 - Unary 11.0101 - Binary 111. 012012 - Trinary .01234567 - Octal 11.0123456789 - Decimal .0123456789abcdef - Hex Any parser that can count will immediately know what to do. I also tried to include an example of a literal with a base of a Googol but I ran out of both ink and symbols. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: your favorite debugging tool?
On Saturday 22 August 2009 16:49:22 Aahz wrote: > In article , > > Esmail wrote: > >What is your favorite tool to help you debug your code? I've been > >getting along with 'print' statements but that is getting old and > >somewhat cumbersome. > > Despite the fact that I've been using Python for more than a decade, > print is still my mainstay (or possibly logging to a file). Same here, although I have not been abusing python for as long as Aahz has been using it. I find that python pretty much does more or less what I expect it to, and where it does not, a print quickly gets me to RTFM when I have been rolling along under intuition. And the final arbiter is of course the interactive prompt. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Blank Line at Program Exit
On Thursday 20 August 2009 07:31:14 Steven Woody wrote: > Hi, > Any python program, even that does absolutely nothing in the code, will > cause a blank line printed out when the program exit. What's the reason? not for me: h...@linuxbox:~/Sasol/lib> cat blank.py h...@linuxbox:~/Sasol/lib> python blank.py h...@linuxbox:~/Sasol/lib> - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Object Reference question
On Friday 21 August 2009 08:07:18 josef wrote: > My main focus of this post is: "How do I find and use object reference > memory locations?" >>> a = [1,2,3,4] >>> id(a) 8347088 >>> - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Parallelization in Python 2.6
On Wednesday 19 August 2009 10:13:41 Paul Rubin wrote: > Hendrik van Rooyen writes: > > Just use thread then and thread.start_new_thread. > > It just works. > > The GIL doesn't apply to threads made like that?! The GIL does apply - I was talking nonsense again. Misread the OP's intention. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Parallelization in Python 2.6
On Tuesday 18 August 2009 22:45:38 Robert Dailey wrote: > Really, all I'm trying to do is the most trivial type of > parallelization. Take two functions, execute them in parallel. This > type of parallelization is called "embarrassingly parallel", and is > the simplest form. There are no dependencies between the two > functions. They do requires read-only access to shared data, though. > And if they are being spawned as sub-processes this could cause > problems, unless the multiprocess module creates pipelines or other > means to handle this situation. Just use thread then and thread.start_new_thread. It just works. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Inheriting dictionary
On Tuesday 18 August 2009 21:44:55 Pavel Panchekha wrote:
> I want a dictionary that will transparently "inherit" from a parent
> dictionary. So, for example:
>
> """
> a = InheritDict({1: "one", 2: "two", 4: "four"})
> b = InheritDict({3: "three", 4: "foobar"}, inherit_from=a)
>
> a[1] # "one"
> a[4] # "four"
> b[1] # "one"
> b[3] # "three"
> b[4] # "foobar"
> """
>
> I've written something like this in Python already, but I'm wondering
> if something like this already exists, preferably written in C, for
> speed.
Its not inheritance, but have you looked at the update method?
-Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
Re: Diversity in Python
On Tuesday 18 August 2009 12:38:36 Ben Finney wrote: > Hendrik van Rooyen writes: > > On Tuesday 18 August 2009 06:45:39 Aahz wrote: > > > Mainly an opportunity to flog the new diversity list. > > > > Here my English fails me - flog as in "whip", or flog as in "sell"? > > Yes :-) Thank you that clears it up. :-) - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Diversity in Python (was Re: Need cleanup advice for multiline string)
On Tuesday 18 August 2009 06:45:39 Aahz wrote: > In article , > > Steven D'Aprano wrote: > >The comments were made a week ago -- why the sudden flurry of attention? > > Mainly an opportunity to flog the new diversity list. Here my English fails me - flog as in "whip", or flog as in "sell"? - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Need cleanup advice for multiline string
On Monday 17 August 2009 23:06:04 Carl Banks wrote: > On Aug 17, 10:03 am, Jean-Michel Pichavant > > wrote: > > I'm no English native, but I already heard women/men referring to a > > group as "guys", no matter that group gender configuration. It's even > > used for group composed exclusively of women. Moreover it looks like a > > *very* friendly form, so there is really nothing to worry about it. > > I like how being very friendly means calling people after a guy who > tried to blow up the English Parliament. +1 QOTW - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: GUI interface builder for python
On Monday 17 August 2009 07:59:02 l...@d@n wrote: > Which is the best GUI interface builder with drag and drop > capabilities. > I am using Ubuntu GNU/Linux. > Please help me. > Thank you. Have a look at Boa Constructor. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Sunday 16 August 2009 15:55:31 Grant Edwards wrote: > On 2009-08-15, Hendrik van Rooyen wrote: > > I am still confused about pyserial and serial - I found serial > > in my distribution library, (on the SuSe machine, not on the > > 2.5 in Slackware) but I had to download pyserial. > > That's very interesting. Is the pre-existing "serial" a > version of pyserial that the packager had pre-installed or is > it something else? I didn't know any distributions shipped I am not too sure now - when I looked in the packages directory over the weekend it was there. But I am really not sure how it got there - I cannot recall downloading it myself, but that means nothing as I have been using this machine for a while now, so it is possible that I did it some time ago and forgotten about it, without ever using it. Possible, but unlikely. I would like to think that if I downloaded it, I would have tried it, and then I would have remembered. Sorry to be so vague. Does this help? h...@linuxbox:~> python Python 2.5.1 (r251:54863, Dec 6 2008, 10:49:39) [GCC 4.2.1 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> import serial >>> dir(serial) ['EIGHTBITS', 'FCNTL', 'FIVEBITS', 'FileLike', 'PARITY_EVEN', 'PARITY_NAMES', 'PARITY_NONE', 'PARITY_ODD', 'SEVENBITS', 'SIXBITS', 'STOPBITS_ONE', 'STOPBITS_TWO', 'Serial', 'SerialBase', 'SerialException', 'SerialTimeoutException', 'TERMIOS', 'TIOCINQ', 'TIOCMBIC', 'TIOCMBIS', 'TIOCMGET', 'TIOCMSET', 'TIOCM_CAR', 'TIOCM_CD', 'TIOCM_CTS', 'TIOCM_DSR', 'TIOCM_DTR', 'TIOCM_DTR_str', 'TIOCM_RI', 'TIOCM_RNG', 'TIOCM_RTS', 'TIOCM_RTS_str', 'TIOCM_zero_str', 'VERSION', 'XOFF', 'XON', '__builtins__', '__doc__', '__file__', '__name__', '__path__', 'device', 'errno', 'fcntl', 'os', 'plat', 'portNotOpenError', 'select', 'serialposix', 'serialutil', 'string', 'struct', 'sys', 'termios', 'writeTimeoutError'] >>> serial.VERSION '1.27' - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Sunday 16 August 2009 12:18:11 Steven D'Aprano wrote: > In any case, after half a century of left-from-right assignment, I think > it's worth the experiment in a teaching language or three to try it the > other way. The closest to this I know of is the family of languages > derived from Apple's Hypertalk, where you do assignment with: > > put somevalue into name > > (Doesn't COBOL do something similar?) Yup. move banana to pineapple. move accountnum in inrec to accountnum in outrec. move corresponding inrec to outrec. It should all be upper case of course... I cannot quite recall, but I have the feeling that in the second form, "of" was also allowed instead of "in", but it has been a while now so I am probably wrong. The move was powerful - it would do conversions for you based on the types of the operands - it all "just worked". - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port? - conclusions
On Sunday 16 August 2009 08:20:34 John Nagle wrote: > Hendrik van Rooyen wrote: > > On Saturday 15 August 2009 14:40:35 Michael Ströder wrote: > >> Hendrik van Rooyen wrote: > >>> In the past, on this group, I have made statements that said that on > >>> Linux, the serial port handling somehow does not allow transmitting and > >>> receiving at the same time, and nobody contradicted me. > > Absolutely false. No its true, if you open the serial port with the standard open() instead of os.open(). And it is also true that I was not contradicted in the past. :-) > > >> Despite all the good comments here by other skilled people I'd recommend > >> to determine whether the transmission line to the devices accessed > >> support full duplex. > > All standard PC serial ports are full-duplex devices. > I know this, and I started the thread because they would not work full duplex for me. 8< pyserial baudot program link --- > > You raise a good point, that is probably not well known amongst the > > youngsters here, as simple serial multidropping has gone out of fashion. > > Actually, no. Dynamixel servos as used on the latest Bioloid robots > are multidrop serial RS-485. But outside the embedded world, nobody uses > that stuff any more. (Embedded is going Ethernet; it's overkill but > works fine and is now cheap.) Exactly - it is no longer part of mainstream fashion. We also still use RS-485 because it is cheaper, and we have better control over timing. I enclose two naive test implementations. To run them you will need a loopback connector. One can be made by shorting pin 2 and 3 together on the standard DB9. The results are illuminating - on my development machine, (dual 64 bit, some gigs), the last lines look like this: test.py: The quick brown fox jumps over the lazy dog 1023 That took 3.91238284111 seconds - 3.82068636827 Millisecs per record, 261.733077152 recs per sec h...@linuxbox:~/dos/JOBS/sms/lib> test1.py: The quick brown fox jumps over the lazy dog 1023 That took 3.90402388573 seconds - 3.81252332591 Millisecs per record, 262.293477185 recs per sec h...@linuxbox:~/dos/JOBS/sms/lib> Almost no difference between the two implementations. This is basically because there is enough processing power to keep the link running at full speed in both instances. On the eBox, (486, 400MHz, 128Mb, no FP), the difference is startling: test.py: The quick brown fox jumps over the lazy dog 1023 That took 69.2863521576 seconds - 67.6624532789 Millisecs per record, 14.7792453797 recs per sec r...@ebox:/home/user/sms/lib# About eighteen times slower than the development machine. test1.py: The quick brown fox jumps over the lazy dog 1023 That took 10.391780138 seconds - 10.148222791 Millisecs per record, 98.5394211964 recs per sec r...@ebox:/home/user/sms/lib# Less than three times slower than the development machine. The little processor + Slackware + python cannot keep the link busy. Python, as a character handler, well let us say that it is suboptimal, because saying that something sucks, sucks. An almost seven times ratio between the implementations is not to be sneezed at. So the conclusions I have come to are the following: 1) Thou shalt not use ordinary python files for serial ports, on pain of death. 2) Thou shalt strive mightily to minimize python calls, doing all in thy power to move away from character input to string input. 3) Thou shalt expend real treasure for real processing power as there is no such thing as a free lunch. I would like to thank everybody who took the trouble to respond to teach me the error of my ways. - Hendrik test1.py Description: application/python test.py Description: application/python -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
>"Steven D'Aprano" wrote: >Now that I understand what the semantics of cout << "Hello world" are, I >don't have any problem with it either. It is a bit weird, "Hello world" >>> cout would probably be better, but it's hardly the strangest design in >any programming language, and it's probably influenced by input >redirection using < in various shells. I find it strange that you would prefer: "Hello world" >> cout over: cout << "Hello world" The latter seems to me to be more in line with normal assignment: - Take what is on the right and make the left the same. I suppose it is because we read from left to right that the first one seems better to you. Another instance of how different we all are. It goes down to the assembler - there are two schools: mova,b - for Intel like languages, this means move b to a mova,b - for Motorola like languages, this means move a to b Gets confusing sometimes. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Saturday 15 August 2009 16:25:03 Grant Edwards wrote: > > Are you using python file operations open/read/write or OS > file-descriptor operations os.open/os.read/os.write? The former - that seems to be the source of my trouble. I have now written a little test that uses serial.Serial and it works a treat. I am still confused about pyserial and serial - I found serial in my distribution library, (on the SuSe machine, not on the 2.5 in Slackware) but I had to download pyserial. I see that you were the the original author. Thank you for letting this stuff loose in the wild. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Saturday 15 August 2009 14:40:35 Michael Ströder wrote: > Hendrik van Rooyen wrote: > > In the past, on this group, I have made statements that said that on > > Linux, the serial port handling somehow does not allow transmitting and > > receiving at the same time, and nobody contradicted me. > > Despite all the good comments here by other skilled people I'd recommend to > determine whether the transmission line to the devices accessed support > full duplex. > > My knowledge is a bit rusty on this topic. But I vaguely remember having to > deal with symmetric two-wire connections (RS-485) which were definitely > limited to half-duplex by the wire. So the PC hardware was a normal serial > port with the usual UART hardware device but the transmission protocols > were limited to half-duplex. You raise a good point, that is probably not well known amongst the youngsters here, as simple serial multidropping has gone out of fashion. There is nothing wrong with your memory as far as RS-485 goes - you have to "turn the line around", same as for *shudder* Burroughs TDI (Two Wire Direct Interface). Otherwise, if two or more parties talk at once you have cacophony. An RS-422 link is to some extent worse, as it is capable of full duplex, but the slaves cannot hear each other, so they have to listen and play very nicely with the master. This instance Is not one of those, thank heaven - I am on both sides of the link - once in the eBox in python, and on the other side there is just one Dallas chip - a fast (30 Mhz single cycle) 8051 lookalike that I programmed in assembler. It is a thing that does discrete I/O that we have made for a customer. The link in between is just RS-232 receive and transmit without hardware flow control or anything fancy. This is why I was so certain that there was something wrong in my python part, because I could use the second port on the Dallas to do monitoring, by spewing stuff out into Hyper Terminal. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Saturday 15 August 2009 04:03:42 Terry Reedy wrote: > greg wrote: > > You can't read and write with the same stdio file object > > at the same time. Odd things tend to happen if you try. > > I believe the C standard specifies that the behavior of mixed reads and > writes is undefined without intervening seek and/or flush, even if the > seek is ignored (as it is on some Unix systems). With two threads, the > timing is undetermined. For a serial port, flush on write makes some sense, but seek is complete nonsense because it is undefined, and besides- the point you try to seek to may never come around. So the message I am getting loud and clear is that the basic thing I am doing wrong is to use the ordinary python open() instead of os.open(). As for the timing in two threads - Yes you are right, but there is not a lot one can do about it - The right solution depends to a large extent on what you are doing - for instance, if you are writing a polling protocol (such as Burroughs poll-select, or Uniscope), then you want a loop that transmits something, and waits for an answer or time out. This is essentially half duplex, and in a high level language the natural structure to write this is in one thread. On the other hand, if you are writing a sliding window type protocol that is capable of pouring stuff into a link asynchronously from both ends, then the natural way to do it is to use two threads - one to handle incoming stuff, and the other to squirt out the data that must go out. If, as is true in my case, the source of outgoing data and the sink for incoming data is a TCP/IP socket, then one can accomplish this with blocking I/O quite efficiently, provided you have a third thread looking after overall timing Issues. For such a case, the timing is essentially determined by the flow of the data (provided of course that you can keep up with the link speed). When one introduces another variable into the equation, namely the requirement to do a transmission at least every n milliseconds, (a feel-good keepalive) then you need a time out on the sources, so that you can either do a transmission or raise an alarm because a reporting period was missed. So then you are back at a loop waiting for input or timeout, and doing a transmission afterwards. Only now there are two of them, facing in opposite directions. I think this sort of thing is better written at a lower level where one has access to the interrupts from the ports, as well as a timer interrupt to handle timing and timeout issues. But that is a lot of work, so I make do with python. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Python 'for' loop is memory inefficient
On Saturday 15 August 2009 03:25:45 Dr. Phillip M. Feldman wrote: > It seems as though Python is actually expanding range(2,n) into a list of > numbers, even though this is incredibly wasteful of memory. There should be > a looping mechanism that generates the index variable values incrementally > as they are needed. There is. Use xrange instead of range, and try again. And while you are about it, you may as well teach them that it is much better to do a multiplication than a division. -Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Why does my ftp script quit after couple of hours?
On Friday 14 August 2009 18:25:50 kk wrote: > As far as robustness, I agree with your assestment. I guess my main > confusion with my result is that the console window just disappears. I > wonder if I can make the window stay even if it crashesor if there are > connection issues? I will createa seperate log file to see if I can > catch any issues in a log file. try opening python with the -i flag - then the console window hangs around after the script exits and you can examine variables and stuff. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: OT Signature quote [was Re: Unrecognized escape sequences in string literals]
On Friday 14 August 2009 18:11:52 Steven D'Aprano wrote: > On Fri, 14 Aug 2009 07:07:31 -0700, Aahz wrote: > > "I saw `cout' being shifted "Hello world" times to the left and stopped > > right there." --Steve Gonedes > > Assuming that's something real, and not invented for humour, I presume > that's describing something possible in C++. Am I correct? What the hell > would it actually do??? It would shift "cout" left "Hello World" times. It is unclear if the shift wraps around or not. It is similar to a banana *holding his hands apart about a foot* this colour. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Friday 14 August 2009 16:28:26 Grant Edwards wrote: > On 2009-08-14, greg wrote: > > Hendrik van Rooyen wrote: 8<--- > Doh! It didn't even occur to me that somebody would use python > "file" objects for serial ports, and I completely overlooked > the fact that the OP was doing that. > > In short: don't do that -- it just messes things up *grin* All right that makes me feel better - you were so adamant that there is no problem that I was starting to doubt my sanity. - So I hereby cancel the promise I have just made to put an example together. - It is no longer needed. > > Do not use Python file objects. Use the underlying file > descriptors: os.open(), os.read(), os.write(). That will > almost certainly solve your problems. > > If you want examples of os.x() usage, below is the > PosixSerial.py module that I use for Linux-only applications. > For cross-platform work, use pyserial (whose Posix support is > based on the code below). > 8< -PosixSerial.py Thanks that looks, on first inspection, similar to the serialposix.py module in the stdlib, but less cluttered. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Friday 14 August 2009 16:19:36 Grant Edwards wrote: > On 2009-08-14, exar...@twistedmatrix.com wrote: > > One strategy you might employ to get rid of the busy looping > > is to use Twisted and its serial port support. This also > > addresses the full- duplex issue you've raised. > > There are no such full-dulex issues. I will put an example together as soon as I have finished reading and answering the mail - maybe I am crazy and chasing angels. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Friday 14 August 2009 16:03:22 Diez B. Roggisch wrote: > You should *really* just use pyserial. No hassle, instant satisfaction. :-) I have downloaded and had a quick look, and I see it is based on the standard library's serial.Serial class - another battery that I have not used before. And I see that serial.Serial looks like it uses os. calls, which is one of the things Greg mentioned. Curioser and Curioser. There was one thing I saw in a quick read of pyserial that I did not like as I cannot understand why it is done - if a timeout is set to less than a tenth of a second, then it is changed to be a tenth. - In a polling protocol that will limit you to poll only ten terminals a second, or less, and is a very long time if a message takes only a couple of millis to send. I am getting there - this time around I want to kill this problem dead because I seem to keep doing something wrong somewhere and I want to understand what it is and stop doing it. - Hendrik -- http://mail.python.org/mailman/listinfo/python-list
Re: Is it possible to use python to get True Full Duplex on a Serial port?
On Friday 14 August 2009 16:19:04 Grant Edwards wrote:
> On 2009-08-14, Hendrik van Rooyen wrote:
> > In the meantime I have had another idea which I have also not tried yet,
> > namely to do independent opens for reading and writing, to give me two
> > file instances instead of one, and to try with that. I have no idea if
> > it would make any difference, or even work at all.
>
> That should work (and shouldn't make any difference)
>
> > My normal stuff works, but I do not like it as it is
> > essentially busy looping with short sleeps in between. In the
> > eBox, it uses most of the processor just to move a few bytes
> > of I/O in and out between the serial port and the TCP/IP, and
> > struggles to do that better than five times a second, while
> > the message time on the 115200 baud port is only about 2
> > milliseconds.
>
> What platform are you using? I suppose it's possible that
> there's something broken in the serial driver for that
> particular hardware.
Your experience seems to be exactly the opposite to mine - you are saying it
should "just work" and I am seeing half duplex functionality.
I have seen this on my development machine which is a dual processor of some
gigs running SuSe Linux 10.3, as well as on the other end of a the scale -
the eBox (a 400MHz 486 without floating point with 128 Mb of memory) running
Slackware.
Maybe it is in the way I set the port up, because that is the common thing.
What I do is this:
reterror = os.system('stty -F /dev/ttyS0 sane 115200 cread clocal raw -echo')
It does not seem to make a difference if I do this before or after opening the
port.
Any comments from a Linux Guru?
- Hendrik
--
http://mail.python.org/mailman/listinfo/python-list
