Как вы относитесь к GUI-программам, разработанным на Python + GUIToolkit

http://en.wikipedia.org/wiki/INT_10H

Указателей

Сишные указатели необратимо деформируют моск. Ты - наглядный тому пример.

Ну конечно, ты же писал гавнокод. Перед тем как писать на питоне, нужно хотя бы прочитать PEP-8

В случае с жабой необходимо писать в ООП-стиле, в случае с лиспом - в ФП-стиле. Иначе получится нечитаемая каша. Вменяемые ЯП (C, Python, JS) не создают неудобств в использовании любого стиля написания кода без потери читабельности (за исключением Си, наверное, но там своя специфика).

Пузон форсит процедурный стиль и недаёт писать функционально. Сравним с Ruby или JS, ага.

есть история успеха на pygtkmvc в embedded, правда x86.
когда захотели ARM - пользовали Qt без питона. но там был mini2440 arm - далеко не тегра

Указателей, разных типов int и т.п. Чтобы я точно знал, какой тип возвращает функция. И точно знал, что объект передается ссылкой, а не копией (или наоборот).

Да вы упоролись! Это же не перл, там все достаточно ясно, если прочитать необходимое кол-во литературы. И это не си, указатели там не нужны.

Да любые питоноскрипты посмотри. Их же читать невозможно

Ты видимо смотрел скрипты людей, которые тоже положили на пеп

каюсь

Это же не перл, там все достаточно ясно, если прочитать необходимое кол-во литературы.

Если прочитать необходимое кол-во литературы, то даже перл будет достаточно ясен. Всё упирается в размер этого самого кол-ва.

Указателей

Есть жизнь и без указателей.

разных типов int

Не понимаю, зачем это нужно, за исключением взаимодействия с подключаемыми через ctypes.CDLL shared-либами.

Чтобы я точно знал, какой тип возвращает функция.

type()

И точно знал, что объект передается ссылкой, а не копией (или наоборот)

Отсюда:

In general, whenever possible, Python returns references to the same objects it already had around, rather than copying; if you DO want a copy you ask for it — see module copy if you want to do so in a general way.

В общем, по дефолту ссылкой всё передаётся, если явно не указано обратное.

Да любые питоноскрипты посмотри. Их же читать невозможно!

Посмотрел твои. Действительно читать сложновато:

is_array = lambda var: isinstance(var, (list, tuple))

Работает зато.

Да всё оно работает... Вива ля зоопарк!

В питоне етой литературы не так много не так много.
Единственное, что там у меня вызывало проблемы, дак это то, что при работе с объектами там переодически вызываются некоторые методы.
Ну и метаклассы взорвали моск, но это уже настолько сильное колдунство, что оно не нужно почти

указатели там не нужны

Ну и пожалуйста. А я без указателей не могу.

Перед тем как писать на питоне, нужно хотя бы прочитать PEP-8

Я писал из безысходности (т.к. времени внедряться в разработку freecad у меня не было, а нарисовать картинку надо было). А вообще мне этот ваш говнопыхтон не нужен.

Зато твой мозг не тронут ни одним ЯП.

Удивительно, тогда зачем ты пишешь в обсуждении питона? :)
Даже на троллинг не тянет же...

это печально

К счастью.

тогда зачем ты пишешь в обсуждении питона? :)

Надеюсь, что ТС таки выберет что-нибудь приличней.

Видел нормальные проги(zim, например или sonata). Если они не подразумевают высокую нагрузку(нет обработки больших массивов данных и сложных постоянно запускаемых алгоритмов), то можно писать весь проект на питоне. Иначе можно делать на python только пользовательский интерфейс, а всё остальное — C/C++.

Достигаешь противоположного результата. Ибо критика твоя с фиксацией, не конструктивна. :)

4.2

Да нах. нужен такой инструмент. Если надо напилить скрипт - пили на баше, если нужно написать нормальный софт - пили на нативном ЯП. И нех. всякими интерпретируемыми подобиями пользоваться. А то развелось говна, куда на фоурсфорж не плюнь - то питон, то ещё какая нибудь херня скриптовая. Ощущение что у девелоперов мозг атрофировался.

В питоне динамическая типизация, так что с надёжностью всё не ок.

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

Главный аргумент поборников статической типизации против динамической в том, что по мере развития проекта, код на динамически типизированном языке быстро превращается в большую, неподдерживаемую без костылей кучу говна.

Главный аргумент поборников динамической типизации против статической в том, что по мере развития проекта, код на статически типизированном языке быстро превращается в большую, неподдерживаемую без костылей кучу говна.

Главный аргумент сторонников статической типизации состоит в том, что статическая типизация устраняет ошибки типизации.

статическая типизация устраняет ошибки типизации...

...которые возникают из-за наличия статической типизации.

Что за бред.

2+"два" - это ошибка типизации. В языке со статической типизацией в рантайм она не попадёт. С динамической — попадёт

килограммы + метры - это ошибка типизации. В языке со статической типизацией в рантайм она не попадё... wait, OH SHI—

В языке со статической типизацией в рантайм она не попадё

Если соответствующие библиотеки использовать — не попадёт.

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

Кстати, да. Полностью согласен с собратом-анонимусом.

P.S. А Tcl/Tk ещё не советовали?

Для разнообразия посмотрите терминальный проект от киберплата. Сделан на Qt/QML.

Есть поддержка стекеров, манетоприемников, фискальных регистраторов и всего прочего что там полагается.

нормально отношусь, если не тормозит.

чем bash лучше python? конечно, помимо того, что это shell по умолчанию во многих дистрах...

Нормально относимся. Многими даже пользуемся. И вот прям уж таких заметных тормозов в них не наблюдается.

/* для справки: я не питонист, я сишник и сиплюсплюсник...иногда :) */

Как к тормозу

Вообще-то кажется уже давно обсосали эту тему, даже на хабре предлагали классификацию на основе 3 признаков ( ЕМНИП «по периоду» (compile-time,run-time), «по силе», «по явности» ).

Ну а статическая сильная типизация просто позволяет верифицировать построенную программную модель на основании размерностей величин (типов данных) во время компиляции. Для динамической типизации такой верификации пока не наблюдается, лично я так понял что там подразумевается верификация на основании exception-нов и последующего багфиксинга.

верификация на основании exception-нов и последующего багфиксинга.

Как красиво назван метод тыка.

Если надо напилить скрипт - пили на баше

этот совет только для скриптов с < 10 строками подходит, если больше, то скорее всего на каком-нибудь perl/python/ruby/tcl/etc уже будет быстрее разрабатывать, легче поддерживать и работать программа будет быстрее.