Mailman 3 September 2002 - Edu-sig

Re: Still working on rational numbers PEP?
by Kirby Urner Sept. 30, 2002

Sept. 30, 2002

============ "Christopher A. Craig" <ccraig(a)ccraig.org> wrote: I think your problem is in assuming that Python 3 division will return a float. The plan for Python 3 is that the / operator will return "a reasonable approximation to the mathematical result of division."[1] The reason it is presently slated to return a float is that there is no rational in Python. Guido has even stated [2] By the time 3.0 comes around, (1L<<2000)/1 will probably return a rational number. But until we have added rationals, I think that for most apps, long/long -> float is the only definition that is consistent with the other requirements... So if rationals go in before 3.0, 1/2 may be the rational one-half and not the float 0.5. Changing the behaviour of the divide operator is going to break a bunch of code regardless of whether the new code returns a float or a rational, but that breakage is already scheduled to happen. > >>> a = 1r2 + 1r2 > >>> a > 1 > >>> 1/a > 1 > >>> a/3 > 1r3 > > If you have the time, please show me how you would express the > above using your proposed extensions. > >>> 1/2 1/2 >>> a = 1/2 + 1/2 >>> a 1 >>> 1/a 1 >>> a/3 1/3 >==================================================================== Kirby: I think there's an option to be less radical and break less pre- existing code. According to the above scenario, code rewritten to accommodate 1/2 == 0.5 as per recent changes, will have to be rewritten *again*. I would prefer to see / return a rational if and only both arguments are rational. Otherwise it should return a float, as per the current plan. Rational arithmetic is in general rather expensive, and the expectation the 4/17 will take us into floating point territory is entirely reasonable I think. Only if 4 and 17 are both type rational would 4/17 then not return a type float answer. So I would prefer we keep the option to go: >>> 5e_1 0.5 >>> 1r2 1r2 on the table. Maybe I will subscribe to python-dev and try to at least prompt a little worthwhile discussion of the proposal, recognizing that it may well be dismissed. Or you could do a quick blurb on "what Kirby thinks". In the meantime, I'm CC-ing this to edu-sig, where this thread got started (for me). I thank you for you patience in bringing me up to speed on the current proposal. Given we're in the initial stages of this and a lot of Pythonistas may not be aware of the J language option, which is quite viable, I think it should at least be looked at. In J, the division operator is % (because / means something else). So in J, a conversation might go like this: 1%2 NB. i.e. 1/2 -- same as Python 2.3 0.5 1r2 1r2 1r2 + 1r3 5r6 1%2 + 1%3 0.428571 The last line above is a surprise -- because J (unlike Python) has no concept of operator precedence (Python should stay the way it is of course). 1%2 + 1%3 really means (in Python) 1/(2 + (1/3)). To get more what we'd expect, we go: (1%2) + (1%3) 0.833333 (x:0.5555) % 1r2 NB. x: coerces 0.5555 to be rational 1111r1000 In Python, we might go: >>> rat(0.5555) 1111r2000 >>> rat(0.5555)/1r2 1111r1000 The main objection to my proposal, I think, is that it seems to return us to the bad old days (like now), when / can do different things depending on the types of the operands. But of course that's true with many operands. float + float is float, int + int is int. The objection, specifically in the case of division, is you "lose information" by returning 0 in place of 0.5 (depending on whether this is int/int or float/float) -- these are NOT "reasonably equivalent" answers. In contrast, returning a rational type would be to return the *fractional equivalent* of a float, i.e. the results are arguably the same, within tolerance. Just as 1.0 == 1, so 1r2 == 0.5 == 5e_1. so no information is lost, perhaps conforming to Guido's long term intentions for / (of course I don't speak for Guido in any way -- maybe I'm way off base here). In J, when you coerce pi to a rational, you get: 1285290289249r409120605684 which in floating point is 3.1415926535896439. That's not *quite* the same as >>> math.pi 3.1415926535897931 but in Python we'd be free to go to more decimal places using longs in both numerator and denominator -- if we want (could do that in J to -- I'll have to ask why they didn't). Kirby

