Mailman 3 July 2001 - Edu-sig

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: [Edu-sig] When to introduce OOP
by Chris Meyers 28 Jul '01

28 Jul '01

Hi Tim, I just completed teaching a 15 hour little survey course on Python at the community college here in Eugene. It went pretty well, particuarly since it was the first time for me with this material. I tried to make the course sort of data-oriented. Concentrated on first simple data types, numbers and strings and then moved on to lists and dictionaries. Treated the rest of the language as just operators on the data, so introduced "for" along with lists, etc. We mostly played with small pieces of code, often at the interactive prompt. Near the end I introduced 2 larger programs. The first was strictly procedural, a tic-tac-toe that showed off functional decomposition pretty well. That was last week. In the last 3 hour class this week we first looked at object oriented stuff and then showed an OOP simulated card game. This game will be a chapter in the OBP book real soon now. People seemed to have no problem with OOP this early. Some of it might be that they were already used to composite data with lists and dictionaries. Including things like nested lists etc. So objects referencing other objects was ok. Tying methods to objects, no problem. Inheritance a little trickier but still ok. My impression is that the two programs were about the same in complexity and size. But my students had to struggle more with the procedural one. There were a lot more smiles this week than last. I think maybe it's all about being able to map the code to a model in your head. As Kirby said, you still got to use procedural code to stuff into the object methods. I vote for using OOP as early as you can and have them use it if they are writting programs. Set good habits early. Chris Meyers 07/27/2001 8:21:27 PM, Timothy Wilson <wilson(a)visi.com> wrote: >Hi everyone, > >I'm working on planning my Python course for this fall, and I'd like to get >the group's advise on when I should introduce OOP. I work with Zope a lot >and the OO paradigm is pretty deeply embedded there. I've really gotten to >like it. (Not that I've mastered it. :-) > >Now I'm fully aware that Python is just as capable a procedural programming >language as it is an OO one. I don't want to skip talking about that side of >things, but OOP seems so prevalent in many areas that I'd like to get my >students working with it as soon as possible. > >I'd appreciate any thoughts you might have on this topic. > >-Tim > >-- >Tim Wilson | Visit Sibley online: | Check out: >Henry Sibley HS | http://www.isd197.org | http://www.zope.com >W. St. Paul, MN | | http://slashdot.org >wilson(a)visi.com | <dtml-var pithy_quote> | http://linux.com > > >_______________________________________________ >Edu-sig mailing list >Edu-sig(a)python.org >http://mail.python.org/mailman/listinfo/edu-sig >

1 0

re: Changing the Division Operator -- PEP 238, rev 1.12
by Arthur Siegel 28 Jul '01

28 Jul '01

from PEP 238, rev 1.12: >A unified numeric model removes most of >the user's need to be aware of different numerical types. >This is.good for beginners, but also takes away >concerns about different numeric behavior >for advanced programmers. FWIW, I think in here is a precise enough to be useful word for what I have always identified as the prime CP4E constituency - the "beginner". Someone at the early stages of a process. But within a process - formal or informal. Very different implications from the word "non-programmer" which, IMO, has very unfortunately been consistently used as a near synonym. I don't think that word has enough precision to be useful. And lack of language precision has been the real devil in all this, I happen to be quite convinced. With much less vehemence and confidence than I express the above opinion, I register my reservations about whether a unified numerical model is in the best interest of the beginner. Certainly I can see the "for" argument. Which is perhaps more consistent with a Programming for the Fun of It ideal, than is the source of my reservations. Reserve the right to mouth off only when a PEP addresses the needs of beginners as the *prime* motivation of a foundation level change. Trying to keep in mind that as Kirby says as to himself, I am not in the leadership - and it is the leadership with the track record, not me. ART

1 0

When to introduce OOP
by Timothy Wilson 27 Jul '01

27 Jul '01

