[Edu-sig] re: More spillover re the division PEP

[Kirby Urner]

>
>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