1 0

Are you series() on teaching with range()?
by Fotis Georgatos Sept. 28, 2002

Sept. 28, 2002

So, I just finished a presentation today in an educational conference here in Rhodes (Greece) regarding a research work done with Python during last year. (look for more on that at http://amstel.science.uva.nl/~fotisg/python/) In the meantime, I have optimized my wrapper function for the xrange() keyword, and its range() equivalent, which both seem to constantly confuse a few novices: >>> def xseries(first,last,step=1): if last>=first and step>=0: return xrange(first,last+1,step) elif last<first and step<0: return xrange(first,last-1,step) return [] >>> def series(first,last,step=1): return [x for x in xseries(first,last,step)] >>> series(100,-8,-3) [100, 97, 94, 91, 88, 85, 82, 79, 76, 73, 70, 67, 64, 61, 58, 55, 52, 49, 46, 43, 40, 37, 34, 31, 28, 25, 22, 19, 16, 13, 10, 7, 4, 1, -2, -5, -8] Compare with... >>> range(100,-8,-3) [100, 97, 94, 91, 88, 85, 82, 79, 76, 73, 70, 67, 64, 61, 58, 55, 52, 49, 46, 43, 40, 37, 34, 31, 28, 25, 22, 19, 16, 13, 10, 7, 4, 1, -2, -5] Am I the only one reporting this case with range()? PS. A random gift... http://amstel.science.uva.nl/~fotisg/python/documents/computer_languages_ev… And if you decide to read the .pdf on the same site, prefer to print it in order to read easily the anecdotal footnotes... cheers, Fotis

1 0

Top 5 All Time Novice Obstacles => #1 ImportError: No module named xyz
by Jason Cunliffe Sept. 26, 2002

Sept. 26, 2002

Hello I've posted here on this before, and naturally received supportive answers. But it just keeps coming up, especially after upgrading/reinstalling Python. Since this is Edu-Sig, and we're on the topic of novice obstacles, I'd love hear your fresh opinions... 1. I downloaded installed Leo, a new Python package. A simple process and it runs great..yay! Leo even lets me open a familiar Python shell directly [Idle/Tk] where I can successfully explore Leo's Python API examples: Chapter 7: Scripting Leo with Python http://personalpages.tds.net/~edream/scripting.html 2. The manual mentions I can invoke Leo from Python. So I launch Idle and try: Python 2.2.1 (#34, Apr 9 2002, 19:34:33) [MSC 32 bit (Intel)] on win32 >>> import leo >>> import leo Traceback (most recent call last): File "<pyshell#0>", line 1, in ? import leo ImportError: No module named leo >>> find leo SyntaxError: invalid syntax >>> find(leo) Traceback (most recent call last): File "<pyshell#2>", line 1, in ? find(leo) NameError: name 'find' is not defined 3. arghh.. Clearly the problem is a simple one. My Python IDLE knows not where 'Leo' module is, but Leo does know where Python is. I've been through this Python import pain enough times so I know how to fix it: >>> import sys >>> sys.path ['C:\\PYTHON22\\Tools\\idle', 'C:\\Python22', 'C:\\PYTHON22\\DLLs', 'C:\\PYTHON22\\lib', 'C:\\PYTHON22\\lib\\lib-tk', 'C:\\PYTHON22\\lib\\site-packages'] >>> sys.path.append('c:\\program files\\leo') >>> import leo >>> leo <module 'leo' from 'c:\program files\leo\leo.pyc'> >>> ok :-) 4. Next time I launch Python from Idle, I have to go through this again, until I learn how to manage import paths via shell, in scripts and with persistent additions to sys.path also. 5. For a novice I believe this is waay too obstructive. Its geeky, and non-intuitive. I am *not* proposing to dumb down Python. But I am proposing to give timely novice crucial help, where needed. The 'import leo' exercise involves a very sophisticated Python application, but exactly the same is true if I write the simplest 'helloworld.py' and save it almost anywhere on my computer. 6. What to do? What do I propose? I suggest that ImportError is #1 all-time Python novice gotcha. For god sakes help people.. Suggestion A. HELPFUL ERROR PROMPT Instead of >>> import helloworld Traceback (most recent call last): File "<pyshell#0>", line 1, in ? import leo ImportError: No module named helloworld How about >>> import helloworld Traceback (most recent call last): File "<pyshell#0>", line 1, in ? import leo ImportError: No module named helloworld *** Python needs to know where "helloworld" is located. import sys sys.path # Shows which directories Python knows to search and load from. You must add the path where "helloworld" is located, then try import again sys.path.append('C:\\path-to-hello=world\\') I am sure you can improve upon this help prompt. Python programmers know perfectly well what to do. It in the tutorials and docs. But why not serve it up for beginners. A "novice-help-prompt-config.py" file could be bundled with Python to allow people to control and modify it. For example a teacher could add urls to docs, on-line courseware notes. Also localize the paths advice better to reflect local operating system locations more cleanly. Sophisticated Python Pros could disable these novice messages with a single line: novice-prompts = OFF User logins, machine IPs and other contexts could be used also to invoke, disable or switch the messages [LongFormTutorial, French, Korean, etc..] Suggestion B. ACTION ERROR PROMPT This version says don't just suggest, do something. In other words run 'import sys' and 'sys.path'. Then ask the user if Python should search the system for possible locations of 'helloworld' If Python finds any, return a visible command list and ask which one to invoke, always using the official sys.path.append() syntax so they can learn the syntax pattern quickly. Since searching for 'helloworld' could be time consuming and error prone, the "novice-help-prompt-config.py" could limit or prioritize the automated find path. Just like any operating system find tool. You may argue that students should learn to use find and be more responsible for files. Of course they should, but it takes time and out-of-the-box Python is unfriendly and terse. I argue, that to help true beginners, *Python* should learn to "use 'find' and be responsible for files"! Suggestion C. LONG-TERM & STRATEGIC HELP Assuming students may want to avoid the error next time they launch Python, what can we do? Well one idea is keep an error history, and parse it see if there are repeats. Another is provide help to reduce the problem directly by showing how. For example show how to make this persistent: sys.path.append('C:\\python\\edu-sig\\helloworld\\]) And next time student logs in and launches Python, the prompt can show what was added to sys.path. We cannot anticipate everything.. and don't need to. That's why this is titled the "Top 5 All-Time Novice Obstacles" Python could be much smarter and friendlier to novices. The tools and experience are not lacking. ./Jason

6 23

readable vs. writable <<>> shell vs. editor
by Jason Cunliffe Sept. 25, 2002

Sept. 25, 2002

[Follow-up on my recent harvest full-moon rants] Tim Peters is right as usual. My assumptions that most people very quickly feel comfortable with Rebol are mistaken. Some do, some don't. The ones who stay with it [and whom I encounter] mostly tend to be the people who took to it like ducks to water. The others indeed flounder, finding the freeform dynamic qualities hard and confusing. I've been asking why, and considering characteristics of Python and Rebol as I switch between them.. Python is very architectural and its #1 characteristic is readability and consistency. As Guido and Tim quickly pointed out, Python leaves one in no doubt. Reading other people's Python code is therefore especially valuable for learning. Python encourages one to think structurally, by its design and with the tools it provides. It is also very writable. The shell and immediate self awareness of new objects in the dictionary. One analogy is how well one quickly one can follow when entering a movie or conversation somewhere in the middle. Python provides full-time subtitles, free headset with UN translator and an index for the whole event. ................... Rebol is conversational, narrative and poetic. It is very writeable [like FORTH], because one can build up words and meaning rapidly inline as part of a message stream. Rebol programmers perhaps depends more on the shell. I think in Rebol people have more iterative writing workflow sessions, using frequent cut and paste in both directions. Moving between shell and editor to refine elegant short final versions. Rebol is harder to read. It depends upon a core vocabulary, fluency of idiom, building pattern recognition. And upon the skill with which the writer chose his words. It is poetic like good FORTH. Leo Brodie's classic book "Starting Forth" described this art and process well. Rebol is a little like a movie where one can get out of one's seat and climb right into the film and join in the conversation. You may or may not be welcome and understood by those there. Exciting, uncertain stuff. "Purple Rose of Cairo", USA [] dir: Woody Allen http://dvdmg.com/purpleroseofcairo.shtml "Escape from Cinema Liberty", Poland [1991] Exuberant attack on censorship parodies Polish politics and 'The Purple Rose of Cairo' in the same breath. 92 min. http://www.hollywood.com/movies/detail/movie/179041 http://www.y.net.ye/polemb/kulturae.html I'd be interested to hear how others move between shell and editor in Python.. What have you observed about beginners and developing habits? ./Jason

1 0

re: Python sequences by reference - how to make
by Arthur Sept. 25, 2002

Sept. 25, 2002

Kirby writes - >I'd think the math people would be especially easy to educate: >just as you must import sin, cos, log, so must you import copy, >i.e. lots of functionality is in the libraries (same with C, >same with Java, same all modularized languages). I agree, at least in some sense. And one of the questions I suggested needed to be answered is how far my experince could be generalized. My situation was - little outside direction, and a lot of pounding at the command line. So I cannot claim that my view is tremendously relevant to folks learning Python in some fundamentally different way, i.e. to folks being "educated" in some more formal environment. Which is one of the reason I can be reasonable in respect to anyone's suggestion that my concept here it not ready for prime time. Art

1 0

Fw: Python sequences by reference - how to make
by Arthur Sept. 25, 2002

Sept. 25, 2002

I vowed not to make a mission of my copy import issue. And in my mind am living with it. But I do think it is an intersting point to discuss. Happens the the Quote of the Week from this weeks Dr Dobbs weekly Python URL http://www.ddj.com/topics/pythonurl/ is a Martelli quote that is from his response to the same post from Michal to python-list that instigating the discussion here. QOTW: "When something "is *EVERYWHERE*", how can it be "clearly VISIBLE" at the same time?" - Alex Martelli http://mail.python.org/pipermail/python-list/2002-September/123526.html A slightly fuller excerpt: """ *EVERY* assignment in Python uses reference semantics. Every occurrence of an assignment, therefore, makes reference behavior "clearly VISIBLE". Presumably fish don't find water "clearly VISIBLE", being used to that, much as it is for us and air. When something "is *EVERYWHERE*", how can it be "clearly VISIBLE" at the same time?-) """ Is it possible that "copy" clearly in the game as a built_in makes us slightly more amphibious? Hate to think that Martelli's suggestion that math types might need to stick with languages that implement a more uniformly functional model, is the only answer to this issue. Art

4 4

Re: [Edu-sig] More re Cross-pollinating Python with other Cool Languages
by Kirby Urner Sept. 24, 2002

Sept. 24, 2002

At 10:16 PM 9/23/2002 -0400, Guido van Rossum wrote: > > (1j)^10 is an unsupported operand type for ^ > > > > yet pow(1j,10) is just fine. Why not have ^ invoke pow internally, > > if pow is more able to manage complex arguments? > >Because ^ means xor in Python, ** is power. :-) Oh yeah... (duh...) > > Anyway, the idea wanted to underline was the coolness of > > letting 1r2 mean 1/2 -- it's a primitive number, like 1e10, > > not a 'string' result of repr(). If Python ever incorporates > > a rational number type at the primitive level, I wonder if > > this'd be a way to go. [etc.] > >This is the subject of two PEPs, PEP 239 and 240. I hear that a new >author is taking over editing, so maybe you'll find a willing ear >there. Thanks for the pointer. Kirby

