If we are disagreeing, I'm not sure where.

I thought we were coming to similar places - just from different angles.

I think I was responding to your sentiment that we don't want to pander to people who don't make it to chapter 3, i.e. if someone really learns the rules completely, then a/b, as currently defined, shouldn't be problematic. After all, it's all spelled out in black and white. You don't want Python to be dumbed down as it panders to some illusory "newbie" audience, a.k.a. people without the discipline to do enough learning. In the long run, it's better to have a steep on ramp than a dumbed down language. Whereas I agree with the sentiment, what I'm saying is that a/b is less problematic from a typical newbie standpoint of just trying to get something done in the language on one's own time. Typically, the posture of a newbie is: I want to program something that will do X, i.e. is one of writing from scratch. As such, the newbie is both the author and debugger of her own code, and therefore has deeper knowledge than lexemes like a/b taken in isolation. You can presume more insight and comprehension, because the reader is also the writer. Further along in a typical programming learning curve, you're not just writing your own stuff, but joining in teams, or inheriting code from others. You start eyeballing these vast programs, with thousands of lines of code, none of which you wrote. This is where you start to feel real gratitude for comments, clear documentation, cross-references. And this is where a/b starts to be problematic, because you don't know if it's losing information, returning 0 for 1/2 3/5 6/7 8/9... because you don't necessarily have all the clues you need to decide the types of a and b. Whereas if the proposed change is implemented, then I know for sure that a/b is a float-style division, and a//b isn't. It matters more with division, because a-b, a+b and a*b, if a,b are integers, usually don't give essentially different results than if a,b were floats. But with /, the current behavior is radically different either way. So it's not a matter of not understanding what / does for reason of not having read and/or understood the docs, it's a matter of knowing full well how / behaves, and finding this a stumbling block, especially because, unlike C or Java (especially Java), you don't have to declare the types of your arguments. In Java, you would go something like: int myfunc(int x, int y){ return x/y } Fine. myfunc expects two integers and returns an integer. No problem telling how / will behave. But in Python: def myfunc(x,y): return x/y How am I supposed to know that this does? It's not a matter of not having studied the docs, it's just that there's a lot more ambiguity built in to the language (by design). To compensate for that abiguity (an advantage, a selling point), we maybe need to be more explicity about what / is doing right where it's being used. This is what the PEP is aimed at fixing. Where I think we're agreeing is on the point that this has little to do with newbies vs. pros. 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, simply because pros are often immersed in the mundane drudgery of scanning large programs written by others, whereas the paradigm newbie is often more blissfully self-involved in pet projects, teaching herself the language, but not forced to rub her nose in a lot of code by others (except maybe the short examples offered in the tutorials and "How to" books). Kirby