#  Re: sqlite3
vit01 (mira, 1) → Andrew Lobanov  –  07:21:24 2016-06-13

AL> У тебя есть какие-нибудь наработки по формату базы? Может, есть смысл посмотреть в сторону твоей реализации ноды?

Вот так создаётся база в ii-php:


CREATE TABLE IF NOT EXISTS `$db->tablename` (
`number` bigint NOT NULL auto_increment,
`id` varchar(20) NOT NULL,
`tags` text,
`echoarea` text NOT NULL,
`date` varchar(30) NOT NULL default '0',
`msgfrom` text,
`addr` text,
`msgto` text,
`subj` text not NULL,


>> Читать далее
#  filler у операции %
Andrew Lobanov (tavern,1) → All  –  07:10:27 2016-04-26

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


"%-20s%s" % (1, 2)


Но при этом между символами 1 и 2 будут пробелы. Как заполнить пространство между ними произвольным символом без написания своей функции форматирования и возможно ли это в принципе?
#  Re: sqlite3
Andrew Lobanov (tavern,1) → vit01  –  06:58:29 2016-06-13

vit01> Ты делаешь просто SELECT COUNT(*) from ... ? Можно попробовать создать индекс в БД и проделывать хаки с ним.

Печальней даже стало. Подсчёт длины выборки стал быстрее раза в два (всё равно около 2-3 секунд), но существенно просела скорость добавления записей.

vit01> Может быть, здесь что-то полезное тебе есть: http://www.sqlite.org/cvstrac/wiki?p=PerformanceTuning

Спасибо. Почитаю как посвободней станет.


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

2vit01: У тебя есть какие-нибудь наработки по формату базы? Может, есть смысл посмотреть в сторону твоей реализации ноды?
#  sqlite3
Andrew Lobanov (tavern,1) → All  –  12:19:28 2016-06-12

Что-то в сабже очень грустно работает подсчёт строк в таблице. Каких-то 42+к записей на нетбуке считает около пяти секунд. Есть спобос быстрого подсчёта строк в связке python3 и sqlite3?
#  Re: Код, возвращаемый приложением
vit01 (mira, 1) → Andrew Lobanov  –  12:15:49 2016-03-21


p=subprocess.Popen(блаблабла)
p.wait()
print(p.returncode)


Но вот зачем...
#  эха про python
Roman Yakovlev (station13, 11) → All  –  17:46:23 2015-09-10

всем привет!
#  Qt и QProgressDialog
vit01 (mira, 1) → All  –  11:53:43 2015-09-18

Решил добавить в свой питоновский клиент диалог с прогрессбаром, чтобы он показывался во время загрузки больших эх.
Так вот, после этого эхи стали открываться раз в 5 дольше, чем без него.

=)
#  Ликвидируем дубли в эхах по сабжу и тексту сообщения
vit01 (mira, 1) → All  –  15:00:54 2015-12-05


#!/usr/bin/python2
# -*- coding:utf8 -*-
from ii_functions import *
import os

echolist=os.listdir(indexdir)

for echo in echolist:
print("doing "+echo)
msgids=getMsgList(echo)
arr=[]
doubles=0

for msgid in msgids:


>> Читать далее
#  Re: rsa и все все все
Difrex (mira, 14) → Roman Yakovlev  –  12:33:31 2015-09-14

Дергай gpg. У GPG стандартизированный API и он есть везде.
#  Re: Qt и QProgressDialog
vit01 (mira, 1) → vit01  –  10:19:13 2016-01-08

vit01> после этого эхи стали открываться раз в 5 дольше, чем без него.

Понял, в чём была проблема.
Когда решил вынести это дело в отдельный поток и попробовать снова, результат оказался точно таким же. Как оказалось, тормоза вызывало не обновление прогрессбара, а прорисовка QListWidget. Да, да, который был во время этого процесса бесполезен. Так что я теперь просто скрываю MainWindow во время подгрузки данных, а после этого опять делаю видимым, и всё работает нормально.
#  Re: rsa и все все все
vit01 (mira, 1) → Roman Yakovlev  –  03:24:49 2015-09-11

