Таки да, исполняющая часть «живёт» в статически скомпиленном модуле _sre, а все 50кб кода из sre_*.py в основном всяческие обёртки…
Эхх… Значит не видать мне 100500 раз ускорения от подключения внешней библиотеки :(
Остаётся вопрос про оптимизацию самих регэкспов, типа «Как писать быстрые регулярные выражения». Нет на примете подобной статьи? Почитал бы не без удовольствия ;)
Вот кто бы ещё написал про оптимизацию питоньих регэкспов — вообще бы было здорово.
От себя замечу:
— встроенные в питон регэкспы написаны на самом питоне и не слишком быстрЫ
— в отличие от «обычного» кода их нельзя ускорить при помощи psyco
— по моим тестам обработка не слишком больших (до 2мб, книжки с самиздата) текстов «руками» давала ускорение от 1.5 до 6 раз.
Я glob-ом как-то редко пользуюсь, разве что в конфиге py2exe, да и то потому, что где-то в примерах попался когда-то… А это было «тупо-наколенное творчество» чтобы быстренько исправить пару файлов… Что вспомнилось, то и воткнул… Там даже проверок никаких нет на повторное преобразование и ошибки
но glob-ом таки поинтересуюсь поплотней при случае ;)
Оно для каждой буквы из `uslt.text` «обманывает» перекодировщик.
`uslt.text` содержит юникодный текст, но русские буквы там не с кодами 0x04**, как положено, а 0x8*.
Символ, например, u'\u00FF' превращается в '\xFF', что соответствует букве «я» в кодировке 1251. Дальше склейка не-юникодной строки и преобразование уже в нормальный юникод :)
Рекомендую посмотреть ещё mp3diags (тоже есть в репах). В сочетании с EasyTag весьма полезен.
Например, у меня оказалось масса «кривых» тэгов, где уже прописана ID3v2 кодировка latin1, а фактически — 1251. В такой ситуации EasyTag не справляется, показывая английские «кракозябры» с умляутами, а в mp3diags есть опция проверки и перекодирования символов с кодом больше 128 в указанную кодировку.
Но даже он не справился с битыми текстами песен и пришлось написать наколенный скриптик, использующий тот же mutagen, который исправляет оплошность. Скрипт перебирает все .mp3 файлы в текущей папке и, находя тэг с русскими текстами принудительно переделывает его в utf-8:
#!/usr/bin/env python
import os, sys
reload(sys)
sys.setdefaultencoding('utf-8')
from mutagen.mp3 import MP3
for fn in os.listdir('.'):
if fn.lower().endswith('.mp3'):
print fn
f = MP3(fn)
try:
uslt = f["USLT::'rus'"]
except:
continue
s = unicode(''.join([chr(ord( c)) for c in uslt.text]),'cp1251')
print s
uslt.text = s.encode('utf-8')
uslt.encoding = 3
f.save()
PS: парсер — лох! :) умудрился в коде превратить «с» в скобках в знак копирайта :)
5.2.1. Уточнение
Использование именованных аргументов и произвольного числа обычных аргументов одновременно, по-видимому, невозможно, потому что именованные аргументы должны быть определены до "*"-параметра. Например, представим функцию:
Ну я же честно предупредил про быдлокодство :)
А если серьёзно, то, не обращая внимание на потенциальную экономию памяти, — это последствия отлова глюков. Было подозрение, что Formatter что-то там запоминает и потом криво парсит текст. На деле это оказались чудеса с экранировкой HTML и пробелами.
ЗЫ: и про «лишний» del в присутствии None я знаю. :)
Рискну нарваться на кучу минусов, но мечты о тихой водянке в подобной ситуации — это только мечты :(
После почти 3х лет пользования Thermaltake Armor LCS (вернее его встроенным радиатором) + Laing DDC + Waterworker на CPU порой задумываюсь — а не вернуть ли старый Big Typhon обратно. Тем более, что радиаторов на чиспсет для моей Asus P5B уже не достать. Только лень и останавливает :).
IMHO выигрыш от воды в плане шума будет только если вынести помпу и радиатор куда-нибудь на балкон или в соседнюю комнату.
Во-первых, даже «культовая» DDC-1T шумит, причём этот шум, в отличие от кулера, низкочастотный и слышно его «гораздо лучше». По крайней мере, гул на нервы действует сильнее чем шелест вентилятора.
Во-вторых, всё равно нужны обдувающие вентиляторы — если не остужать встроенный радиатор, то как минимум чипсет и винчестеры, а они опять шумят. Хотя по-мне, помпа при сопоставимой громкости, их перешибает :(
В-третьих, это возня с водой, риск спалить всё от протечки и, по-хорошему, регулярная чистка радиаторов. Но тут уж — на любителя ;) Мне понравился сам процесс (с) :)
Пользуюсь такими же где-то 1.5 года с Nokia 5800.
По сравнению со 101-ми — небо и земля.
Выбирал довольно долго и тоже сначала думал про 101-е, но «удачно» коллега пожадничал и взял именно 101е. Результат — поролоновые амбушюры, шипение как из старого радио и малое время работы (чуть ли не пара дней по 2-3 часа). Никакие попытки настроить профиль результатов не дали. В итоге тоже сменил на 50-е и остался доволен.
В итоге взял 50-е в плеер-ру за что-то около 5000 и до сих пор не жалею. Заряжаю раз в две недели при пользовании 4 часа в день, 5 дней в неделю. В таком режиме реально хватает на 2.5 недели, потом просто выключаются в самый интересный момент :) Хорошо ещё автоматически останавливают плеер перед отключением.
По поводу охвата ушей — порой создаётся ощущение, что ухо свернули в трубочку внутри телефона :)
Да, и зимой на улице вместо ушанки можно пользоваться :)
А там всё потребление на мотор, вертящий рамку, уходит. Шутка-ли — железную «подкову» в 2.5м высотой и порядка 40-50см шириной прокрутить на оборот и обратно на примерно секунду времени…
Где-то видел цифру в несколько милливатт, возможно в бумажном буклете. Если _очень_ интересно — попробую его найти, но не обещаю :)
На данный момент пользую Sony BT-50 с телефоном. По качеству звука — весьма достойно, на уровне 212 Sennheiser-ов.
НО!
"+":
1. Весьма неплохой звук, особенно для синезубых
2. Хорошая шумоизоляция
3. Заряда аккумуляторов хватает на 2 недели поездок на работу — по 3-3.5 часа в день
"-":
1. Цена :(
2. Микрофон ловит не просто всё, а будто ещё и усиливает шумы — как гарнитура только в тихих помещениях или нет другого выбора
3. Та самая чувствительность — лотерея — то по всей квартире работает, то из заднего кармана штанов не пробивается. Особенно заметно в час-пик в метро — стоя в плотной толпе есть шанс потерять сигнал, у и головой вертеть приходится. Есть ощущение, что вероятность «провала» звука зависит от битрейта, но специально не проверял
Если очень хочется — есть сочетание Ctrl-Shift-U плюс 16-ричные Unicode, упоминание есть в ссылке ниже. Для Ubuntu 9.xx можно настроить птичку «включить дополнительные типографские символы» — третьим уровнем будут типографские символы.
НО! При использовании мультимедийных клавиатур и/или ноутбуков (фактически — ACPI клавиш/событий) вылезает глюк с появлением дополнительной «лишней» раскладки. Гугл говорит, что это бага Xorg-а и советов по лечению не даёт. Пересобирать Xorg ради этого, естественно, нет ни малейшего желания.
Я для себя сделал кнопку с запуском
setxkbmap
на таскбаре. Попытки повесить обработчик на multimedia клавиши или загнать это дело в cron не помогли (возможно надо что-то мудрить с параметрами bash/gnome-terminal).
finally мне видится полезным при работе с ресурсами, которые обязательно надо освободить. В случае же exception-а ресурс может оказаться занятым. Например, открытый файл, сокет, всякие семафоры с флагами и т.п.
Мне сейчас скажут, что есть же with, но он далеко не всегда доступен :( Говорят, в python 3000 with должен поддерживаться большей частью библиотек, для версий же 2.5-2.6 это не так. Сам, недавно испольpуя urllib, с огорчением для себя обнаружил, что с ним with не работает.
Таки да, исполняющая часть «живёт» в статически скомпиленном модуле _sre, а все 50кб кода из sre_*.py в основном всяческие обёртки…
Эхх… Значит не видать мне 100500 раз ускорения от подключения внешней библиотеки :(
Остаётся вопрос про оптимизацию самих регэкспов, типа «Как писать быстрые регулярные выражения». Нет на примете подобной статьи? Почитал бы не без удовольствия ;)
Вот кто бы ещё написал про оптимизацию питоньих регэкспов — вообще бы было здорово.
От себя замечу:
— встроенные в питон регэкспы написаны на самом питоне и не слишком быстрЫ
— в отличие от «обычного» кода их нельзя ускорить при помощи psyco
— по моим тестам обработка не слишком больших (до 2мб, книжки с самиздата) текстов «руками» давала ускорение от 1.5 до 6 раз.
но glob-ом таки поинтересуюсь поплотней при случае ;)
`uslt.text` содержит юникодный текст, но русские буквы там не с кодами 0x04**, как положено, а 0x8*.
Символ, например, u'\u00FF' превращается в '\xFF', что соответствует букве «я» в кодировке 1251. Дальше склейка не-юникодной строки и преобразование уже в нормальный юникод :)
Например, у меня оказалось масса «кривых» тэгов, где уже прописана ID3v2 кодировка latin1, а фактически — 1251. В такой ситуации EasyTag не справляется, показывая английские «кракозябры» с умляутами, а в mp3diags есть опция проверки и перекодирования символов с кодом больше 128 в указанную кодировку.
Но даже он не справился с битыми текстами песен и пришлось написать наколенный скриптик, использующий тот же mutagen, который исправляет оплошность. Скрипт перебирает все .mp3 файлы в текущей папке и, находя тэг с русскими текстами принудительно переделывает его в utf-8:
PS: парсер — лох! :) умудрился в коде превратить «с» в скобках в знак копирайта :)
сравнительно активно пользую версию 1.0 на андроиде и в убунте… Всё руки не доходят под винду поставить :)
А как же стандартное
Полагаю, правильно было бы написать что-то вроде «использование неименованных аргументов _после_ именованных»
Кроме того
мнеудобнее хранить и править off-line пост без мусора из раскраски и одним файломА если серьёзно, то, не обращая внимание на потенциальную экономию памяти, — это последствия отлова глюков. Было подозрение, что Formatter что-то там запоминает и потом криво парсит текст. На деле это оказались чудеса с экранировкой HTML и пробелами.
ЗЫ: и про «лишний» del в присутствии None я знаю. :)
После почти 3х лет пользования Thermaltake Armor LCS (вернее его встроенным радиатором) + Laing DDC + Waterworker на CPU порой задумываюсь — а не вернуть ли старый Big Typhon обратно. Тем более, что радиаторов на чиспсет для моей Asus P5B уже не достать. Только лень и останавливает :).
IMHO выигрыш от воды в плане шума будет только если вынести помпу и радиатор куда-нибудь на балкон или в соседнюю комнату.
Во-первых, даже «культовая» DDC-1T шумит, причём этот шум, в отличие от кулера, низкочастотный и слышно его «гораздо лучше». По крайней мере, гул на нервы действует сильнее чем шелест вентилятора.
Во-вторых, всё равно нужны обдувающие вентиляторы — если не остужать встроенный радиатор, то как минимум чипсет и винчестеры, а они опять шумят. Хотя по-мне, помпа при сопоставимой громкости, их перешибает :(
В-третьих, это возня с водой, риск спалить всё от протечки и, по-хорошему, регулярная чистка радиаторов. Но тут уж — на любителя ;) Мне понравился сам процесс (с) :)
По сравнению со 101-ми — небо и земля.
Выбирал довольно долго и тоже сначала думал про 101-е, но «удачно» коллега пожадничал и взял именно 101е. Результат — поролоновые амбушюры, шипение как из старого радио и малое время работы (чуть ли не пара дней по 2-3 часа). Никакие попытки настроить профиль результатов не дали. В итоге тоже сменил на 50-е и остался доволен.
В итоге взял 50-е в плеер-ру за что-то около 5000 и до сих пор не жалею. Заряжаю раз в две недели при пользовании 4 часа в день, 5 дней в неделю. В таком режиме реально хватает на 2.5 недели, потом просто выключаются в самый интересный момент :) Хорошо ещё автоматически останавливают плеер перед отключением.
По поводу охвата ушей — порой создаётся ощущение, что ухо свернули в трубочку внутри телефона :)
Да, и зимой на улице вместо ушанки можно пользоваться :)
Где-то видел цифру в несколько милливатт, возможно в бумажном буклете. Если _очень_ интересно — попробую его найти, но не обещаю :)
Вот, например: www.antiterror.com.ru/?item=2181
НО!
"+":
1. Весьма неплохой звук, особенно для синезубых
2. Хорошая шумоизоляция
3. Заряда аккумуляторов хватает на 2 недели поездок на работу — по 3-3.5 часа в день
"-":
1. Цена :(
2. Микрофон ловит не просто всё, а будто ещё и усиливает шумы — как гарнитура только в тихих помещениях или нет другого выбора
3. Та самая чувствительность — лотерея — то по всей квартире работает, то из заднего кармана штанов не пробивается. Особенно заметно в час-пик в метро — стоя в плотной толпе есть шанс потерять сигнал, у и головой вертеть приходится. Есть ощущение, что вероятность «провала» звука зависит от битрейта, но специально не проверял
‐ 2010 (ALT+8208): HYPHEN
‑ 2011 (ALT+8209): NON-BREAKING HYPHEN
‒ 2012 (ALT+8210): FIGURE DASH
– 2013 (ALT+8211): EN DASH
— 2014 (ALT+8212): EM DASH
― 2015 (ALT+8213): HORIZONTAL BAR
− 2212 (ALT+8722): MINUS SIGN
“ 201c (ALT+8220): LEFT DOUBLE QUOTATION MARK
„ 201e (ALT+8222): DOUBLE LOW-9 QUOTTION MARK
… 2026 (ALT+8230): HORIZONTAL ELLIPSIS
« ab (ALT+0171): LEFT-POINTING DOUBLE ANGLE QUOTATION MARK
» bb (ALT+0187): RIGHT-POINTING DOUBLE ANGLE QUOTATION MARK
НО! При использовании мультимедийных клавиатур и/или ноутбуков (фактически — ACPI клавиш/событий) вылезает глюк с появлением дополнительной «лишней» раскладки. Гугл говорит, что это бага Xorg-а и советов по лечению не даёт. Пересобирать Xorg ради этого, естественно, нет ни малейшего желания.
Я для себя сделал кнопку с запуском на таскбаре. Попытки повесить обработчик на multimedia клавиши или загнать это дело в cron не помогли (возможно надо что-то мудрить с параметрами bash/gnome-terminal).
try: print "TRY!" finally: print "Finally!" === TRY! Finally!Замечательно работает. Остальное же — да, запрещено, да и смысла, вроде, не имеет. Зачем может понадобиться try/else сочетание — ума не приложу %)
finally мне видится полезным при работе с ресурсами, которые обязательно надо освободить. В случае же exception-а ресурс может оказаться занятым. Например, открытый файл, сокет, всякие семафоры с флагами и т.п.
Мне сейчас скажут, что есть же with, но он далеко не всегда доступен :( Говорят, в python 3000 with должен поддерживаться большей частью библиотек, для версий же 2.5-2.6 это не так. Сам, недавно испольpуя urllib, с огорчением для себя обнаружил, что с ним with не работает.
pygmentize.py -O style=native,encoding=utf-8,full=true,outencoding=cp1251,noclasses=true -o manage.py.html manage.py
… попробовал. стили и из тэгов вырезаются…
тогда — после этого простенький regexp натравить для замены стиля из span на <font folor="">, <i>, <b>?