re: More spillover re the division PEP
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
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). Forcing type coercian looks a bit easier when you write 3./4 vs p/q, as the former show their types by inspection. It's p/q that's more problematic because we don't know what it will do until we either (a) type check or (b) coerce, on the assumption that p and q are at least int, float or long. Suppose p = long('2847509247509234750924752309') and q = 5. Then p/q returns 569501849501846950184950461L whereas float(p)/q returns 5.6950184950184698e+026. We know that the former is how many times 5 divides evenly into p; there might still be a remainder (and there is: 4). Using // in the code tells other programmers that division of the former kind is expected (tossing out the remainder, keeping results integer). / says the result will be float. You don't need to look elsewhere in the code to try to figure out if p and q are both ints. Given this is code you didn't write, you maybe don't get to force a type coercian either (who said you could change what's written? -- maybe this is a commercial app and you job is to understand but NOT tweak). So you're left trying to discover the secret identities of p and q, if you want to know how this operator will behave. In a weakly typed language, that's not easy. Maybe the coder has some p *= 1. nearby, but who's to enforce such an idiom? Now of course we have overdetermination in + as well, i.e. a + b might concatenate, vs. add numbers. But it's somewhat easier to track when a variable is being treated as an str vs. some kind of number, than it is to be sleuthing the diff between float, int and long usages. 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. Kirby
float() 2.847509247509235e+027 float(long('2847509247509234750924752309'))/5
long('2847509247509234750924752309')/5
divmod(long('2847509247509234750924752309'),5) (569501849501846950184950461L, 4L)
Hi Arthur, <<SNIP>>
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.
That's understandable - I've seen many people call themselves database designers simply because they can use Microsoft Access, although it is obvious from their work that they don't understand the conceptual issues involved. In fact, they break many of the essential rules the 'trained' DB designer is taught to uphold. To listen to someone advocate creating these kinds of workers would frustrate me as well. But in this case the errors do not occur because students do not understand the concept. They may understand the concept perfectly, but because they are so familiar with arithmetic and "calculator" division, and because they have been using these forms of division far longer and more often than integer division, they forget that Python does things differently and as a result create a "gotcha" in their code. They of course will remember this when an error occurs, but that could happen be in a production environment.
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[.
I think we could safely say the current target audiences for Python should be old enough that they have a solid grounding in whatever pre-requisite knowledge they need to learn Python and programming in general. However, as you say it would be interesting to know what those pre-requisites are! After all, how long until 7-8 year olds start trying their hands at programming? (If they aren't already.) Kevin
participants (3)
-
Arthur_Siegel＠rsmi.com -
Kevin Ollivier -
Kirby Urner