Hi everyone, I'm working on planning my Python course for this fall, and I'd like to get the group's advise on when I should introduce OOP. I work with Zope a lot and the OO paradigm is pretty deeply embedded there. I've really gotten to like it. (Not that I've mastered it. :-) Now I'm fully aware that Python is just as capable a procedural programming language as it is an OO one. I don't want to skip talking about that side of things, but OOP seems so prevalent in many areas that I'd like to get my students working with it as soon as possible. I'd appreciate any thoughts you might have on this topic. -Tim -- Tim Wilson | Visit Sibley online: | Check out: Henry Sibley HS | http://www.isd197.org | http://www.zope.com W. St. Paul, MN | | http://slashdot.org wilson(a)visi.com | <dtml-var pithy_quote> | http://linux.com

2 1

小泉内閣支持不支持緊急アンケート
by メールアンケート事務局 27 Jul '01

27 Jul '01

小泉内閣　支持・不支持　緊急アンケートお忙しいところ、ご迷惑をおかけしますが、下のURLをクリックして、アンケートにご協力お願いいたします。 http://211.9.37.210/koizumi/koizumi_an.asp?id=260083

1 0

re: More spillover re the division PEP
by Arthur Siegel 27 Jul '01

27 Jul '01

Kevin writes: >They of course will remember this when an >error occurs, but that could happen be in a >production environment. Kirby writes: >However, I'm adding that I think the limitations >of the current / are more likely to trip up a pro >than a dedicated, serious-minded newbie And as boring as it might be, I essentially agree with the major points of both your posts. (Except that I am probably less sympathetic to the issues of someone who can't keep in mind that using a programming language is different than using a calculator) I recall for some reason in this context when I encountered a previously unreported JPython bug. It was a major victory for me to be able to eliminate all other possibilities and send up a bug report. The point of the story - if there is one - is that a few hours later someone (who had nothing to do with writing the original piece of code) comes back with the fix. Somewhere in the thousands of lines of Java code a ">" had to be a ">=". Issue gone. I looked at the offending code and the fix and didn't have a clue what was going on. But was awed that someone was able find it. And a little scared silly by a closer exposure to the rigor of the discipline. Though I hope this is not interpreted as lobbying for rigor for rigor's sake in a learning environment. I certainly understand that many of the more rigorous aspects of programming are hidden from me in Python's C code, and wouldn't have in at any way. But like all processes, there is a point of diminishing returns, and even a point perhaps where the process feeds back over itself. Whatever that might mean. ART PS - I thought I sent this note up last night. Don't see it posted. If duplicative, I apologize.

1 0

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

26 Jul '01

Kevin writes - >I guess I saw things differently up until now. I always thought Python, by >design, performed the conversion whenever the conversion was needed. This >ensures that when you run an arithmetic operation, you get the result - not >a type error or lost data. I would bet this reasoning accounts for why many >newbies stumble on the division issue. I now realize that is not how Python >works, but why shouldn't it work that way? I don't mean to sound as if I'm >complaining, I would just like to know why it works the way it does. To me this is all about the need for precision in a whole different sense - precision in language. Keep trying to ask - what is a "newbie" and what is the "Programming" in CP4E supposed to mean., "3.1.1 Numbers" of Guido and Fred' tutorial which ships with Python covers the issue of the division operator. My recollection of my true newbie mindset - let me know clearly what the rules are and I will try to play by them. That is my work - my contribution to the learning effort. Certainly Guido and Fed made theirs. The tutorial makes the rules clear. Have I made typos - 3/4 when I meant 3. / 4 - yes. Did I have any significant conceptual problems about what was going on. No. It is actually the hidden bug argument that I find most compelling. But it has nothing to do with newbie status. Absolutely nothing. Should a language be desgined to minimize the possiblity of a hidden unintended result from a missing ".". I guess probably it should, to the extent possible. Obviously this argument is most compelling where we are talking about significant applications. So, by definition, not a newbie issue. Should the language be designed to prevent conceptual errors by folks who haven't made it to Chapter 3 of its introductory tutorial. For reasons that I can't even explain to myself, the argument that it should - if and to the extent that argument has been advanced in these discussions - makes me nuts. A more interesting argument is to what extent we should concern ourselves about those with an interest in learning to program who who read Chapter 3 carefully, and can't follow it - don't have the background to make any sense of it. That's certainly worth talking about. But first we need to have some evidence that such a population exists, which we do not. Or that, if such a population does exist, programming language design is a reasonable arena in which to expect to be able to offer them help[. ART