Попробуй PyCrypto. Я, правда, не использовал RSA через него, но с AES он отлично справляется.
#  Re: rsa и все все все
Andrew Lobanov (station13, 1) → Roman Yakovlev  –  17:50:48 2015-09-10

>подскажите какой-нибудь алгоритм шифрование и лёёёгонькую библиотечку python для него, чтобы был небольшой паблик-кей, какой-нибудь привейт-кей и можно было слать шифровки на паблик-кей
>ща я пробую с python-rsa, в debian она есть, а вот в openbsd её нет :) но может есть способы проще
Немного неэхотаг, на у меня мелькали мысли прикрутить просто PGP для этих целей. Да-да. Прямо к ii-софту =)
#  регекспы
Roman Yakovlev (lenina,1) → All  –  00:38:22 2015-11-16

Вот {8} - это 8 символов
{8,20} - это от 8 до 20
а как сделать "или 8, или 20"?
#  Re: эха про python
Roman Yakovlev (station13, 11) → Andrew Lobanov  –  17:53:35 2015-09-10

>Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.

>Питон всё таки язык транслируемый и достаточно неторопливый.

это идеология. :) всё, что укладывается в pep8 и pep20 - питоноугодно. всё, что нет - нет

ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать
#  Re: эха про python
Andrew Lobanov (station13, 1) → Roman Yakovlev  –  17:57:11 2015-09-10

>ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать
Ну фиг знает. Это кушает python3. И это я очень долго и упорно всё гуглил и обкатывал. И они таки есть. Потому как байт-массив из юникода не получается и потому приходится промежуточно транслировать всё в ascii. Уж не знаю тонкостей, но работает.
#  Пишем плагин для Sensu
Difrex (mira, 14) → All  –  09:47:54 2015-10-13

Думал, куда бы перетащить эту статью -- в linux.14 или в python.15. Решил остановиться на питоне.

Итак:

Будем писать на питоне.

Нам потребуется пакет sensu-plugin-python. Ставим его. У меня он опакечен, вам же предстоит это делать самому. Взять его можно на гитхабе: https://github.com/sensu/sensu-plugin-python.git.

*Пишем проверку*


#!/usr/bin/python
# -*- coding: utf-8 -*-

from sensu_plugin import SensuPluginCheck


>> Читать далее
#  rsa и все все все
Roman Yakovlev (station13, 11) → All  –  17:48:40 2015-09-10

всем привет в новой эхе

подскажите какой-нибудь алгоритм шифрование и лёёёгонькую библиотечку python для него, чтобы был небольшой паблик-кей, какой-нибудь привейт-кей и можно было слать шифровки на паблик-кей

ща я пробую с python-rsa, в debian она есть, а вот в openbsd её нет :) но может есть способы проще
#  Re: регекспы
vit01 (mira, 1) → Roman Yakovlev  –  12:49:34 2015-11-16

RY> а как сделать "или 8, или 20"?
Вроде бы, надо отдельные группы городить, но точно не уверен.

([A-Z]{8})|([A-Z]{20})
#  Вопрос знатокам эхотага
Andrew Lobanov (station13, 1) → All  –  05:10:13 2016-01-21

Сабж: если я разбиваю программу на несколько логически раздельных файлов, но хочу использовать одни и те же библиотеки в них, я должен импортировать их повторно в каждом файле. Насколько это экономично? Они подгружаются каждый раз отдельно?
#  Re: эха про python
Roman Yakovlev (station13, 11) → Andrew Lobanov  –  18:01:52 2015-09-10

