Mailman 3 August 2001 - Edu-sig

re: PythonScript
by Arthur Siegel 05 Aug '01

05 Aug '01

>On the other hand, we wouldn't want to turn of case- >sensitivity if the goal were to train future Python >programmers I don't think. That'd just set them up to >have to unlearn a lot of reflexes -- same with numerics >it seems to me. But then, maybe you're not proposing >this environment for would-be Pythonistas. No indeed I'm not. But I am trying to recognize the existence of the other constituency relevant to Edu-Sig - e.g., the physics class scripter of VPython or the geometry class scripter of PyGeo. And am arguing, I guess, that to the extent it is determined that this constituency may have unique requirements, that efforts to accommodate them be set aside as a special project, not an issue of central concern to the mainstream development of Python. I, BTW, do not necessarily agree that those needs are unique. VPython is not only visual Python, it is visual Numeric - which relies on typing of arrays, with all kinds of traps for the uninitiated, unaware, or the uncareful. Typical was the Zero Division "bug report" on the main list. Some variant of: a=array([1,2,3]) snip,snip,snip a[0]=.4 1/a[0] = BOOM/CRASH But I just set a[0] explicitly to .4 and Python is treating it as zero, therefore bug report. The VPython class members who *only* got trapped by 3/4 were probably not doing their homework. ART

1 0

PythonScript
by Arthur Siegel 05 Aug '01

05 Aug '01

What not a PythonScript variant? VPython is itself all C. Its purpose is to expose some functionality to Python scripting, but it is not Python itself. Wouldn't a relatively small sub-set of Python functions accommodate the needs of this kinds of project. And since it is geared for a specific constituency and use, things like case insensitivity, simplified numerics, etc. become "cost effective" - clearer benefits, less cost to others. A real light weight distro with limited library support, but a clear and simple C extension API. What am I missing. Undoubtedly something. ART

2 1

long int / long int = ??
by Brent Burley 05 Aug '01

05 Aug '01

It has been noted that int/int=int results in more information loss than int/int=float. Based on this, it has been proposed that anything/anything return float. This got me wondering about long ints. Given that a long int can have an unlimited number of digits (easily into the thousands), the result of a long/long could also be an unlimited number of digits (considering just the integer part). Given that a float can only represent about a dozen or so digits of precision, the precision loss due to float conversion could be much greater than the precision loss due to dropping the fractional part of the long division. It's as if you're compressing an unlimited amount of information into 8 bytes. Also consider that float can only represent numbers up to about 1e308. Any result > 308 digits would result in a float "inf" - total information loss. I therefore argue that long int division should not result in a float. There have been discussions about a unified numeric model for python. One suggestion is to automatically promote to long int on int overflow. If int/int=float and long/long=long, auto-promoting int to long could cause strange and unpredictable results. However, if a/b=float for all types, this would be unfortunate for the long/long case for the reasons mentioned. Are rationals the answer? They would provide zero information loss for integer division and consistent behavior between integers, rationals, and floats. So, if rationals are coming, is int/int=float just a stopgap? Is it worth the pain? Brent

2 1

Re: [Pythonmac-SIG] Working interactively with IDE (refreshing script; namespace updating)
by Jack Jansen 05 Aug '01

05 Aug '01

I think I would categorise this as a bug in IDE, I think it should clear out the namespace of the module before running it again. Or at least there should be an option alongside the "run as __main__", "run profiled", etc. to get this behaviour. -- Jack Jansen | ++++ stop the execution of Mumia Abu-Jamal ++++ Jack.Jansen(a)oratrix.com | ++++ if you agree copy these lines to your sig ++++ www.oratrix.nl/~jack | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm

1 0

Working interactively with IDE (refreshing script; namespace updating)
by Christopher Smith 05 Aug '01

05 Aug '01

After reading the "Up All Night with IDLE" thread http://mail.python.org/pipermail/tutor/2001-January/003082.html and seeing the post by Patrick regarding "Refreshing a script" I came up with the following way to work with IDE: The problem: When you are working on a script in a window and you make changes to an object (variable, function, etc...) name, the old object still exists. This means that you will not always get an "is not defined" error even though you would if you quit and tried to run your script after restarting IDE. Example: ORIGINAL x=2 print "x=",x MODIFIED y=1 print "y=",x ## <--forgot to change the 2nd x # the modified program will print "y= 2" -- even # though the x variable is undefined in the script it is # still remembered by Python in this IDE window and # that is what you told it (inadvertently) to print. A solution: Work with two scripts, one to load your active work and one containing your developing script: # tester.py (this just loads and reloads your work) import mywork reload(mywork) mywork.testmywork() # mywork.py (this is the one that will contain your work def testmywork(): x=2 print "x=",x When you make changes to "mywork.py" and *save* these changes and then run the "tester.py" program as written, you work in "mywork" will be reloaded and if you have a modification like shown above, you will generate an error since x is not defined. When your scipt runs as you want it to, copy the text of "mywork.py", delete the first line, and unindent one level and save under a new name. The one-best-solution (IMO): IDE would automatically do this sort of thing with a script that is being run --not in the interactive window which prompts you with the ">>>" but in the script windows that are created and used to write new scripts. /c

