Как стать автором
Обновить
84
0
Алексей @alexey_uzhva

Пользователь

Отправить сообщение
Нет, не поимеете. Сигналы и слоты это не просто вызов функций, а целый механизм, включающий в себя как прямой вызов слотов, так и отложенный.

Вот что написано в этом в документации Qt:
enum Qt::ConnectionType

This enum describes the types of connection that can be used between signals and slots. In particular, it determines whether a particular signal is delivered to a slot immediately or queued for delivery at a later time.

Qt::DirectConnection — When emitted, the signal is immediately delivered to the slot.
Qt::QueuedConnection — When emitted, the signal is queued until the event loop is able to deliver it to the slot.
Qt::AutoConnection — If the signal is emitted from the thread in which the receiving object lives, the slot is invoked directly, as with Qt::DirectConnection; otherwise the signal is queued, as with Qt::QueuedConnection.


Последний вариант используется в Qt по умолчанию. Работоспособность этого дела с нативными питон-нитями была мною уже не раз проверена и активно используется в разработке.
Да, вариант ol-li получше и он нормально копируется больше чем в половине случаев.

На другой сайт идти согласен, не очень хорошо.

Однако если код таки не скопировался, то гораздо приятней сходить на другой сайт, чем вручную расставлять попорченые отступы. Если предложите красивый способ, который всегда и из любого браузера будет копироваться без перехода на другой сайт, порчи переносов и доступными для хабра методами — респект и уважуха :-).
Спасибо за вторую статью цикла.

С ходу отмечу небольшой просчет — когда вы показываете концепцию логирования в QTextEdit (второй листинг в этой статье), то показывайте именно концепцию.

Приведенная довольно страшненькая конструкция для перевода выводимого текста будет бесполезна в 99% случаев.
trstring = QtGui.QApplication.translate("MainWindow", string.strip(), None, QtGui.QApplication.UnicodeUTF8)

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

Второе, что хотел бы я отметить: то, что вы пишете — это хорошо и правильно, но только для малых (и с большой натяжкой — для средних) приложений.

Для средних же и крупных необходимо отделение логики от представления. В идеале, вся работа с Qt должна быть изолирована либо в модуле gui, либо в package с таким или подобным именем.

Ядро же программы желательно должно оставаться девственно чистым от Qt-кода (в том числе Qt-потоков):
— Это облегчит тестирование (для того, чтобы провести юнит-тестирование Qt-потока, надо инициализировать QApplication, а для некоторых других вещей — создавать главное окно).
— Это позволит снизить сложность ядра программы: разработчику ядра не обязательно держать в голове все требования и особенности Qt-реализаций.
— Это позволит легко тестировать программу в консольном режиме.
— И, наконец, это позволит держать код в едином стиле, не перемешивая методы с подчеркрутыми_именами (питон-стиль) с теми, что написалы в camelCase, не перемешивая u'Строки в юникоде' с QString-ами.
Спасибо! Если брать именно подсветку, то качественно и красиво.

Но, скажем в соседнем топике используется сервис Source Code for Me (с очень интересной фавиконкой), который, кроме того, добавляет к коду номера строк и ссылки на копирование исходного поля из textarea.

Номера строк удобны тем, что в статье можно теперь говорить «в 20-й строке вы видите...», а копирование и вовсе незаменимо для питона, ибо при копировании из странички стандартными средствами браузера портятся отступы. В питоне же правильные отступы критичны.

Единственная неприятность — не получается изменить цвет фона на хабре, что делает не все цветовые стили pygments пригодными для использования.


Подсветка кода — это не игрушка, а инструмент, предназначенный для более легкого восприятия. Если каждый начнет самовыражаться и делать статьи то белыми буквами по черному фону, то зелеными по красному, то ничего хорошего, уверяю вас, не получится.
Если вы не собираетесь писать локализуемое приложение, то тем более непонятно зачем делать метод toUtf, то возможно проще писать так, да и работать будет явно быстрее:
MainWindow.setWindowTitle(QString.toUtf8("ХабраОкно 2.0"))


А можно еще проще — MainWindow.setWindowTitle(u"ХабраОкно 2.0")

PyQt отлично умеет мэппить unicode в QString :-)
Неплохая статья, радует что код грамотно подсвечен и не слишком перегружен деталями.