>>ps. ты, кстати, пишешь, на python2 а не python3 :) в python3 нет всех этих .decode, поэтому я даже не понимаю, почему оно работает (но в python3 я не вникал и не интересуюсь особо). по идее, это можно портировать на python2, надо будет попробовать
>Ну фиг знает. Это кушает python3. И это я очень долго и упорно всё гуглил и обкатывал. И они таки есть. Потому как байт-массив из юникода не получается и потому приходится промежуточно транслировать всё в ascii. Уж не знаю тонкостей, но работает.

именно поэтому я выбираю python2. там всё просто - str это байт-строка, unicode это unicode-строка. в python3 столько заморочек по этому поводу, что проще повеситься. поэтому, когда стоят такие задачи, python2 - то, что доктор прописал. а сейчас это в python2 не запускается :(
#  Re: эха про python
Andrew Lobanov (station13, 1) → Roman Yakovlev  –  17:49:14 2015-09-10

>всем привет!
Привет.

Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.

Питон всё таки язык транслируемый и достаточно неторопливый.
#  Расстановка сообщений в эхе в правильном порядке
vit01 (mira, 1) → All  –  10:13:07 2015-12-04

$ mkdir echo_new # и дальше


#!/usr/bin/python2
# -*- coding:utf8 -*-
from ii_functions import *
import os

echolist=os.listdir(indexdir)

for echo in echolist:
print("doing "+echo)
msgids=getMsgList(echo)
msgs={}


>> Читать далее
#  Re: эха про python
Roman Yakovlev (station13, 11) → Andrew Lobanov  –  17:53:34 2015-09-10

>>всем привет!
>Привет.

>Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.

>Питон всё таки язык транслируемый и достаточно неторопливый.
#  Re: эха про python
Roman Yakovlev (station13, 11) → Andrew Lobanov  –  05:49:56 2015-09-11

>Я привык считать приведение типов, работу с нетипизированными массивами (читай списками) медленными операциями. Определение длинны строки -- медленная операция. Но вот, например, классическая задачка по программированию: определить разряд числа. Классическим питон-решением является:

какое очевидное - такое и правильное :) дзен python :)

со списками... поэтому у тебя в python аж три списка - list, tuple и set :) посмотри, с какой скоростью сравниваются два set-а по 200000 значений в них ;)


не, я теорией не интересуюсь, мне важнее практика. какой вариант читабельнее - тот и лучше, pep8 и pep20 не зря являются основой основ :)

>Вот и вопрос отсюда: как оптимальнее с точки зрения питона? Конечно, я бы мог написать несколько тестов для проверки этого факта, но всегда было интересно мнение непосредственно питонщиков по этому вопросу.

мнение тех, кто постиг дао, дзен, pep8 и pep20, думаю, будет однозначным - какое читабельнее, то и лучше. для скорости - расширения C и разные numpy, а в обычных вещах никто на спичках экономить не будет (разумеется, если это не сверхнеоптимальное решение)
#  Re: эха про python
Andrew Lobanov (station13, 1) → Roman Yakovlev  –  04:26:56 2015-09-11

>>Сразу же вопрос: насколько оптимизированы всякие штуки, как то приведение типов или методы .split/.join? Просто порой мне начинает казаться, что я увязаю в болоте синтаксического сахара, но при этом не уверен, что внутри этого всего нет оптимизированных низкоуровневых реализаций, а значит моя высокоуровневая реализация таких штук "по-старинке" будет медленнее.
>это идеология. :) всё, что укладывается в pep8 и pep20 - питоноугодно. всё, что нет - нет
Поутру перечитал и решил добавить. Вопрос сугубо технический =) Если его перефразировать, то звучит примерно так:

Я привык считать приведение типов, работу с нетипизированными массивами (читай списками) медленными операциями. Определение длинны строки -- медленная операция. Но вот, например, классическая задачка по программированию: определить разряд числа. Классическим питон-решением является:


number_length(num):
return len(str(num))


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

С точки зрения "классического" программирования это решение неэлегантно и неторопливо. Гораздо быстрее будет работать такой вариант:


>> Читать далее
Powered by iii-php v0.11