1 0

Top 5 All Time Novice Obstacles => #3 Where am I ?
by Arthur Sept. 24, 2002

Sept. 24, 2002

Jason - One other thing I think worth commenting on. In looking at ActiveScript and Rebol, you are looking at projects of an essentially different kind than Python. As commercial products, they maintain a consistency of look, feel, approach which can be comforting and confidence inspiring. Python is an open source project with many people with their own approach and asthetic contributing to different aspects. Less "coherent" in some senses. I don't recall the details, but I think it is accurate to say that pydoc was built outside of the mainstream of Python development, by a volunteer developer. Guido made the decision to incorporate it into the distribution, but I believe, let it stand pretty much pat. (Somehow I feel he might correct me if I'm wrong) So it has maybe someone else's precise look and feel, rather than one uniformly "Pythonic" or "Guidoic". Could seem a little hodgepodge compared to a strictly commercial type product. But in the end it all seems to hang together quite well. But takes some getting used to, no doubt. Not that I mean to insult you about not having worked alot with open source type projects. But just don't know whether yu have made the connection here to what might be bugging you. Art

5 11

re: CP4E-2002
by Arthur Sept. 23, 2002

Sept. 23, 2002

Jason asks - >Relative to your original CP4E grant proposal where you think Python stands now? >If we were writing a CP4E-2002 proposal what would be the key points? I realize that you question is to Guido and I am quite sure I am not him. But I am in a *very* talkative mood today. What I would hope Guido might do is one of two things. Withdraw the proposal. There is simply no evidence of which I am aware that children have the cognitive capacity to do anything that is properly called programming - depending of course, and this is the key to it all, on how one defines the term programming and who one considers a child. Under my definitions, we have a no go. I certainly do not blame that reality on Guido. But nor do I expect him to have the capacity to change it. Else, Define the terms carefully. What do we mean by "programming" when we are talking about what it is that we hope to be able to expose to children. What Guido and Tim do? Obviously not. What I do? I humbly suggest not. What my son did at 7 or 8 with his more education video games? SimCity, e.g. Maybe. In which case there is *lots* going on out there, and it is presumptous to think that Python is bringing anything radically new to the table. So to me the question has always been moving clearly past semantics, to a clear definiton of terms and expectations.Don't think that happened very well the first time around. Art