1 0

re: [Edu-sig] More re: Advanced or beginner?
by Arthur_Siegel＠rsmi.com 02 Aug '01

02 Aug '01

Kirby asks - >When teaching Python, do we begin with a treatment of >low level representations of data? Or is that saved for >a later time? Good question. Truth of the matter is that I don't consider myself a beginner anymore, but I am lost even trying to follow your illustration. But I do have a top-level awareness of data structure issues, and that has been essential to understanding the environment. IMO top-side awareness is crucial. The details can follow. So your illustration to me would be more of a "for example watch what happens when" rather something that needed to be grasped in its full detail. ART

1 0

Re: Changing the Division Operator -- PEP 238, rev 1.12
by Arthur_Siegel＠rsmi.com 02 Aug '01

02 Aug '01

Kirby writes - >But then, programming with variables, the type of which may not >be readily known to the reader, is not the same thing as raw >entry of numbers into a calculator. Just looking at raw numbers >is to all together miss the point of adding a // key to this >calculator (and saving / from doing double-duty depending on >the type of inputs we feed it). I guess I do communicate poorly. My point was totally something else: What a end-user understands themselves to be working with determines their experience wth it. If they aren't clear that they are in an environment where something other than calculator numerics is at work, the fact that they are getting results inconsistent with normal calculator numerics seems broken. If their expectations are put properly in line with what they are going to experience, the experience is changed. By ultimate point is that I think that there has been an implicit assumption that lessons learned from environments like VPython in a college physics class are somehow relevent or meaningful when speaking of, let's say, a beginning programming class. I contend that they are not different shades of gray. They are just different, period. Design decisions that might well be good for one constituency, could be directly counter-productive as to the other. It would be better if things were simpler. Its not my fault that they may not be. I happen to have a deeper interest in one constituenecy than the other. So I have been struggling to get this simple distinction on some map. Very badly. ART

1 0

re: More spillover re the division PEP
by Arthur_Siegel＠rsmi.com 01 Aug '01

01 Aug '01

Kirby writes - >I think Arthur points too much emphasis on someone >writing their own programs and following the unambiguous >rules in the tutorial, vs. someone inheriting code written >by others, and trying to puzzle out what's going on. If we are disagreeing, I'm not sure where. I thought we were coming to similar places - just from different angles. Kirby also writes - >In any case, these are all just hats. I'm a newbie >with respect to language A, casual user of B, non-user >of C, pro with D. Always a newbie, always a pro - >that's life in the big city. Here we are disagreeing. I liked where you started better - newbie in the sense of new to programming different from newbie in the sense of prior programming experience new to Python. Quite different. I attempt to add a third category. Scripter. You seem to disagree with my assertion that we need to be more explicit than "newbie" when discussing something like the divisor operator. Who stumbles, why, and what accommodation to their pre-existing expectations are possible or wise. I think it is impossible to speak productively of "newbies" as a group in having such a conversation - because all the conversation ends up being is about different peoples different definition of the word "newbie", caste as a discussion about something else. ART

5 7

Re: Changing the Division Operator -- PEP 238, rev 1.12
by Arthur Siegel 01 Aug '01

01 Aug '01

Bruce writes - > I think you are missing something... > If you were designing a control system for the `toys', and needed to > expose a user level programming interface; would you be more likely to > choose languages C+S or language P (which can do both jobs) > [C+S == P, of course]. > > Unless CP4E is done as a "semantic game" with a larger language, > language P will never exist. Or else I am expressing myself badly and you are missing something of my point. Let's take one little such toy. A calculator. One that does undisguised Python numerics - 3/4 = 0, 3.0/4 = .75. But let's give them 2 different names. One is called the Python Calculator and the other the Python Numeric Type Calculator. One is sadly broken and the other works perfectly - but they are exactly the same little toy. If you see my wonderfully made little point. ART

2 2