Высказывания в первой части спорны. В частности вы выступаете портив 3-4 лишних генерируемых строк, забывая о том, что сам по себе PyQt содержит десятки тысяч строк на python и C++, не говоря уж о самом Qt. Но в любом случае стремление к чистоте похвально:) Не надо лишь делать столь категоричных выводов о том, что pyuic4 плохо.

По поводу того, зачем класс интерфейса наследуется от object:
Стиль кода Qt и рекомендации по стилю для Python программ очень отличаются. Вы не можете полностью отказаться от питон-стиля (т.к. он используется стандартной библиотеке), а так же не можете отказаться от стиля Qt (иначе вы потеряете связь с интерфейсом).

В серьезных программах единство кода является серьезной проблемой. Разделение кода формы и генерируемого кода для этой формы на разные классы и разные файлы позволяют изолировать визуальный Qt-код от кода программы и свести использование Qt-стиля к минимуму, сохраняя единство и целостность проекта.

Единственный минус, который вижу в статье — отсутствие выводов. Здесь, возможно, уместно добавить области использования PyQt и наоборот те случаи, когда его использование не целесообразно.

Впрочем, коли вы обозначили стиль как беседу, то это простительно, но все равно могло бы значительно улучшить полезность текста.
Хотел уже было возмутиться на «странный» API, но увидел UPD2.

Вот это уже действительно хорошее решение! Спасибо:-)
Начинать надо заранее, когда еще учитесь, когда еще нет своей семьи, когда еще есть такая возможность пожить за счет родителей и за стипендию.

А когда университет закончен, родители ждут от вас помощи, а вы не можете работать — то конечно тут уже не до OpenSource проектов будет.
Для популярных ресурсов мой совет бесполезен — там имеет смысл потратить и более чем 3 часа, потому какая бы ни была защита ее все равно сломают.

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

Но ни первое, ни второе не относятся к небольшим сайтам, о которых я вел речь в своем посте.
Помните, как reCaptcha набирала популярность? Популярность растет и сейчас. Однако спамерами она стала пробиваться на ура.

Заинтересовавшись вопросом, провел некоторый поиск и нашел сервис антикапчи, который предлагает ручной взлом 1000 капч за 1$.

Предлагать-то многие предлагают, скажете вы, а работает ли? Вот и мне стало интересно… Написал небольшую прогу, не пожалел бакса на счет, проверил десятка 4 капч из рекапчи — распознали все правильно.

Какой из этого вывод?

Спам — это бизнес.

Любая защита будет побита, когда станет экономически выгодно ее побить. А значит единственный эффективный способ защитить свой сайт — сделать так, чтобы его было не выгодно ломать.

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

Час работы хорошего программиста стоит 250-500 рублей. Очевидно, что если на взлом вашего блога потребуется 1-3 часа, то он автоматически становится неинтересным для спама.
Не подключается даже…
1. Давайте не доводить до абсурда. Если вам не нравится формат INI — сделайте в XML, YAML или любом другом формате, который вам нравится.

Суть не в конкретном формате, а в том, что есть модуль Settings, в котором есть параметры.

Откуда они там берутся — это проблема модуля settings и никакого другого модуля программы.

2. Про переменные даже отвечать не буду. Я вам привел ссылки на литературу, считаю что этого достаточно.
1. Если меняется название скрипта настроек, то имеет смысл обратиться к модулю ConfigParser и вынести настройки в ini-файл, оставив при этом в покое сам модуль конфигурационного файла.

2. Идеи правильного именования вы найдете в таких трудах, как «Совершенный код» (глава 11), «Domain driven development» и многих других.

Позволю себе привести отрывок из первой упомянутой книги:
Имя переменной нельзя выбирать, как кличку собаке:… В отличие от собаки и ее клички, которые являются разными сущностями, переменная и ее имя формируют по идее одну сущность. Поэтому и адекватность переменной во многом определяется ее именем. Выбирайте имена переменных со всей тщательностью.


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

Например участок с конфигурационным файлом. Вместо
mod = __import__(modName)
host = getattr(mod, 'host', 'horn:intur')
user = getattr(mod, 'user', 'SYSDBA')

