Мысли о вечном

а не является ли это своего рода извращением писать код для Tk из под Python?

Нет.

Чем это чревато?

Ничем. Хотя для глаз пользователя может быть опасно, если не применишь Tile. Хотя и с ним не всё идеально.

Вариант с tcl этому подвержен не меньше.

не является ли это своего рода извращением писать код для Tk из под Python?

Уже нет.

Чем это чревато?

Ничем.

Что может дать Tcl при написании кода на нем вместо Python?

Необходимость выучить другой язык. Который, кстати, православен.

Что может дать Tcl при написании кода на нем вместо Python?

Необходимость выучить другой язык. Который, кстати, православен.

Тогда уж «знание другого языка», а не «необходимость выучить другой язык».

... другой язык. Который, кстати, православен.

Столлман же считал наоборот вроде?

Если сравнивать с лиспом — то Столлман прав.

Если сравнивать с лиспом — то Столлман прав.

Вот только он зацементировал, спасеный им лисп в emacs, фактически угробив развитие, и на этом успокоился. А из tcl получился вполне отдельный язык.

Если брать именно Столлмана — то да, он не написал лисп для замены тикля, но с этим справились другие.

Что может дать Tcl при написании кода на нем вместо Python?

Полноценный REPL, метапограмирование запиленное под небольшие скрипты. Применяя tclkitt делать небольшоие переносимые сборки для работы без-tcl/tk-шном окружении. Полезняшки типа tktable или gridplus2 который хоть и не принципиальны, но делают Tk шеловистее.

он не написал лисп для замены тикля, но с этим справились другие.

Тут скорее важно не противостояние лисп/тикль лспов и тогда было много и сейчас хватает. А скорее изкоробочность графической подсистемы.

AFAI{R|K}, основными претензиями были работа со строками вместо символов и использование множества видов скобок.

Что может дать Tcl при написании кода на нем вместо Python?

например

Появился большой вопрос - а не является ли это своего рода извращением писать код для Tk из под Python?

Вопрос лучше ставить несколько иначе. А нафига тебе вообще древний и убогий tk при наличии мейнстримовых тулкитов (gtk/qt) и биндингов к ним практически к любым яп?

Что может дать Tcl при написании кода на нем вместо Python?

мозги себе потрахаешь хорошо, если будешь писать много.

Чем это чревато?

тем, что реализацию новых фишек придется ждать по 100500 лет (как было с тем же tile), в то время как на tcl всё нативно (а в CL-ном ltk реализуется одним макросом).

Что-то не очень наглядно =/

Что может дать Tcl при написании кода на нем вместо Python?

А в Tkinter есть поддержка TkTreeCtrl (http://tktreectrl.sourceforge.net/) ?

P.S. Кстати, обрати внимание на http://www.evolane.com/software/etcl/

Что-то не очень наглядно =/

ну уж что есть. в любом случае, не попробуешь - не узнаешь

Кстати, обрати внимание на

и на Jim

а не является ли это своего рода извращением писать код для Tk из под Python?

Да. Питонописательство - и есть извращение.

а не является ли это своего рода извращением писать код для Tk из под Python?

если возможностей Tk вам для задачи хватает, то нет.

Чем это чревато?

чревато тем, что нельзя использовать виджеты не из Tk. Например tktreectrl или mclistbox уже не подцепишь.

Что может дать Tcl при написании кода на нем вместо Python?

портабельность - tcl скрипты таскать по системам проще. Чрезмерная гибкость языка. Отличный набор tcllib.

Можно о Jim подрбонее? Как он в использовании? Насколько удобен?

Вопрос лучше ставить несколько иначе. А нафига тебе вообще древний и убогий tk при наличии мейнстримовых тулкитов (gtk/qt) и биндингов к ним практически к любым яп?

Tk - есть везде, даже на «экзотике».

Можно о Jim подрбонее?

стабильная компактная реализация Tcl, расчитанная на встраивание

Как он в использовании? Насколько удобен?

нареканий не имею. рекомендую попробовать