Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 80
хорошая статья
не имею дело непосредственно с Python, но идея отличная :) плюс
Полезная ссылка :)
Да уж код вышел весьма некрасивый после Source Code Highlighter-а. Жаль, что он не поддерживает питон корректно. Все остальные подсвечивалки, которые я нашел, используют CSS, который, как понимаю, хабрапарсер не пропустит по соображениям безопасности. Можете порекомендовать хороший онлайн-хайлайтер с поддержкой python на чистом html?
Да уж код вышел весьма некрасивый после Source Code Highlighter-а. Жаль, что он не поддерживает питон корректно. Все остальные подсвечивалки, которые я нашел, используют CSS, который, как понимаю, хабрапарсер не пропустит по соображениям безопасности. Можете порекомендовать хороший онлайн-хайлайтер с поддержкой python на чистом html?
Именно онлайн?
Хотя и их есть :) — тот же pygments, который используется на приведённой ссылке с сорцами. Где-то у них на сайте есть ссылка на онлайн-демо с возможностью получить html или rtf.
Хотя и их есть :) — тот же pygments, который используется на приведённой ссылке с сорцами. Где-то у них на сайте есть ссылка на онлайн-демо с возможностью получить html или rtf.
Пигменты смотрел, но там опять на стилях.
нихрена се «полезная»…
«пеп-восемь» наизусть вообще каждый разработчик должен знать =).
«пеп-восемь» наизусть вообще каждый разработчик должен знать =).
:)
Оформлено-то оно нормально, проблема в другом — взрывоопасная сместь Source Code Highliter + HabraParser взорвали код, особенно 8-ю строку.
Поэтому я убираю отсюда код и переношу все на гугл:
code.google.com/p/intervalmap/source/browse/trunk/intervalmap.py
Оформлено-то оно нормально, проблема в другом — взрывоопасная сместь Source Code Highliter + HabraParser взорвали код, особенно 8-ю строку.
Поэтому я убираю отсюда код и переношу все на гугл:
code.google.com/p/intervalmap/source/browse/trunk/intervalmap.py
не…
там строки есть по 100+ символов. в тесте так вообще больше 200 =). Название всего класса спорное. Assert лучше не использовать — ведь при -OO у вас все перестанет работать =) Там где пользовательские каяки проверяются — эксепшн простой нужен. Докстринги не по пеп-8. Pylint вообще переплевался весь)
До кучи — на 2.4 не работает, а об этом ни слова нет. Ко всему прочему — это изза «else» в try — только и всего.
Паблик вещи надо ж очень хорошо прилизывать…
там строки есть по 100+ символов. в тесте так вообще больше 200 =). Название всего класса спорное. Assert лучше не использовать — ведь при -OO у вас все перестанет работать =) Там где пользовательские каяки проверяются — эксепшн простой нужен. Докстринги не по пеп-8. Pylint вообще переплевался весь)
До кучи — на 2.4 не работает, а об этом ни слова нет. Ко всему прочему — это изза «else» в try — только и всего.
Паблик вещи надо ж очень хорошо прилизывать…
Интересно, большое спасибо!
Спасибо, только что за взрыв на 8-й строке?
Visual Code Highligher + HabraParser :)
Можно посмотреть в нормальном виде здесь: paste.pocoo.org/show/90012/
Можно посмотреть в нормальном виде здесь: paste.pocoo.org/show/90012/
неплохо бы комменты выравнять, а то проблемы при выполнении тестов
Как вы заметили, я не претендую на открытие Америки :)
Я описал принцип использования интервального хеша. Пример добавлен для большей наглядности — на самом деле я решал совсем другую задачу :)
Здесь реализованы базовые вещи, и само собой, всегда есть, что можно добавить.
Реализовать поиск по фамилии не сложно: нужно сделать поиск по массиву _items и взять соответствующее значение из _bounds. С русскими буквами работало бы без проблем:
Поиск без учета регистра: самое простое — последовательное сравнение с .upper(). Конечно, для больших списков это неэффективно, но это уже другая задача.
Я описал принцип использования интервального хеша. Пример добавлен для большей наглядности — на самом деле я решал совсем другую задачу :)
Здесь реализованы базовые вещи, и само собой, всегда есть, что можно добавить.
Реализовать поиск по фамилии не сложно: нужно сделать поиск по массиву _items и взять соответствующее значение из _bounds. С русскими буквами работало бы без проблем:
>>> ['аб', 'вг'].index('вг')
1Поиск без учета регистра: самое простое — последовательное сравнение с .upper(). Конечно, для больших списков это неэффективно, но это уже другая задача.
А в чем проблема? Если с самого начала использовать юникод, тогда все обработается корректно:
>>> print u'Вася Пупкин'.upper() ВАСЯ ПУПКИН $ python -V Python 2.5.2
А что там не так с русскими буквами?
Python 2.5.2
>>> print u«час».upper()
ЧАС
Python 2.5.2
>>> print u«час».upper()
ЧАС
print unicode(a).upper()
Так что, все таки работает «upper с русскими буквами и utf-8»? :)
Что-то из него я уже использую :)
Например, модуль processing для управления процессами как потоками. С 3-ей версии он будет числе базовых.
Например, модуль processing для управления процессами как потоками. С 3-ей версии он будет числе базовых.
Вопрос: что возвращает raw_input в такой ситуации?
a — это не строка, это какое-то фуфло напоминающее utf-8. Вернее, по последовательности байтов это и есть «абв» в utf-8, но питон-то об этом не знает. Еще больше с толку сбивает, что на печати вы видите то, что ожидаете:
Но только питон не знает, что это строка в utf-8. Поэтому он ее обрабатывает некорректно. Это то же самое, что пытаться вывести int как последовательность байтов — выйдет не совсем то, что ожидалось.
Поэтому эту строку нужно сконвертировать в unicode:
Можете проверить: с точки зрения байтов это одно и тоже, только теперь питон правильно воспринимает эту строку.
>>> a=raw_input() абв >>> a '\xd0\xb0\xd0\xb1\xd0\xb2'
a — это не строка, это какое-то фуфло напоминающее utf-8. Вернее, по последовательности байтов это и есть «абв» в utf-8, но питон-то об этом не знает. Еще больше с толку сбивает, что на печати вы видите то, что ожидаете:
>>> print a абв
Но только питон не знает, что это строка в utf-8. Поэтому он ее обрабатывает некорректно. Это то же самое, что пытаться вывести int как последовательность байтов — выйдет не совсем то, что ожидалось.
Поэтому эту строку нужно сконвертировать в unicode:
>>> a8 = unicode(a, 'utf-8') >>> a8 u'\u0430\u0431\u0432'
Можете проверить: с точки зрения байтов это одно и тоже, только теперь питон правильно воспринимает эту строку.
>>> print a8.upper() АБВ >>> print a.upper() абв
Я ждал этот вопрос :)
На самом деле в консоли, просто чтобы не грузить и не отвлекать людей на несущественные детали, я подправил вывод.
Если нужно чтобы в консоли строки не экранировались, можно переопределить представление строки:
Впрочем это довольно коряво и кроме как «пощупать» в консоли лучше нигде не использовать.
На самом деле в консоли, просто чтобы не грузить и не отвлекать людей на несущественные детали, я подправил вывод.
Если нужно чтобы в консоли строки не экранировались, можно переопределить представление строки:
>>> class Str(str):
... def __repr__(self):
... return "'" + self + "'"
...
>>>
>>> s=Str("фбв")
>>> s
'фбв'Впрочем это довольно коряво и кроме как «пощупать» в консоли лучше нигде не использовать.
Здесь самое главное — внимательно проследить путь объектов, с которыми вы имеете дело. Нужно убедиться, что везде используются unicode-объекты, а не строки с псевдо-unicode содержимым, про которые я писал чуть выше. Если их просто печатать, но их легко спутать по содержимому. Используйте проверку типа вместе с содержимым:
Давайте рассмотрим «чистый» пример.
>>> type(u'абв')
<type 'unicode'>
>>> type('абв')
<type 'str'>Давайте рассмотрим «чистый» пример.
>>> import re
>>> reg = re.compile(u'АБВ')
>>> print reg.match(u'АБВ')
<_sre.SRE_Match object at 0xb7df0218>
>>> print reg.match(u'абв')
None
# вроде бы работает, но на самом деле - нет.
# получается примерно та же проблема как с цепочкой байт
>>> reg = re.compile(u'АБВ', re.IGNORECASE)
>>> print reg.match(u'АБВ')
<_sre.SRE_Match object at 0xb7df01e0>
>>> print reg.match(u'абв')
None
# Дело в том, что нужно везде указать, что вы используете unicode-объекты:
>>> reg = re.compile(u'АБВ', re.UNICODE | re.IGNORECASE)
>>> print reg.match(u'абв')
<_sre.SRE_Match object at 0xb7df0250>
>>> print reg.match(u'АБВ')
<_sre.SRE_Match object at 0xb7df0250>
* This source code was highlighted with Source Code Highlighter.
А откуда python узнает, что в переменной a — юникод строка? Или, может, в культуре запускающего программу нет понятия букв в верхнем регистре — он использует только нижний регистр, или, наоборот только ВЕРХНИЙ? разве в питоне нет возможности обрабатывать вводимые строки в соответствии с явно прописанной локалью пользователя или программиста (что-то типа setlocale)?
К примеру, несмотря на юникод, в какой-то из культур (то ли шведской, то ли норвежской) принятый порядок лексикографического сравнения латинских букв с диакритическими знаками отличается от общепринятого в остальных странах Европы и попытка лексикографической сортировки «по умолчанию» у таких пользователей пройдёт не так, как они хотят.
Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…
К примеру, несмотря на юникод, в какой-то из культур (то ли шведской, то ли норвежской) принятый порядок лексикографического сравнения латинских букв с диакритическими знаками отличается от общепринятого в остальных странах Европы и попытка лексикографической сортировки «по умолчанию» у таких пользователей пройдёт не так, как они хотят.
Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…
> А откуда python узнает, что в переменной a — юникод строка?
Вы ему об этом сообщите, создав именно unicode объект, а не обычную строку str.
> Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…
Никто не спорит. Только в комментариях я говорил не про локали, а про корректную работу с юникодом.
А поддержка локалей, это отдельная тема: www.python.org/doc/2.5.2/lib/module-locale.html
Вы ему об этом сообщите, создав именно unicode объект, а не обычную строку str.
> Интернационализация — слишком сложная вещь, что бы её можно было решить заменой литералов вида u'юникод' на 'юникод'…
Никто не спорит. Только в комментариях я говорил не про локали, а про корректную работу с юникодом.
А поддержка локалей, это отдельная тема: www.python.org/doc/2.5.2/lib/module-locale.html
Собственно, я и сообщал автору исходника, что комп не знает, что в raw_input вводится юникод. Пример, как надо работать с вводом (хотя там сложнее немного):
x@y:~$ echo $LANG
ru_RU.UTF-8
x@y:~$ python
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
>>> print raw_input( 'превед ' ).upper()
превед медвед
медвед
# ^-- python не телепат
>>> import locale
>>> print raw_input( 'превед ' ).decode(locale.getdefaultlocale()[1]).upper()
превед медвед
МЕДВЕД
# ^-- как надо было
x@y:~$ echo $LANG
ru_RU.UTF-8
x@y:~$ python
Python 2.5.2 (r252:60911, May 7 2008, 15:19:09)
>>> print raw_input( 'превед ' ).upper()
превед медвед
медвед
# ^-- python не телепат
>>> import locale
>>> print raw_input( 'превед ' ).decode(locale.getdefaultlocale()[1]).upper()
превед медвед
МЕДВЕД
# ^-- как надо было
Ну да, строку байт надо превратить в юникодную строчку, тогда все заработает.
С другой стороны, хорошо бы чтобы это делалось автоматом после ввода. Тем более все данные есть.
Пусть будет метод advanced_raw_input, который все и обработает. Я так понимаю, примерно этого хочет товарищ.
С другой стороны, хорошо бы чтобы это делалось автоматом после ввода. Тем более все данные есть.
Пусть будет метод advanced_raw_input, который все и обработает. Я так понимаю, примерно этого хочет товарищ.
А если на системе кривая локаль, а приложение должно работать?.. Я, если честно, вышеприведённый мной пример сначала попробовал на cygwin — там ничего не заработало, т.к. там криво реализованы POSIX-локали. В Перле автоматический ввод/вывод в юникоде реализуется с помощью переменной окружения PERL_UNICODE, но это тоже не универсально, т.к. там много пограничных случаев. В частности, только автор может решить в какой кодировке ему работать с нестандартными потоками ввода/вывода (они ведь могут вообще быть бинарными).
> В частности, только автор может решить в какой кодировке ему работать с нестандартными потоками ввода/вывода (они ведь могут вообще быть бинарными).
Я считаю, что это в большей степени зависит от самих потоков, чем от автора программы.
А вот ввод и вывод через стандартные потоки (которые даже называются stdin, stdout, stderr) должен быть максимально стандартным на всех платформах. Собственно ради этого и придуман POSIX.
Если в системе локаль кривая, то надо брать админа за гопy и заставлять настраивать. Увы, пока такое встречается, но, надеюсь, что скоро уйдет в прошлое.
Я считаю, что это в большей степени зависит от самих потоков, чем от автора программы.
А вот ввод и вывод через стандартные потоки (которые даже называются stdin, stdout, stderr) должен быть максимально стандартным на всех платформах. Собственно ради этого и придуман POSIX.
Если в системе локаль кривая, то надо брать админа за гопy и заставлять настраивать. Увы, пока такое встречается, но, надеюсь, что скоро уйдет в прошлое.
Через потоки POSIX передаются не только текстовые, но и бинарные данные. Так что я согласен с доводом максимальной стандартности, но при этом надо чётко отрецензировать большое количество библиотек, многие из которых, особенно на win32 уже не поддерживаются и даже не имеют исходников. Это — малореально…
Ибо тогда, к примеру, возникает вопрос: а что делать по умолчанию с потоками, где встречаются utf-суррогаты и отсутствующие символы (например, дуализм unicode 0x0 и java 0x0). Это нетривиально, поэтому в Перле в конце концов (5.8.x) остановились на варианте максимальной совместимости со старым кодом (не придумывать ничего за программиста). Вставить же в начале программы прагмы (слои) потоков (PerlIO layers) — способен программист любого уровня (но с этим постоянные проблемы, т.к. люди просто не понимают разницу между семантикой данных и сериализацией этих данных).
P.S. Прежде чем делать стандартизованный ввод/вывод, надо хотя бы от последнего американского программиста добиться замены char * на unsigned char*, а ещё лучше — на безопасные unicode-контейнеры.
P.P.S. проверил на Asus wl700ge (optware) — там raw_input вообще не запрашивает ввод. ;-) А вы говорите, админа… Понятно, что в linux, freebsd (и macosx) всё нормально с локалями, но этими системами хосты не ограничиваются. Поэтому о стандартизации ввода/вывода можно будет говорить не ранее, как отрапортуют об успешном решении «проблемы 2038K» :)
Ибо тогда, к примеру, возникает вопрос: а что делать по умолчанию с потоками, где встречаются utf-суррогаты и отсутствующие символы (например, дуализм unicode 0x0 и java 0x0). Это нетривиально, поэтому в Перле в конце концов (5.8.x) остановились на варианте максимальной совместимости со старым кодом (не придумывать ничего за программиста). Вставить же в начале программы прагмы (слои) потоков (PerlIO layers) — способен программист любого уровня (но с этим постоянные проблемы, т.к. люди просто не понимают разницу между семантикой данных и сериализацией этих данных).
P.S. Прежде чем делать стандартизованный ввод/вывод, надо хотя бы от последнего американского программиста добиться замены char * на unsigned char*, а ещё лучше — на безопасные unicode-контейнеры.
P.P.S. проверил на Asus wl700ge (optware) — там raw_input вообще не запрашивает ввод. ;-) А вы говорите, админа… Понятно, что в linux, freebsd (и macosx) всё нормально с локалями, но этими системами хосты не ограничиваются. Поэтому о стандартизации ввода/вывода можно будет говорить не ранее, как отрапортуют об успешном решении «проблемы 2038K» :)
Да, есть такая проблема: очень много старого кода написано из рассчета на ascii, latin-1 или даже на 7-bit кодировку.
Поэтому пока не произойдет перенос всего на юникод, будут проблемы «переходного возраста». Поэтому в питоне сейчас есть два типа строк — 8-битные и юникодные. Так же есть два типа классов: старые и новые. Представляю, сколько проблем совместимости пришлось решить ребятам, чтобы хотя бы это работало нормально.
Что делать с конкретными потоками — трудно сказать, видимо придется каждый раз делать что-то привязанное к задаче.
Какая система на асустике? И какой питон? Может он вообще встроенный?
Поэтому пока не произойдет перенос всего на юникод, будут проблемы «переходного возраста». Поэтому в питоне сейчас есть два типа строк — 8-битные и юникодные. Так же есть два типа классов: старые и новые. Представляю, сколько проблем совместимости пришлось решить ребятам, чтобы хотя бы это работало нормально.
Что делать с конкретными потоками — трудно сказать, видимо придется каждый раз делать что-то привязанное к задаче.
Какая система на асустике? И какой питон? Может он вообще встроенный?
Верно. Я в связи с этим избегаю вообще использовать понятия строк таких-то, строк сяких-то. Есть два типа объекта: вектор/массив байтов и вектор символов (собственно, строка). Они просто имеют похожий интерфейс.
Кстати, проблем не так много, если рассматривать данные сущности, как полиморфные классы с похожим интерфейсом.
Asus — Asus 1.0.7.8-kc + optware oleg/cross
Кстати, проблем не так много, если рассматривать данные сущности, как полиморфные классы с похожим интерфейсом.
Asus — Asus 1.0.7.8-kc + optware oleg/cross
Я стараюсь все делать в юникоде. Хотя с выводом этого добра на консоль в свое время намучался.
Интерфейс общий, а внутри различия могут быть очень серьезные.
На базе чего эта сделана эта система — linux?
Интерфейс общий, а внутри различия могут быть очень серьезные.
На базе чего эта сделана эта система — linux?
Главное не ставить обработку юникода в библиотеки (кроме application-specific модулей).
Различия непринципиальны, если помнить всегда, что на выходе любых методов получается всегда такой же объект. А вот в случае операторов (во всяком случае, в перле), это не так. В перле обычно, в результате оператора, с одной из сторон которого стоит символьные строки, получаются символьные строки с неявным преобразованием байтовых в символьные.
$ uname -a
Linux WL700gE 2.4.20 #44 Sat Jan 26 20:07:26 EST 2008 mips unknown
Плюс в стандартной прошивке: uClibc, busybox. Плюс optware-порты под эту платформу. В общем, кривизна на кривизне, если говорить про архитектуру — содержимое / менять очень геморройно.
Различия непринципиальны, если помнить всегда, что на выходе любых методов получается всегда такой же объект. А вот в случае операторов (во всяком случае, в перле), это не так. В перле обычно, в результате оператора, с одной из сторон которого стоит символьные строки, получаются символьные строки с неявным преобразованием байтовых в символьные.
$ uname -a
Linux WL700gE 2.4.20 #44 Sat Jan 26 20:07:26 EST 2008 mips unknown
Плюс в стандартной прошивке: uClibc, busybox. Плюс optware-порты под эту платформу. В общем, кривизна на кривизне, если говорить про архитектуру — содержимое / менять очень геморройно.
ну и для кучи:
Python 2.6
>>> print u«час».upper()
ЧАС
Python 2.6
>>> print u«час».upper()
ЧАС
У меня самый большой вопрос сейчас вызывает копирование объектов.
Как быть уверенным, что при любом содержании хеша, объект будет скопирован корректно?
Использовать deepcopy? Это вроде как из пушки по воробьям. Можете что-нибудь порекомендовать?
Как быть уверенным, что при любом содержании хеша, объект будет скопирован корректно?
Использовать deepcopy? Это вроде как из пушки по воробьям. Можете что-нибудь порекомендовать?
Это очень круто. Всё больше и больше скатываюсь в Питон…
Интересно и красиво выглядит, решая на PHP подобную задачу заставил бы базу делать эти операции.
Можно и с базой. Мое текущее решение задачи активно использует базу, но в моей ситуации это не эффективно: объем хранимых данных небольшой, а запросов получается много. Эта разработка как раз для снижения нагрузки.
Кроме того, думаю будет не так просто обрабатывать пересечения интервалов. Ведь здесь возможны самые разные случаи:
— нет пересечения — все просто, оставляем как есть
— полное пересечение — стираем перекрытый ключ
— частичное перекрытие — нужно сократить старый ключ, или же наборот удлинить при равенстве значений
— фрагментация — из одного старого ключа получается два
— комбинация выше перечисленных случаев.
Если это все обрабатывать, то в базе придется держать довольно сложную логику.
Кроме того, думаю будет не так просто обрабатывать пересечения интервалов. Ведь здесь возможны самые разные случаи:
— нет пересечения — все просто, оставляем как есть
— полное пересечение — стираем перекрытый ключ
— частичное перекрытие — нужно сократить старый ключ, или же наборот удлинить при равенстве значений
— фрагментация — из одного старого ключа получается два
— комбинация выше перечисленных случаев.
Если это все обрабатывать, то в базе придется держать довольно сложную логику.
Сделал field для Django с такой функциональностью. Авось пригодится.
Класс!
А в каком виде оно будет записываться в базу?
А в каком виде оно будет записываться в базу?
{[1:2] => 3, [2:4] => ...}, текстом. Не лучший вариант — при чтении оно вообще через eval гоняется, но это надо еще подумать, как хорошо сделать.
Eval? Но пока нормальный конструктор не написан. Чтобы можно было вызывать примерно так:
Надо будет придумать наиболее удобный синтаксис создания.
tt = intervalmap( slice('08:00', '12:00'), 'Иванов')
Надо будет придумать наиболее удобный синтаксис создания.
Вот сегодня и займусь :)
:)
Да синтаксис-то ладно, это полировка.
Я вот над работоспособностью самой штуки думаю.
Я выложил ее на гугль — code.google.com/p/intervalmap/source/browse/trunk/intervalmap.py
Предлагаю ядро этой штуки разрабатывать отдельно, а прикладные вещи тоже отдельно. Тогда мы получил гораздо большую гибкость.
Да синтаксис-то ладно, это полировка.
Я вот над работоспособностью самой штуки думаю.
Я выложил ее на гугль — code.google.com/p/intervalmap/source/browse/trunk/intervalmap.py
Предлагаю ядро этой штуки разрабатывать отдельно, а прикладные вещи тоже отдельно. Тогда мы получил гораздо большую гибкость.
code.google.com/p/django-interval-field/source/browse/trunk/interval.py
Возьмите тогда отсюда еще __eq__ — строка 148 :)
Возьмите тогда отсюда еще __eq__ — строка 148 :)
Интересная вещь.
Но у нас есть одно серьезное упрощение: интервалы не пересекаются. Иначе сама идея хеша как однозначного сопоставления значения ключу перестает работать.
Что касается производительности, то ожидается, что bisect работает со скоростью порядка O(log2(N)).
Правда, другие операции существенно медленнее — порядка O(N).
Но у нас есть одно серьезное упрощение: интервалы не пересекаются. Иначе сама идея хеша как однозначного сопоставления значения ключу перестает работать.
Что касается производительности, то ожидается, что bisect работает со скоростью порядка O(log2(N)).
Правда, другие операции существенно медленнее — порядка O(N).
А кто-нибудь знает, есть ли что-нибудь на подобие топика в Ruby?(только не бейте)
ассоциативные массивы — это волшебно)
ассоциативные массивы — это волшебно)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Интервально-ассоциативный массив