Python, to its credit, has been making changes of that level.

First, True and False were just the integers 1 and 0. Then they were given special values that numerically evaluated to 1 and 0, but __str__ now emitted 'True' or 'False'. They were still global variables, though, so they could be reassigned ('True, False = False, True') and cost a dictionary lookup to use. Finally, with Python 3, they (along with None) were made keywords so that such shenanigans could be stopped.

It does sound like they might have gone a bit far, but as someone who works in an industrial context, a tool that maintains backwards compatibility rigorously is of enormous benefit.

The case you might have to make to upgrade the version of the tool you are using has to take into account the risks, and something that is maintaining a high level of backwards compatibility has a much lower level of risk.

Here are my preferences for tools, in order from most-preferred to least preferred: first, tools that have a rigorous deprecation process for breaking changes, distant second, tools that are incredibly conservative about breaking changes, pretty close third, tools that refuse to make breaking changes at all ever, astronomically distant last, tools that make breaking changes willy-nilly.

I generally eventually have to re-write to use a totally different tool for either of the middle two cases, because they just can't keep up. I would much rather make changes to my use of them based on deprecations than be forced to ditch them entirely.

(This is more a general statement - obviously refusing to make this datetime change isn't realistically going to push anybody away from Python.)

Type-safe format strings should never be mixed with plain strings, constant strings, byte strings, unicode strings, batteries strings, byte array strings, char array strings, string buffers or any other type of string supported by ocaml. Keep your types pure and never mix them with any other types. Never. And you will never have any problem. And these python developers are lunatics. It is preposterous to use 'if' condition on a Date object and expect anything good. Idiots. They should have at least written a type-safe wrapper.

Indeed, the first thing that came into my mind when reading this was "You wouldn't have this problem if the only valid type in a conditional was boolean."

It's against the grain to think this way in dynamic languages because variables don't have types, only individual values do. Ill-thought truthiness rules are the real problem. IMO every value except boolean false (and, if you insist, nil/null) should be truthy in a dynamic language.

> It's against the grain to think this way in dynamic languages because variables don't have types, only individual values do.

So? "The only valid type for a conditional is boolean" still works if types only apply to values. Under that principle, anything but True or False value encountered in evaluating the condition of an if statement ought to throw a TypeError, not be evaluated for truthiness. If you are expecting something else, call an explicit, use-case-appropriate function to get the right in-context truth value.

(Note, I'm not saying Python should do this, I'm explaining how the logic applies to Python without any contradiction to the "variables don't have types, values do" principle.)

> IMO every value except boolean false (and, if you insist, nil/null) should be truthy in a dynamic language.

I think that's better than what Python does (Ruby does that by default, with nil included as false, though it is IIRC possible-but-extremely-strongly-discouraged to override the default truthiness of objects so you could have classes with falsey values), and I lean toward preferring that approach, but the idea that a dynamic language would do well to just allow True and False as the only valid (non-error-producing) values for an "if" statement is not, IMO, without some merit.

We're on the same page - I just didn't phrase that well. I mentioned it because most of the time what's written is a test of a variable, not a literal value, and that couldn't get a thumbs-up as robust without someone putting a static analyzer hat on.

Having a simple universal truthiness rule seems preferable and more in the spirit of a dynamic language.

> variables don't have types, only individual values do.

It really depends on what language you're using. This is more or less true in Python, Ruby, and Javascript. In Lisp generic methods you can specify the type for the input variables and be guaranteed that if you are inside the method the parameters are of that specific type. For optimization reasons you can also declare to the compiler that variables are a specific type. This is really important when doing numeric computations in a tight loop. I've had 50% - 80% performance improvement by declaring types (amounting to hours of run time). I think Groovy and Clojure also allow this but I don't know much about those two.

There's also the maintenance issue though. After a few years of maintaining a fairly large Lisp project I've become pretty convinced that the only way to stay sane, at least for me, is to treat it as a statically typed language. I have asserts and check-type macros all over the place. If variables may have multiple types they can be checked against '(or type1 type2) but things do become more complicated then.

Interesting. Admittedly I have only used (UnCommon) Lisps in a hobbyist way and haven't been concerned with techniques for extra speed/robustness there.

That latter's debatable but probably not the former unfortunately.

I can't tell if this is sarcasm.

Similar issues plague Haskell. A bunch of functions have illogical names, just because that's how they've always been used. And, there's the annoying matter of Applicative not being a superclass of Monad in the language, when it mathematically should be. This should be fixed in Haskell 2014, though.