I found the wording of one line of the devguide strange and changed it IMO for the better.  Please review.

New semantics may also be something else than new classes or functions. New optional function arguments exposing new functionality, for example.

What about this: (this obviously does not apply to new classes, functions or arguments)

(this obviously does not apply to new classes, functions or *optional* arguments) ?

Good idea.  So, any -1 on this:

(this obviously does not apply to new classes or functions, or new optional arguments)

The parenthetical comment is a complete sentence, and no longer trivial. I would separate it and write it more simply as
"... their code. (This obviously does not apply to new classes, functions, or optional arguments.)"

Okay for a new sentence.  I think repeating new is clearer:

(This obviously does not apply to new classes or functions, or new optional arguments.)

Updated the existing patch with the new wording

I like it.  Terry, objections?

LGTM.

(Actually you can still break someone's code by introducing new functions/classes, in case they get imported with 'from mod import *' and override some local function/class with the same name -- but this is such an obscure case that doesn't deserve to be mentioned (and 'import *' is bad practice anyway).)

To be more exact, "optional arguments" should be more extended to "optional arguments whose default maintains the existing behavior"

I don't think we need to mention that.  Actually the tone of the whole paragraph could be relaxed a bit, because it first says that "any change **will** break code" (which is not true), except "new semantic, obviously" (which is not true either).

The whole sentence could also be dropped altogether IMHO.
"""
Basically just put yourself in the shoes of someone whose code will be broken by a change to pre-existing semantics.
"""
is already clear enough, and it could be rephrased to
"""
Basically just put yourself in the shoes of someone whose code will be broken by the change(s) introduced by the patch.
"""
to avoid talking about 'semantics'.

This is the wording I committed:

(This obviously does not apply to new classes or functions; new arguments should be optional and have default values which maintain the existing behavior.)

Should I push or should I delete the changeset?

Ezio's comment got me to reread the entire paragraph. I do not like it. 'Having you think' is wrong; 'Basically just' is unneeded; 'guaranteed' is hyperbole; and the paragraph is otherwise repetitive, vague, and pretty useless. For most issues "the core developer who eventually handles your patch will make the final call on whether something is acceptable" is not exactly true and misses the point that we have clearly defined policies that all core developers follow. Here is a suggested replacement that says what is actually acceptable for what versions.

"Second, follow our backwards-compatibility and upgrade policies. New parameters (whose default is the current behavior), functions, and methods may be accepted, but only for a future x.y version. New classes, modules, and syntax (including keywords) get increasingly severe scrutiny and require discussion on the python-dev list. Bug fixes that make behavior better match the documented intention are nearly always accepted for current releases. So are fixes for mistakes and sufficiently bad wording in the documents. Changes away from the current documented behavior are only occasionally accepted and only for future releases. Since they nearly always require at least a few people to update their code, they require special consideration, including a python-dev discussion, and a deprecation process."

That's a bit heavy in my opinion.  I don't think it's necessary to define in detail what "backward-compatibile" means, it's probably enough to say that whatever code might be running before the patch should keep running fine even after.  Bug fixes can change the behavior -- but only if the current behavior is clearly wrong.

In addition you might want to define the meaning of "features", "bug fixes", and "security fixes", mention what releases accept what, say that doc fixes are usually fine in bug fix releases too, and possibly document the deprecation process.  But maybe this is getting out of the initial scope of the issue :)

PEP 387 explains the rules about backward compatibility.  The paragraph could just link to that.

Tried to summarize the previous discussion and generate a compromise here. Patch attached.

New changeset 4ce6bfb27267 by Ezio Melotti in branch 'default':
#12296: clarify paragraph about backward-compatibility.  Patch by Moritz Neeb, Jyrki Pulliainen, and Éric Araujo.
http://hg.python.org/devguide/rev/4ce6bfb27267

Fixed, thanks for the patches!