3 2

PEP 238 - non-integer division
by Brent Burley 26 Jul '01

26 Jul '01

Sorry for jumping in so late. I'd like to argue in opposition to 238. 1) pep 238 introduces significant backwards incompatibility. Existing code may work differently, or may even fail. Consider x/2&1. If x/2 is automatically promoted to a float as in pep 238, you'll get an error: "TypeError: unsupported operand type(s) for &". If you want to write code that will work now and in the future, you'll need to do: int(x/2)&1 which is tedious and error prone. 2) pep 238 breaks consistency with C, C++ and Java. Considering that, like C++ and Java, Python incorporated most of C's operators including all of the integer operators (<<, &, |, ^, etc.), having one operator behave differently will impede transfer of knowledge to/from those languages. This is especially troublesome since python is so often used in a hybrid C or Java environment. 3) pep 238 makes the language inconsistent with itself. None of the other operators return a float for integer arguments. In general terms, there's an automatic promotion from int to long int to float. 4) The rationale given for pep 238 is that 1/2==0 is a "hump in the learning curve" and "manages to trip up new programmers regularly." This may be the case, but it's not clear that pep 238 reduces the learning curve. I think it just moves the hump a little farther down the road and possibly makes it bigger at the same time. Consider trying to teach type promotion. If you now have to include "except for '/'" in every explanation, it will be a much harder concept to grasp and apply. As long as Python treats integers differently than other numbers (e.g. doesn't allow the use of certain operators like '&'), users will need to understand that there is a difference between integers and floats and what the ramifications are. -- Comparisons with Perl have been mentioned. In Perl 1/2==0.5. However, what Perl does is _radically_ different from what is being proposed. Perl operates on "numbers" which in most cases behave like floats. Internally, ints are used where possible for efficiency, but as far as I can tell, there's no way to determine whether an integer or a float (with an integer value) is being stored, and it doesn't matter. Perl just jumps back and forth between integer and float (and even string) automatically, always trying to "do the right thing." Perl _almost_ always does what you want. However, it often feels a little bit too magical, that it's hard to develop an intuition for what's going on under the hood. If Python could be made to work like Perl and work on "numbers" without making users worry about ints vs floats, this would seem to be a much better approach. However, it seems like much too fundamental a change to be making at this stage of the development of the language. Brent

2 3

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

26 Jul '01

Kirby writes - >I agree with Art that this really shouldn't have much to >do with "newbies" (how to define? -- new to Python in >particular, or to programming in general; I suppose the >latter). But there is another category. Take my PyGeo, for example. At the top level, there is a very limited API exposed to Python scripting. The point is to study geometry, using that API, via Python. In the context of a geometry class, no transfer of programming knowledge intended. Write this, expect that to appear. It is my job as the application writer to aniticipate my users ability to work within the API I define. Python is great, but not ideal, in that role. But I think it would be nuts for anything of substance to be sacrificed to make it more perfect in that limited role. My application. My problem. Obviously since I have written (in part) to it, I consider the API scripter to be a legitimate constituency for Python and for Python in education. But it is outside the realm of the P in CP4E - by my definition. Not a novice, not a newbie - I propose a new category for another legitimate constituency - the "scripter". Tremendous confusion has been caused, in my opinion, by not being explicit about defining constituencies. ART

2 1

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

26 Jul '01

Kirby writes - >So I can see the argument for making the return value >explicitly typed thanks to what operator is used (/ or //). >I don't need to think about newbies. I think about pro >programmers studying code they didn't write and trying to >figure it out. So we have a consensus I think. True it is annoying to have to share a language with a bunch of pros. And the change in the division operator status might represent a small sacrifice to the pedagogical value of the language. But all in all, community spirit being what it is - we learners,novices, and educators graciously accept to sacrifice on their behalf. Should we let them know? ART

1 0