>> Судя по этой реплике, Вы вообще не в курсе, как до сих
>> пор делалась миграция в питоне. Что ж, напоминаю.
> К счастью, знаю.  В частности - довожу до вашего сведения, что
> синтаксис, семантику покуда так не меняли.

Что именно считать синтаксисом и семантикой? Например, был ряд запланированных устареваний модулей по этой схеме:
http://docs.python.org/release/2.4/whatsnew/node13.html
The mpz, rotor, and xreadlines modules have been removed.
http://docs.python.org/release/2.5/whatsnew/modules.html
"The old regex and regsub modules, which have been deprecated ever since Python 2.0, have finally been deleted. Other deleted modules: statcache, tzparse, whrandom."

Если Вы считаете, что изменения в библиотеке нельзя включать в это рассмотрение, я заранее не соглашусь.

>> На сейчас есть устойчивый 2.7. Представим себе, что в 2.8 деление уже
>> сделано точь-в-точь как в 3.x, то есть '/' всегда генерирует float,
>> а не остаток. У нас есть сейчас уже 2.7, где есть
>> '//' (на самом деле появилось в 2.6?) Сидя на 2.7, можно
>> исправить код с тем, что там, где деление должно быть нацело,
>> '/' меняется на '//'. Далее переходим на 2.8, и всё работает.
> Это не то как делаются несовместимые изменения в 2.x.   Вам
> в PEP5.

Я и не собираюсь это делать, потому что данное изменение относится к миграции на 3.x, а не сохранения стиля 2.x. Все предложенные алгоритмы перехода - именно для этого случая.

> Так что извольте вынуть из рукава промежуточные шаги.  Пусть старый
> вариант / объявлен deprecated в 2.7.  Я хочу там обещанную "warning"
> от парсера.

Я вам её не обещал, точно так же как в процессе перехода на 3.x все эти обещания PEP 5 были похерены. Так что обвинять *меня* в создании проблемах перехода на 3.x, мягко говоря, некорректно.
Но если Вы действительно хотите это сделать - путь тоже есть:
* вводим новую функцию типа divide()
* вводим во __future__ новый импорт, который генерирует жалобы на все непеределанные '/' в тексте; должно быть или '//' или 'divide()'
* на следующих версиях восстанавливаем рекомендацию использовать '/' и депрекейтим divide().

Это и есть те "строительные леса" на время перехода, о которых я говорил. Да, громоздко. Да, лишняя работа. Зато обеспечивает плавный переход и тестирование с соблюдением остальных требований PEP5 или хотя бы их духа.

> То что описали вы - делает from __future__ import.  Теоретически, наверно
> нет ничего невозможного во введении *всех* новшеств из py3 подобным образом.
> А практически - они, как я понимаю разработчиков python, приведут к
> переусложнению  потрохов CPython.

Только на время перехода и достаточно немного - десяток лишних методов и функций.

>> От того, что "давно толкуют", это не становится правдой, по крайней мере
>> чисто для питонового кода. Переход возможен, с дополнительными "строительными лесами".
>> Весь плач про невозможность это всего лишь нежелание напрягаться.
>> С print_function в 2.x, например, напряглись и не плакались о тяжёлой судьбе.
> Я пока доказательства возможности не увидел и утверждения разработчиков
> о невозможности подобного (собственно, причина появления py3) - звучат весомей.

Сочувствую, если для Вас они звучат весомей, не смотря на открытые факты.