On Thu, Aug 06, 2020 at 07:19:01PM -0500, Skip Montanaro wrote: > > > > When Excel reads a file, it looks for stuff and decides to upgrade its > > type. Eg dates etc (particularly pernicious with US-style dates versus > > the rest of the planet). Mojibake for data ensues. > > > > As always, I am reminded of Heuer's Razor: > > > > If it can't be turned off, it's not a feature. - Karl Heuer > > > > Good one. I always remember the start-up days (late 90s) when I developed > and maintained an online concert calendar (Musi-Cal) written in Python. The > technology got bought by another start-up (Mojam) who used Perl for their > web stuff. Both front end systems talked to my Python-based back end > (communication between both front ends and the one back end was via > XML-RPC). I was sometimes frustrated by the stuff Perl did. The one which > stuck with me all these years was its silent conversion of the band name " > 311 <https://en.wikipedia.org/wiki/311_(band)>" to the integer 311 on which > my Python backend obligingly barfed. I eventually had to put in data type > checks for all fields in my back end (my front end already had that sort of > input validation) as I could no longer assume a sentient front end was > handing it data.
311 rocks. That Perl code, OTOH... =8^) Obviously, it's a bug. One that likely is not that hard to correct... FWIW this is what I've long hated about Perl: Yes, TIMTOWTDI, but nearly all of them are subtlely (or sometimes not-so-subtlely) wrong. You *can* write good Perl but it encourages the inexperienced to find one of the wrong ways, by providing the illusion that it is easy to work with. Python is *actually* easy to work with... most of the time. "If you want more things for you buck there's no luck..." =8^) -- https://mail.python.org/mailman/listinfo/python-list