5 8

Re: [Edu-sig] re: CP4E-2002
by Phillip Kent Sept. 23, 2002

Sept. 23, 2002

>To: Arthur <ajs(a)ix.netcom.com> >cc: edu-sig(a)python.org >Subject: Re: [Edu-sig] re: CP4E-2002 >From: Guido van Rossum <guido(a)python.org> >Date: Sun, 22 Sep 2002 22:33:52 -0400 > >Art, have you actually *read* the CP4E proposal? Or are you basing >your rejection still on the article I wrote for LJ? > >I am not so naive to expect that most children of 7-8 years old can >learn to program -- though there definitely have been unusually >talented children that young who *have* used Python (and everything >else from Basic to assembler) successfully to create what can only be >called computer programs. > >--Guido van Rossum (home page: http://www.python.org/~guido/) I've haven't been reading this thread in detail - but if anyone is interested in the extent to which young children can learn to program, I recommend checking out a project by colleagues of mine, "Playground", which was precisely aimed at investigating what 7-8 year old children could learn in a "visual programming" environment (ToonTalk - www.toontalk.com ) - www.ioe.ac.uk/playground (The web site is a bit neglected, since the project is finished - but email them for more details) Piaget is often wheeled out in arguments like this to "demonstrate" that children cannot access formal reasoning until they achieve the "formal stage" (around 12 years old). However, I think the case against Piaget is pretty conclusive now (besides, Piaget is "out" in educational theory and we're all supposed to "into" Vygotsky nowadays). An old, but very very good argument for why computers change mental performance is "Mindstorms" by Seymour Papert (1980). And more recently, "Changing Minds" by Andrea diSessa (MIT Press, 2000). - Phillip ++++++ Dr Phillip Kent, London, UK mathematics education technology research p.kent(a)mail.com mobile: 07950 952034 ++++++

2 1