можно использовать простое и понятное
import settings
… settings.host…
… settings.user…

Кроме читаемости это будет соответствовать принципам «Simple is better than complex», «Namespaces are one honking great idea» и другим, включенным в The Zen of Python.

Так же, например, код:
def completeFile(self, i):
… widget = self.ui.listWidget
… text = widget.item(i).text()
… widget.item(i).setText('%s\t%s' % (text, u'готово'))
… self.ui.progressBar.setValue(0)


Читая его получаем:
функция «завершить i-й файл»:
… На форме у нас есть некоторый ListWidget, возьмем его
… Допишем к тексту i-го элемента в нем слово «готово»
… Возьмем некоторый прогрессбар на форме и установлим его прогресс в 0.


Отсюда сразу встают вопросы, что за ListWidget, что за элементы в нем хранятся, каково их назначение, и почему функция «завершить файл» вместо того, чтобы завершать этот файл, лишь констатирует факт что файл завершен.

Я не претендую на истинность своих слов, это лишь результат быстрой выкладки, но можно было бы переписать так:
def file_completed(self, file_index):
… file_item = self.ui.file_list.item(file_index)
… file_item.setText( '%s\t%s' % (file_item.text(), u'готово') )
… self.ui.current_file_progress.setValue(0)


Ваш код весьма запутан, а хорошая программа всегда имеет простой (не путать с примитивностью) код, даже если эта программа сама по себе крайне сложна.
Уважаемый, ну зачем сразу же так агрессивно…

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

Лишь хочу сказать, что в данной статье не хватает (помимо подсветки кода) некоторой центральной идеи.

Говорю о том, что читателю вряд ли нужна точно такая программа, как есть у вас. Читатель хочет научиться чему-то, каким-то принципам, каким-то приемам.

Потому полезно ткнуть пальцем «вот тут сделано то-то так-то потому, что...». А учиться лишь по одному исходнику способны гики, которые вряд ли обучаются программированию на хабре.
Обратите внимание на PyInstaller — малоизвестный инструмент, между тем превосходящий по фичам и удобству упомянутый py2exe.

Один из ключевых моментов — автоматически распознает и подключает PyQt/lxml и прочие библиотеки. Т.е. не надо делать абсолютно никаких телодвижений — оно работает «из коробки».

Впрочем, для объективности отмечу и минусы — для поддержки .manifest файлов требует патча (не знаю как с этим у py2exe), и лучше использовать SVN-ветку программы т.к. они почему-то уже год с лишним как не хотят выкладывать на публику версии своей утилиты, несмотря на то, что работает отлично и разработка идет, проект не мертв.
Хотелось бы видеть в начале статьи краткую аннотацию с описанием того, что конкретно делает ваша программа.

Прочитать неподсвеченный код без комментариев — весьма сомнительное удовольствие, особенно не зная что там должно быть.

Какая цель этой статьи? Кому должна быть полезна?

Тот кто не знает PyQt от такого изложения не поймет ничего. А кто знает, скажет вам, что код ваш откровенно средненького качества.

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

Если сейчас там есть какие-то достойные моменты — то их не видно в вашей куче. Если нет — то незачем писать статью.

В данный момент все это похоже на «Я вот сделал за вечер на коленке программку, посмотрите какой я молодец, вот ее исходник».
Вот буквально 4 дня назад сидел, смотрел ПДФ версию романа Пелевина (продающуюся официально) и там сама ПДФ текстовая, но местами весьма странные помарки…

И вот и думал — а что если сделать такие помарки в разных местах и…

Ну в общем, сия публикация точно подтверждает что идея не бредовая:)
За обеими руками и ногами:-)

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

Так что мирно и только мирно… Либо увольняться. На хорошего специалиста всегда место найдется.
Частично соглашусь с вами — при явке с повинной и доказательствах принуждения, директор должен получить срок больший, чем исполнитель.

Но исполнитель тем не менее все равно преступление совершил. Пусть срок он получит и условный, но это будет судимость. Об оправдании здесь речи не может идти — он осознанно все сделал.

Да и работу он после этого точно потеряет.

Может проще просто уволиться по собственному желанию?

Информация

В рейтинге
Не участвует
Откуда
Москва и Московская обл., Россия
Зарегистрирован
Активность