[Edu-sig] Python Workshop at Chapman University, Orange, CA, June 19-22, 2006
Dear edu-sig members, This email is to announce a summer workshop entitled "Python First: A Lab-Based Digital Introduction to Computer Science": http://www.chapman.edu/wcls/MathCS/sWorkshop/Python/default.asp This tuition-free workshop will be held on the Chapman University's campus in Orange, California, June 19-22 (Monday - Thursday). The workshop is intended for computer science educators who seek an alternative to either purely commercial languages, such as Java or C++, or educational languages, such as Scheme, for introductory computer science courses. The workshop will introduce participants to interactive program design with the Python programming language. Participants will also learn how to customize and manage a 'Python First' digital study pack. Daily activities will start with overview lectures and will continue with hands-on sessions in the computer lab. The summer workshop and all supporting materials are free. A nominal registration fee will cover meals and snacks. Transportation costs and lodging are the responsibility of the attendee. Please see: http://www.chapman.edu/wcls/MathCS/sWorkshop/Python/default.asp for complete details on the Python workshop and an on-line registration form. Or contact Dr. Arnold Shugarman ([EMAIL PROTECTED]) for more information. Respectfully, Atanas Radenski mailto:[EMAIL PROTECTED] http://www.chapman.edu/~radenski/ ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] FW: Properties use case
Arthur wrote: > My response to something Grégoire sent me this off-list is below. My > off-list response to him bounced. I see no reason why he would mind me > posted it up so I take the liberty to do so. Apologies if Grégoire feels > otherwise. Not something I generally like to do, but see no reason in this > case why he would be all sensitive to it. > > No problemo. I just forgot to cc the list. >> No I do not lock my circle. >> >> > Do you use threads ? > >>> In one sense, and it depends. >>> >>> There is the *option* of running a TK control panel that >>> provides functioning to control more aspects of the >>> interactivity with the rendering window than can be >>> controlled directly from the rendering window itself. >>> AFAIK, you won't have any problems as Tk is single threaded and explicitely forbids to call any Tk related function from an other thread. So unless you spawn an other thread yourself and make it interact in a non-atomic way with your objects you should be safe as the Tk mainloop will call your functions/methods in a sequential way. >>> Thanks for your interest in my question/dilemma. >>> You are welcome. -- Gregoire ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
[Edu-sig] FW: Properties use case
My response to something Grégoire sent me this off-list is below. My off-list response to him bounced. I see no reason why he would mind me posted it up so I take the liberty to do so. Apologies if Grégoire feels otherwise. Not something I generally like to do, but see no reason in this case why he would be all sensitive to it. Art > >-Original Message- > >From: Arthur [mailto:[EMAIL PROTECTED] > >Sent: Saturday, March 25, 2006 10:29 AM > >To: 'Grégoire Dooms'; 'Arthur' > >Subject: RE: [Edu-sig] Properties use case > > > > > > > >> >-Original Message- > >> >From: Grégoire Dooms [mailto:[EMAIL PROTECTED] > >> >> > >> >What is the question you ask here ? Do you want a > >certification that > >> >you have done your PyGeo The Right Way (tm) ? > > > >No. I see no issues and have some confidence in my overall > >design. People with more depth on some of these issues than > >I seem to be concerned that I am overconfident. I am simply > >trying to understand better why. > > > >*I* raised none of these questions. I raised what I > >understood to be a very specific, and - yes - technical > >issue about Numeric's typing mechanism. *I think* that *if* > >Numeric were to accept my custom type as a pseudo-complex > >type rather than something as general as a Python object, > >and processed it *as if* it were equivalent to a Python > >complex primitive, no harm would come to the calculations > >being performed and my ideas for the design I am pursuing, > >and am generally comfortable with, would proceed in an > >optimal manner. I am not *sure* that this is true. But even > >that question is not the question I raised. I was simply > >hoping to get far enough to be able to get some sense of > >whether it is true. I would be curious to learn why it is > >not, if it is not. But have no way of learning that if it > >is not even implementable. > > > >My question whether was and is - Is anyone aware, or > >could imagine, a mechanism that would allow me to coerce > >Numeric to process my custom type as a complex primitive > >while maintaining object identity? > > > >I have taken the silence as a *no*, a not terribly > >surprising *no*, and have begun to think about the > >implications of that *no* on my overall thinking about my > >overall design. > > > >I take reasonability for my design, but feel it not > >responsible to look-the-other-way when folks more > >experienced than I seem to have reasons to doubt its > >integrity - from the little I have said about it. Doubts > >have been raised and I am not looking-other-other-way. > > > >> >How do you store the dependency graph ? Is it cycle free (a > >> >DAG) ? How do you decide which objects need to be > >repainted when an > >> >other object is changed ? What is the overall design of the > >> >application ? > > > >Other then not knowing what a DAG is, I feel that the other > >issues you raise are under control in some reasonable way. > >Part of the Fun (tm) of doing PyGeo has been not just to > >find my way to solutions - first I needed to find my way to > >the issues. Eventually the issues seem to identify > >themselves, and in general the one's you raise have done so. > > > >Nothing yet (before these discussions) raised to me the > >issue of the thread safety of my geometric objects. > >Therefore I have not considered it to be an issue. > > > >I call the style in which I have approached the development > >of PyGeo - tongue-in-cheek - Naïve Programming. It's been a > >fascinating experience. > > > >But I am sincerely trying to inquire whether there could be > >something fundamental I have missed by this approach - only > >because the issue has been raised - presumably sincerely - > >by others. Perhaps it is so subtle as to be unidentifiable > >except under Extreme Circumstances (tm). Perhaps it doesn't exist. > > > >> >> No I do not lock my circle. > >> >> > >> >Do you use threads ? > > > >In one sense, and it depends. > > > >There is the *option* of running a TK control panel that > >provides functioning to control more aspects of the > >interactivity with the rendering window than can be > >controlled directly from the rendering window itself. These > >are more in the nature of changing some global settings > >on-the-fly, then they are about interactivity with the > >rendering and interactivity on a micro-second by > >micro-second basis - which, whether the control panel option > >is or is not selected - run together in one thread. In my > >conception of what is taking place, at least. > > > >Thanks for your interest in my question/dilemma. > > > >> >Best, > >> >-- > >> >Grégoire > >> > > >> > ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] > >On Behalf Of Michael Tobis > >Sent: Saturday, March 25, 2006 10:21 AM > >To: edu-sig@python.org > >Subject: Re: [Edu-sig] Properties use case > > > >Arthur (addressing you directly) does your code use any > >threading library at all? > > > >Did you bring up concurrency at all? > > > >If not, what do you suppose these people are going on about? I brought up threading and concurrency - and I think the record will bear me out - exactly to the same extent I brought up the question of the impact of my "cultural baggage" on my design decisions. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
I think they are "going on" about a very fundamental CS issue: mutable objects are not thread-safe. If threads are not an issue, then this has all been hot air, but it came up, IIRC, because the discussion mentioned the "mutable vs. immutable" issue, and this always leads one to concurrency nowadays, since so many applications have some level of concurrency (we take it for granted in the apps we use - and more programmers will have to face concurrency issues as time goes on; as Herb Sutter says, "The Free Lunch is Over"). Immutable objects are inherently thread-safe, and mutable ones are not. That's the simple truth, so, if one asks what's the diff, there it is. I believe that summarizes the past few days of discussion to some degree. No amount of further discussion will change the facts. The point I tried to bring up a while back was that numeric types tend to be *value types*, and they also are traditionally immutable, even without considering thread-safety issues. There is room for debate there, and I think Arthur has brought up some good points. He may have good reason for not having his complex be a value type. I was just saying that this was a departure from the norm, but hey, that what norms are for :-). Saturday, March 25, 2006, 8:21:03 AM, you wrote: MT> Arthur (addressing you directly) does your code use any threading MT> library at all? MT> Did you bring up concurrency at all? MT> If not, what do you suppose these people are going on about? MT> mt MT> ___ MT> Edu-sig mailing list MT> Edu-sig@python.org MT> http://mail.python.org/mailman/listinfo/edu-sig -- Best regards, Chuck ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
Arthur (addressing you directly) does your code use any threading library at all? Did you bring up concurrency at all? If not, what do you suppose these people are going on about? mt ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
On Mar 25, 2006, at 8:33 AM, Arthur wrote: > > >>> -Original Message- >>> From: Laura Creighton [mailto:[EMAIL PROTECTED] >>> Sent: Saturday, March 25, 2006 7:16 AM >>> To: Arthur > >>> Ok, so it does matter. Are you locking your complex number >>> before modifying it? > > Just to generalize the issue, so that I know, realy, what we are > talking > about, can we discuss my circle instead of my complex object. > > It has a center, a radius, and a matrix describing its orientation > in space. > I would like all to be in sync and recalculated, based on changes > to the > position of any other objects on which its center, its radius, or its > orientation in space is dependent, *before* it redraws itself. > > No I do not lock my circle. > > Art I think you are saying you don't quite understand when locks are needed. My apologies if this is not what you are saying, but here is a short explanation of when locks are needed. Whenever you have multiple threads that are using the same data structure you need a lock to ensure that only one thread is accessing it at a time. This is not an issue if none of the threads are modifying the object (which is the case with immutable objects since they cannot be modified). If at least one thread is modifying the object you need a lock around every access of the object otherwise you could have one thread start updating the object, be interrupted by the scheduler and another thread could then access the object that is now in an inconsistent state because the modification by the other thread had not completed. Consider two different threads both executing the code (with the same variables): y = x y = y + 1 x = y If one thread executes y = x and then is interrupted by the scheduler, and the other thread now executes all three statements, and then the first thread completes the final two statements, x is now just one more than it was before, even though both threads added one to it (i.e., it should be two more than it was). The solution to this each thread does: lock.acquire() y = x y = y + 1 x = y lock.release() This will not allow the second thread to start the code if the first thread has started it but not yet finished it. Again with immutable objects, this is not an issue. Also, as I understand it, Python's Queue class in the Queue module is thread safe (i.e., it essentially takes care of the locking for you). HTH, Dave ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: Laura Creighton [mailto:[EMAIL PROTECTED] > >Sent: Saturday, March 25, 2006 7:16 AM > >To: Arthur > >Ok, so it does matter. Are you locking your complex number > >before modifying it? Just to generalize the issue, so that I know, realy, what we are talking about, can we discuss my circle instead of my complex object. It has a center, a radius, and a matrix describing its orientation in space. I would like all to be in sync and recalculated, based on changes to the position of any other objects on which its center, its radius, or its orientation in space is dependent, *before* it redraws itself. No I do not lock my circle. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
In a message of Sat, 25 Mar 2006 03:02:31 EST, Arthur writes: >It doesn't matter to me any more than whether my tax calculations are >consistently correct were my class the one you described a few posts back >. > >I think I should perhaps appreciate that Kirby is the only one talking >straight to me. This programming business is quite over-my-head. > >Art Ok, so it does matter. Are you locking your complex number before modifying it? Laura ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Arthur > >Sent: Saturday, March 25, 2006 3:03 AM > >To: 'Laura Creighton'; 'Michael Tobis' > >Cc: edu-sig@python.org > >Subject: Re: [Edu-sig] Properties use case > > > >It doesn't matter to me any more than whether my tax > >calculations are consistently correct were my class the one > >you described a few posts back. Can someone remind me why we are talking about threads related to my complex number class? Which I think we have agreed is just in the end a class like any other class. My general understanding is that unless there is some special reason to get into it, stay away from trying to manage multiple threads of execution in general, and in Python in particular. Should I not be using classes? Sould I not be using threads? Should I not be using Python? Should I not be programming? Which the hell is it, damn it. Art Are we talking OS threads that are somehow unavoidable? ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
Re: [Edu-sig] Properties use case
> >-Original Message- > >From: [EMAIL PROTECTED] > >[mailto:[EMAIL PROTECTED] On Behalf Of Laura Creighton > >Sent: Saturday, March 25, 2006 1:13 AM > >To: Michael Tobis > >Cc: edu-sig@python.org > >Subject: Re: [Edu-sig] Properties use case >> It has also not > >been clear to me whether he _cares_ if he uses a > >half-modified complex number in the course of running > >things. Maybe for his purposes this doesn't matter. It doesn't matter to me any more than whether my tax calculations are consistently correct were my class the one you described a few posts back. I think I should perhaps appreciate that Kirby is the only one talking straight to me. This programming business is quite over-my-head. Art ___ Edu-sig mailing list Edu-sig@python.org http://mail.python.org/mailman/listinfo/edu-sig
