PEP0238 lament

[Duncan Booth]

Steve Horne <sh at ttsoftware.co.uk> wrote in
news:44ioltcofs8i897flbo7bfqtec5ki06n0s at 4ax.com: 

> I hope he sees my current posts as they are intended - I see PEP0238
> as being something worthy of extreme scepticism if not outright
> terror. But I only care at all because Python *is* a good and
> worthwhile thing, and as a result I have been a very vocal advocate in
> my company.

I must admit to being terrified by PEP0238. Although I agree that in
principle it would be a good thing for division to always be predictable,
I like a programming language to be predictable even more. 

If someone tells me that a future version of Python will (for example)
support proper static scoping, then I endeavour to write all my code so
that it will work both in the current version and in the future version.
And with the scoping issue the compiler can warn me about potential
trouble spots. If someone tells me that a future version of Python will
treat division differently, then what on earth am I supposed to do now
when I want integer division. I cannot write my code so that it works
properly in both old a new versions, all I can do is dread the
maintenance headache that will appear when I finally need to upgrade. It
isn't even an area where the compiler can generate a useful warning. If
the proposal was to introduce '//' to mean proper division and leave '/'
as the 'broken' one I would be fully behind it, but in almost every
situation where I use division I intend the integer truncating version,
and that means a LOT of code breaking. 

I too say "But I only care at all because Python *is* a good and
worthwhile thing, and as a result I have been a very vocal advocate in
my company."

-- 
Duncan Booth                                             duncan at rcp.co.uk
int month(char *p){return(124864/((p[0]+p[1]-p[2]&0x1f)+1)%12)["\5\x8\3"
"\6\7\xb\1\x9\xa\2\0\4"];} // Who said my code was obscure?