Comment on PEP-0238

[Mark Jackson]

Guido van Rossum <guido at python.org> writes:
> "Terry Reedy" <tjreedy at home.com> writes:
> 
> > Another *STRONG* argument for replacing int / with another infix operator
> > is the feasibility of revising the thousands of broken lines of code to run
> > under 2.whatever.  Any decent programming editor can do a 'find / and
> > replace with xxx if I say yes' (which will require the reviser to examine
> > the code to determine if / meant int div) but hardly any can do 'find / and
> > examine the code on both sides to determine the strings that the
> > interpreter will see as e1 and e2 and replace e1 / e2 with div(e1,e2) if I
> > say yes'.  Writing a special purpose update program would also be much
> > easier.
> 
> This is a very good argument for a 'div' operator that I hadn't
> thought of before!

Good.  There may be applications in which the functional form has a
slightly more natural feel than the infix operator - but in dealing
with mathematical expressions the preference is strongly the other way.
I speak from bitter experience, having once translated a lot of complex
arithmetic from Fortran (A = B*C + D) to Intel Pascal86 (Call Cmult(B,
C, E); Call Cadd(E, D, A)).

But is "//" rather than "div" actually ruled out?  I find it hard to
believe that the C++ and Java programmers are actually so hardwired that

a = b//c

looks like "a = b" followed by a comment to them.  If so, how do they
cope when (after working in Python for a while) they encounter a stray
octothorpe in some other language?

If "//" is dismissed on this trivial basis it's obvious that, in fairness
to Fortran programmers, starting an unindented line of code with "C"
or "c" must be disallowed in Python as well!  Perhaps I shall write a
PEP. . .

-- 
Mark Jackson - http://www.alumni.caltech.edu/~mjackson
	The chief executives of large American corporations are,
	as a class, the most overpaid people on the planet.
				- James Surowiecki