Okay, thanks, I'll probably be proceeding over the next few weeks, as I finish up my Chutes & Ladders project... I think I have to do a bit more code/manual reading in proportion to my coding for a bit, also. Thanks for the insights.
K On Fri, Jan 3, 2014 at 6:12 PM, spir <denis.s...@gmail.com> wrote: > On 01/03/2014 10:53 PM, Keith Winston wrote: > >> My concern is with speed. This will have to keep up with (somewhat >> arbitrarily) fast typing, while doing background processing, with a GUI of >> course. >> > > I wouldn't even bother. Try & see, you may be surprised. There are several > factors at play: > * The core processing in dealing with user input (read, decode, store, > queue key strokes, etc) will be done by low-level (OS) routines written in > C, with only thin Python wrappers (which essentially translate from/to > python data types). > * Similar point for GUI and/or other user interface layer (less so if > you'd use a pure python GUI framework, but in general they're also just > wrappers over C code). > * The ratio between such low-level processing and actual processing code > written and executed in python for your application logic is certainly high > (as is usually the case), unless there is much realtime computation you did > not speak about. > Anyway, just try and see. > > This is similar to how & why python is reputed to be good (read: fast) at > "number crunching": they are standard libs for that just link to low-level > C routines which do about all computation, behind the stage, and very few > application logic remains written *and actually executed* in python (search > "numpy"). > > Denis > _______________________________________________ > Tutor maillist - Tutor@python.org > To unsubscribe or change subscription options: > https://mail.python.org/mailman/listinfo/tutor > -- Keith
_______________________________________________ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
