Площадка на Войкова 6

Автошкола-онлайн опять. Сюрпризы продолжаются.

Уж не знаю, совпало так или я слишком сильно им мозоль придавил своими глупыми требованиями предоставить мне эстакаду, но занятия на площадке у Речного вокзала перенесли на площадку по адресу ул. Войкова 6; координаты lat, lon: 55.855234,37.523758.

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

На Войкова 6 добираться на перекладных или на оленях полдня. Зато там есть эстакада, новенькая совсем, на днях построили. Но это территория спиртзавода и охрана не пускает. Только в сопровождении инструктора.

В общем, интересная учеба. Уже на трех площадках покатался и на трех машинках — два фольцвагена поло и один рено дастер. Нет, на четырех — три фольцвагена поло. Все фольцвагены новенькие.

Я так понимаю, что когда в школе говорят «площадка на Речном или Водном Стадионе или Войковской» – это они теперь про вот эту площадку:

http://maps.yandex.ru/?um=64ZsHjOxctsQKUIRujhF8Mf_zIkW1fJt&l=sat%2Cskl%2Csat

http://wikimapia.org/#lang=ru&lat=55.855335&lon=37.523798&z=19&m=b

https://www.google.ru/maps/place/55%C2%B051%2718.8%22N+37%C2%B031%2725.5%22E/@55.8551477,37.5237822,320m/data=!3m1!1e3!4m2!3m1!1s0x0:0x0

На м. Водный стадион сесть в автобус 65 или 72, выйти на 6-ой остановке "Лихоборская наб.", далее пешком до территории (стопанут на шлагбауме) и позвонить инструктору.

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

original post http://vasnake.blogspot.com/2014/09/6.html

scikit-learn

scikit-learn is a Python module for machine learning built on top of SciPy and distributed under the 3-Clause BSD license

https://github.com/scikit-learn/scikit-learn

Не знаю, почему они назвали пакет модулем, не обращайте внимания, я не про это.

В Линкедин, в группе BigData & Analytics всплыло прекрасное.

Классификатор классификаторов модулей scikit-learn, алгоритм выбора нужного инструмента:

http://scikit-learn.org/stable/tutorial/machine_learning_map/index.html

И там же вспомнили про аналогичный проект http://dlib.net/ml_guide.svg

C++ библиотеку Dlib, подмножество ml: http://dlib.net/ml.html

A major design goal of this portion of the library is to provide a highly modular and simple architecture for dealing with kernel algorithms

Что может быть полезнее хорошей шпаргалки?

original post http://vasnake.blogspot.com/2014/09/scikit-learn.html

Где люди живут

Интересную картинку видел сегодня:

http://next.pwc.de/2014-02/funkloecher.html

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

Если щелкать по сетке, можно загрузить PDF-ки с детальной информацией.

Лично меня удивили Австралия и Южная Америка. Я думал, там цивилизация несколько распространеннее. А вот пост-СССР не удивил как раз. Такая страшная и ужасная Россия, а посмотрите, сколько площади занимает реально значимые территории. Меньше западной Европы.

Правда, площади надо сравнивать с осторожностью, ибо проекция Меркатора сильно врет (чем дальше от экватора, тем сильней) про площади.

https://gmaps-samples.googlecode.com/svn/trunk/poly/puzzledrag.html

original post http://vasnake.blogspot.com/2014/09/blog-post_26.html

War and peace

В сериале Seinfeld много смешного. Например, шутка про Войну и Мир Льва Толстого.

Elaine: Oh! Don't you know what this means, it's like working with Tolstoy!

Jerry: Hey ya know what I read the most unbelievable thing about Tolstoy the

other day, did you know the original title for "War and Peace" was

"War--What Is It Good For?"!

Elaine: Ha ha.

Jerry: No, no.. I'm not kidding Elaine it's true, his mistress didn't like

the title and insisted him change it to "War and Peace"!

Elaine: But it's a line from that song!

Jerry: That's were they got it from!

Elaine: Really?

Jerry: I'm not joking!

http://www.seinfeldscripts.com/TheMarineBiologist.htm

А вот и пестня, из которой Толстой позаимствовал оригинальное название (хаха)

http://youtu.be/dpWmlRNfLck

original post http://vasnake.blogspot.com/2014/09/war-and-peace.html

Duster

Renault Duster это машинка, на которой я теперь буду учиться по городу ездить. Я еще и половины уроков не откатал (сегодня был 10 из 24) а уже покатался на трех машинках — два Volkswagen Polo и один Renault Duster.

Что любопытно, фольцвагены новенькие, 20-30 тысяч пробега, а рено изрядно поюзаный, уже за 126 тысяч перевалило. Аккумулятор у рено дохлый, сегодня с толкача два раза заводили машинку, после того как я умело глох на маневре. Сцепление разболтанное, вызывает дрожь земли на фазе трогания. Передачи надо дотыкивать с усилием, нет четкости, как у новеньких поло.

При практически одинаковой цене базовой комплектации, дастер изнутри выглядит победнее и попроще, чем поло. Меньше регулировок сидения, нет электроподьемника стекол и всякое такое, по мелочи. Зато головой в потолок не упираешься и сидишь заметно выше, что приятно. Правда, в рено места для ступней, на педалях, маловато, по ставнению с поло. Как-то тесно там ногам.

А в целом неплохо, комфортно. Мне понравилось.

Сегодня урок считался «в городе», перед этим были на площадке. Но реально в город мы не ездили. Почти час я осваивался с новой машиной, выполняя весь комплект упражнений на площадке (кроме эстакады), потом мы выехали за площадку на пустую дорожку рядом, и я пробовал стартовать как положено, с добавлением газа (по площадке все ездят на холостых оборотах), разгоняться с переключением передач 1-2-3 и останавливаться.

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

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

original post http://vasnake.blogspot.com/2014/09/duster.html

Комментарии к ПДД РФ

Полностью книга называется очень длинно и скушно. Более короткий вариант:

«Комментарии к Правилам дорожного движения РФ»

Под редакцией В.Н. Кирьянова. 2011. 327 стр. ISBN 978-5-9698-0389-3

http://goo.gl/ASVvtK

Я ее утянул к себе и расшарил, пользуйтесь:

https://drive.google.com/file/d/0B-jgR_nGC_c-djZ2MngtajBfMXc/edit?usp=sharing

скопипижжено с http://padabum.com/d.php?id=80921

Удивительный факт — в Сети эту книгу найти очень непросто. Видимо, не нужна никому. Хотя, если люди не врут, именно сведениями из этой книги руководствуются бойцы ГИБДД при отлове и наказании водятлов.

original post http://vasnake.blogspot.com/2014/09/blog-post_23.html

Twisted

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

Twisted is an event-driven networking engine written in Python and licensed under the open source ​MIT license

https://twistedmatrix.com/trac/

Я тут доклад с HighLoad++ увидел, аж 2010 года, про Twisted. Сумбурно но интересно рассказывают про то, как применяли сабж на практике. К сожалению, не слишком подробно и без технических деталей.

И немного про Tornado:

Вопрос из зала: Можно сказать пару слов об альтернативах? Было сказано, что Twisted хорошо подходит для определенного класса задач. Если у меня возникает задача такого класса, я хочу сначала понять, что мне нужно – Twisted, или Tornado, или NoJS.

Андрей Смирнов: Мне очень тяжело говорить, потому что это очень специфически. Надо отдельно готовиться, чтобы сравнивать.

Можно сказать пару слов о Tornado. Мне не хочется сказать ничего плохого. Но человек из FriendFeed, который написал Tornado, какое-то время крутился в сообществе Twisted, задавал вопросы, но не осилил. Это честно. Он задавал вопросы, на какое-то время ушел в себя, написал Tornado. Но, по сути, написал почти то же самое. В некоторых тестах он дает лучшую производительность.

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

В мире продуктов на "Си" с открытыми исходниками Postgres – несомненный лидер в смысле самой разработки. Там можно поучиться тому, как разрабатывать любой проект на "Си".

Twisted для Python тоже один из примеров того, как хорошо разрабатывать проект. Делают его тоже очень долго (этому проекту больше десяти лет), развивают достаточно медленно и аккуратно, что похоже на Postgres. Любой функционал обсуждается, потом предоставляется патч, затем идет выделение отдельной ветки. Эту ветку они могут делать месяцами и годами. Есть открытые тикеты, которым по 4-5 лет. Они все-таки кого-то не удовлетворяют, поэтому это не "коммитится"

...

http://profyclub.ru/docs/124

Это что же получается? Торнадо появилось как результат «не постигаю» Твистед? Неосилятор написал свой велосипед, с блекджеком и шлюхами? Очень интересно.

А что вы знаете про Циклон? http://cyclone.io/

original post http://vasnake.blogspot.com/2014/09/twisted.html

Mplayer

На днях у меня отказался работать SMplayer, фактически Mplayer. Сказал, что «libdvdnavmini.so.4: cannot open shared object file» и ушел в отказ.

Недолгое гугление привело к простому рецепту починки:

su -l
ldd $(which mplayer2) | grep "not found"
ln -s /usr/lib/x86_64-linux-gnu/libdvdnav.so.4.1.2 /usr/lib/x86_64-linux-gnu/libdvdnavmini.so.4

Первоисточник http://crunchbang.org/forums/viewtopic.php?pid=390892

original post http://vasnake.blogspot.com/2014/09/mplayer.html

PEP 8, Programming Recommendations

Изучаем PEP 8 по частям. Часть 7, Programming Recommendations. Практически крайняя.

Тут говорится о том, что:

Не надо писать такой код, который будет трудно запустить под другими Python машинами (PyPy, Jython, …).

Например, не надейтесь на CPython-скую эффективность реализации склеивания строк в форме a += b или a = a + b. Оптимизация этой операции хрупка даже в CPython (работает только для некоторых типов) и ее вовсе нет в машинах не использующих подсчет ссылок. Более правильным, с точки зрения производительности, будет использование формы ''.join(). Так можно гарантировать линейное время выполнения операции.

Сравнение с синглтонами вроде None следует всегда делать в форме «x is None» или «x is not None», и никогда через оператор сравнения.

Также, остерегайтесь писать «if x» когда в действительности вы подразумеваете «if x is not None», например, когда проверяете переменную по умолчанию установленную в None. Можете натолкнуться на ситуацию, когда некий тип данных (вроде контейнера) может выдать False в контексте булевых операций.

Используйте «is not» оператор вместо «not … is». Хотя функционально оба варианта идентичны, первое более читабельно.

if foo is not None:

При реализации операций упорядочивания с многовариантными сравнениями, лучше написать все шесть магических метода (__eq__, __ne__, __lt__, __le__, __gt__, __ge__) нежели полагаться на то, что другой код воспользуется только некоторыми из них.

Чтобы не перенапрягаться при этом, можете воспользоваться декоратором functools.total_ordering() для генерации недостающих методов.

PEP 207 показывает что в Python предполагаются правила рефлексивности. Так, интерпретатор может заменить y > x на x < y и т. д. Операции sort() и min() гарантируют использование оператора < и функция max() использует оператор >. Однако, лучше реализовать все шесть и не опасаться возможных неприятностей использования вашего кода в других контекстах.

Всегда используйте выражение «def ...» вместо присваивания лямбда выражения идентификатору

def f(x): return 2*x
f = lambda x: 2*x

Первая форма означает, что имя получившегося объекта (функции) есть «f» вместо общего «<lambda>». Это полезнее при отладке и выводе на печать. Использование присваивания уничтожает единственную выгоду от использования лямбды — анонимность, приводящую к возможности использования лямбды в составном выражении.

Наследуйте свой класс исключений от класса Exception а не от BaseException. Прямое наследование от BaseException зарезервировано для исключений, которые не надо перехватывать.

Проектируйте иерархию классов исключений основываясь на том, что нужно коду, поймавшему исключение, в противовес месту, где случилось исключение. Нацеливайтесь ответить на вопрос «что пошло не так?», нежели декларировать «случилась неприятность». См. PEP 3151 как на пример.

Тут применимы правила именования классов, только добавляйте суффикс «Error» для тех исключений, что отлавливают ошибки. Исключения сигнализирующие о чем-то другом нуждаются в других суффиксах.

Используйте цепочки исключений (exception chaining) разумно. В Python 3 выражение «raise X from Y» следует использовать для указания явной замены без потери оригинального стека (traceback).

В случае умышленной замены внутреннего исключения (используя «raise X» в Python 2 или «raise X from None» в Python 3.3+), потрудитесь обеспечить передачу важной информации в новое исключение (сохраняя имя атрибута, превращая KeyError в AttributeError, или текст сообщения).

В Python 2 используйте форму вызова «raise ValueError('message')» вместо «raise ValueError, 'message'».

Второй способ устарел и не работает в Python 3.

Вариант со скобочками также означает, что легче будет писать длинные аргументы с переносами строк.

При отлове исключений, нацеливайтесь на конкретные варианты вместо отлова более общих

try:
    import platform_specific_module
except ImportError:
    platform_specific_module = None
except:
    platform_specific_module = None

Выражение «except:» поймает и SystemExit и KeyboardInterrupt и еще бог знает что, затрудняя диагностику и мешая интерактивности (обработка Ctrl-C). Если хотите отлавливать все программные ошибки, используйте «except Exception:», потому как чистый «except:» равносилен «except BaseException:».

Хорошая эмпирика такова, использовать «except:» только в двух случаях:

1. Если обработчик исключения печатает или логирует стек ошибки, так хотя бы пользователь увидит, что за ошибка была.

2. Если нужно в коде проделать работу по чистке чего-либо. Но затем надо выкинуть исключение обратно. В этом случае может быть лучше использовать «try... finally».

При связывании отловленного исключения с именем, делайте это явным образом, в синтаксисе, доступном еще в Python 2.6

try:
    process_data()
except Exception as exc:
    raise DataProcessingFailedError(str(exc))

Только этот синтаксис поддерживается в Python 3, в нем избегается неоднозначность присущая старому синтаксису, который с запятыми.

При отлове ошибок операционной системы используйте иерархию исключений, представленную в Python 3.3 вместо изучения значений errno.

В дополнение, для всех выражений try/except сводите содержимое блока try к минимуму, это помогает локализовать ошибки

try:
    value = collection[key]
except KeyError:
    return key_not_found(key)
else:
    return handle_value(value)
try:
    return handle_value(collection[key])
except KeyError:
    return key_not_found(key)

Используя ресурс, локальный конкретному участку кода, используйте выражение «with» для надежной и быстрой зачистки после его использования. Выражение try/finally тоже неплохо.

Менеджеры контекста следует вызывать через разные методы/функции, когда они выполняют что-то отличное от захвата и освобождения ресурсов. К примеру:

with conn.begin_transaction():
    do_stuff_in_transaction(conn)
with conn:
    do_stuff_in_transaction(conn)

во втором примере нет информации для менеджера контекста о том, что надо отработать транзакцию (коммит сделать, в частности), только открытие/закрытие коннекта. Важно явно выразить происходящее.

Используйте методы строкового типа а не функции строкового модуля.

Методы строки всегда быстрее и у них тот-же API, что и у юникодных строк. Но это правило неприменимо если нужна обратная совместимость с Python дряхлее 2.0.

Используйте ''.startswith() и ''.endswith() вместо применения слайсов, чтобы проверить суффиксы и префиксы.

Эти функции чище и менее подвержены ошибкам

if foo.startswith('bar'):
if foo[:3] == 'bar':

Сравнение типов объектов следует делать через isinstance()

if isinstance(obj, int):
if type(obj) is type(1):

Проверяя, что некий объект это строка, помните, что это может быть юникодная строка. В Python 2 str и unicode происходят от одного базового класса basestring, поэтому проверка может быть

if isinstance(obj, basestring):

Но, в Python 3 уже нет unicode и basestring, только str и bytes, причем bytes это и не строка вовсе а последовательность целых чисел.

Для последовательностей (строки, списки, кортежи) используйте тот факт, что пустая последовательность дает False

if seq:
if len(seq):

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

Не сравнивайте булевы значения с True/False используя «==»

if greeting:
if greeting == True:
if greeting is True:

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

Рекомендовано использовать ассоциированный декоратор при экспериментах с аннотациями, для индикации способа интерпретации аннотаций.

Ранние попытки использовать аннотации функций выявили некоторую несогласованность. К примеру:

* [str] не дает ответа — это список строк или значение суть строка либо None.

* Нотация open(file:(str, bytes)) была использована в случае, когда значение может быть bytes или str вместо кортежа из двух значений.

* Нотация seek(whence:int) показывает одновременно овер-спецификацию и недо-спецификацию: int слишком ограничивающ (подойдет все, что угодно, обладающее __index__), при этом он недостаточно ограничивающ (допустимы только значения 0, 1, 2). Также, аннотация write(b: bytes) слишком ограничивает, подошло бы что угодно с поддержкой протокола buffer.

* Аннотации вроде read1(n: int=None) противоречат сами себе, ибо None это не int. Аннотации вроде source_path(self, fullname:str) -> object сеют сомнения в типе возвращаемого значения.

* В дополнение к указанному, были аннотации несогласованные по использованию конкретных/абстрактных типов: int versus Integral и set/frozenset versus MutableSet/Set.

* Некоторые аннотации в абстрактных базовых классах имели некорректные спецификации. Например, операции set-to-set требуют, чтобы other был другим экземпляром Set нежели просто Iterable.

* Более того, аннотации становятся частью спецификации, но не были протестированы.

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

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

http://legacy.python.org/dev/peps/pep-0008/

http://docs.python-guide.org/en/latest/writing/style/

Опять много слов, а суть простая. Здесь вы видите небольшой набор best practice по работе с разными примитивами языка. Это, конечно, не укладывается в предназначение документа «Style Guide for Python Code», но мы же помним, «A Foolish Consistency is the Hobgoblin of Little Minds».

На этом PEP 8 как-то заканчивается.

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

original post http://vasnake.blogspot.com/2014/09/pep-8-programming-recommendations.html

Toolbar

Продолжаю разгребать старые проекты.

Сегодня выложил на Github компонент ESRI.ArcGIS.Client.Toolkit.Toolbar.

Это реализация тулбара с кнопками для аппликух на Silverlight. Если кто использовал ArcGIS API for Silverlight для создания веб-карт, тот, скорее всего, знает о чем это. А другим это, пожалуй, нафиг не надо.

У нас это применялось в Картобонусе

Вон он, тулбарчик, в левом нижнем углу.

original post http://vasnake.blogspot.com/2014/09/toolbar.html

PEP 8, Naming Conventions

Изучаем PEP 8 по частям. Часть 7, Naming Conventions. TL;DR

Тут говорится о том, что:

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

Самый важный принцип: имена видимые пользователю как общедоступные (открытые) интерфейсы, должны отражать использование вместо реализации. Ну, типа если метод пишет в файл текущую температуру воздуха, то этот метод надо назвать «запись_текущей_температуры» а не «выдрать_температуру_с_метеосайта».

Описание стилей именования.

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

Наболее употребимые стили:

* b (однобуквенные, нижний регистр)

* B (однобуквенные, верхний регистр)

* lowercase (нижний регистр, слово)

* lower_case_with_underscores (нижний регистр, слова через подчерк ненавижутакиеписать)

* UPPERCASE (верхний регистр, слово)

* UPPER_CASE_WITH_UNDERSCORES (верхний регистр, слова через подчерк)

* CapitalizedWords (CapWords, CamelCase – слова отбиваемые по первой букве в верхнем регистре). При использовании этого стиля, аббревиатуры пишите полностью в верхнем регистре. Пример: HTTPServerError.

* mixedCase (мой любимый почти как CamelCase, только первая буква в нижнем регистре).

* Capitalized_Words_With_Underscores (отвратительно!)

Есть еще стиль, когда используется общий префикс для группирования имен в рамках некоей темы. Такое в Python встречается не часто, но для полноты картины мы это упомянули. К примеру, функция os.stat() возвращает кортеж, где элементы традиционно называются как-то так: st_mode, st_size, st_mtime, … (Это было сделано для выделения того факта, что есть сильная связь между этими элементами и структурой из вызова POSIX).

Библиотека X11 использует имена начинающиеся с X для всех публичных функций. В Python такой стиль в целом считается ненужным, ибо имена атрибутов и методов предваряются именем объекта, имена функций предваряются именем модуля.

В дополнение есть еще формы с начальным или завершающим подчерком. Они могут быть скомбинированы с любым стилем.

* _single_leading_underscore: индикатор «внутреннего использования», но слабый. К примеру, «from M import *» не будет импортировать такие имена. Это важный пункт, ниже будет масса текста на эту тему.

* single_trailing_underscore_: используется для избегания конфликтов с ключевыми словами Python. Например

Tkinter.Toplevel(master, class_='ClassName')

* __double_leading_uderscore: при именовании атрибута класса вызывает эффект name mangling, что приводит к тому, что внутри класса FooBar атрибут __boo становится _FooBar_boo.

* __double_leading_and_trailing_underscore__: «волшебные» объекты или атрибуты, что живут в пространствах имен, контролируемых пользователем. К примеру, __init__, __import__ или __file__ Никогда не создавайте таких имен, только используйте их, как описано в документации.

Указания по использованию стилей именования.

Избегайте имен: из одной буквы ('l', 'O', 'I') - 'l' (lowercase letter el), 'O' (uppercase letter oh), or 'I' (uppercase letter eye). В некоторых шрифтах отличить эти буквы от других ('1', '0') почти невозможно. Если очень хочется использовать 'l', пишите 'L'.

Имена пакетов и модулей.

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

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

Когда модуль, написанный на C/C++ имеет вспомогательный модуль на Python, предоставляющий более высокоуровневый интерфейс, модуль на C/C++ именуется с добавлением подчерка впереди (например _socket).

Имена классов.

Классы следует именовать используя CapWords стиль.

Можно использовать способ именования функций, если интерфейс документирован и используется в основном как вызываемый (callable).

Отметим, что есть отдельное соглашение для встроенных (builtin, относится скорее к ядру Python) имен: большинство встроенных имен это одиночные слова (или два слова используемые как одно), при этом CapWords используется только для имен исключений (exceptions) и встроенных констант.

Имена исключений.

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

Имена глобальных переменных.

Будем надеяться, что эти переменные предназначены для использования только внутри модуля. Правила именования такие же, как и для функций. Модули, предназначенные для использования в стиле «from M import *», должны использовать механизм «__all__» для предотвращения экспорта глобальных переменных. Или использовать старый способ с подчеркиванием в качестве префикса имени, что можно трактовать как индикацию таких переменных как «не публичные переменные модуля».

Имена функций надо писать в нижнем регистре, разделяя слова подчерками при необходимости улучшить читабельность. mixedCase допустим только в тех случаях, если такой стиль уже используется (например в threading.py), для сохранения обратной совместимости.

Аргументы функций и методов.

Всегда используйте «self» в качестве первого аргумента в методах инстанса.

Всегда используйте «cls» в качестве первого аргумента метода класса.

Если имена аргументов пересекаются с зарезервированными ключевыми словами, обычно лучше добавить один подчерк в конце имени, нежели использовать аббревиатуры или портить слово выбрасывая/заменяя буквы. В смысле, class_ лучше, чем clss. Возможно, лучше избегать таких коллизий используя синонимы.

Имена методов и переменных инстанса.

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

Используйте начальный подчерк для непубличных методов и переменных инстанса (экземпляра).

Чтобы обойти проблему одинаковых имен в подклассах, используйте два начальных подчерка для запуска правил искажения (mangling) имен в Python.

Такие имена Python заменяет на составные: _имя класса__имя метода. Если класс Foo содержит атрибут __a, его нельзя потрогать за Foo.__a, хотя настойчивые могут попробовать Foo._Foo__a. В целом, двойной начальный подчерк следует использовать только для избегания конфликта имен в классах, предназначенных быть подклассами.

Заметим: есть некоторые противоречия в использовании имен с двумя подчерками __names.

Константы обычно определены на уровне модуля и записаны в верхнем регистре, подчерки разделяют слова. Примеры: MAX_OVERFLOW, TOTAL.

Проектируя для наследования.

Всегда определяйтесь, методы класса и переменные инстанса (в общем – атрибуты) будут публичными или закрытыми. Если сомневаетесь, выбирайте закрытые. Легче их потом сделать открытыми, чем закрывать публичные атрибуты.

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

Мы здесь не используем термин «private», поскольку нет реально приватных атрибутов в Python.

Другая категория атрибутов, называемая в других языках «protected», это та, что является «API подкласса». Некоторые классы проектируются для того, чтобы от них наследовали, либо для расширения, либо для изменения аспектов поведения класса. Когда проектируете такой класс, позаботьтесь явным образом решить, какие атрибуты открыты, какие часть API подкласса и какие будут использованы только в базовом классе.

Учитывая вышеизложенное, вот руководства:

* Открытые (public) атрибуты не должны начинаться с подчеркивания.

* Если имена открытых атрибутов совпадают с зарезервированными ключевыми словами, добавьте к хвосту слова подчерк. Лучше так, чем аббревиатура или испорченное написание слова. Тем не менее, «cls» это предпочтительное название переменной или аргумента, про который известно, что это класс, особенно, если это первый аргумент в методе класса.

* Для простых атрибутов, представляющих данные, лучше открывать только имя атрибута, без сложных методов доступа/изменения. Не забывайте, Python дает легкий путь к будущим усовершенствованиям вашего кода, если вы обнаружите, что простой атрибут нуждается в более сложном поведении. В этом случае используйте свойства (properties) для упрятывания функциональности позади простого синтаксиса доступа к простому атрибуту.

Заметки:

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

* Если предполагается, что у класса будут подклассы (наследники) и есть атрибуты, которые вы не хотите давать наследникам в пользование, подумайте об использовании двойного подчеркивания вначале имени такого атрибута. Это вызовет name mangling, что приведет к появлению составного (из имени класса и имени атрибута) имени. Это помогает избежать коллизий имен в подклассах.

Заметки:

если подкласс использует, кроме совпадающего имени атрибута, совпадающее имя класса, name mangling не поможет. Name mungling может сделать отладку менее удобной, как и использование __getattr__(). Однако, алгоритм хорошо документирован и легко выполняется вручную. Не всем нравится name mangling. Постарайтесь не злоупотреблять.

Внешние и внутренние интерфейсы.

Любые гарантии обратной совместимости могут рассматриваться только для внешних (public) интерфейсов. Посему важно, чтобы пользователи могли четко различать внешние и внутренние интерфейсы (и избегать пользоваться внутренними).

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

Для лучшей поддержки интроспекции, в модулях следует явно объявлять имена их внешних интерфейсов используя атрибут __all__. Установка __all__ в пустой список показывает, что у модуля нет внешнего API.

Даже правильно записав __all__, внутренние интерфейсы (пакеты, модули, классы, функции, атрибуты, пр.) следует именовать с добавлением впереди подчерка.

Интерфейс рассматривается как внутренний, если он находится внутри внутреннего интерфейса.

Импортированные имена следует всегда рассматривать как детали реализации. Другие модули не должны полагаться на непрямой доступ к таким именам, пока они явно не документированы как часть API их модуля, как os.path или модуль __init__ открывающий функциональность из подмодулей пакета.

http://legacy.python.org/dev/peps/pep-0008/

http://docs.python-guide.org/en/latest/writing/style/

Слов много, но суть очень простая: отделяйте мух от котлет закрытые интерфейсы от открытых, используя подчерк перед именами для закрытых и записывая открытые в переменную __all__ модуля. Используйте стиль lowercase_name для именования всего, кроме пакетов (подчерк в имени пакета не нужно) и классов. Классы именуйте в стиле CamelCase. При желании использовать зарезервированное слово в качестве имени, добавьте в конце подчерк. Константы записывайте в стиле UPPER_CASE. Имейте в виду, что существует name mangling.

И будет вам щасте.

original post http://vasnake.blogspot.com/2014/09/pep-8-naming-conventions.html

Горка

Сегодня ездил тренироваться на автодром центрального офиса, Автошкола-онлайн. Полтора часа (почти полтора, минут 10 ушло на ожидания и «кофе-брейк») повторял упражнение «остановка и трогание на подъеме», ака горка, ака эстакада. В плане руления — ничего сложного. Вся сложность в одновременной и точной работе с педалями обоими ногами. Необходимо точно дозировать газ, 1200-1300 оборотов и, еще точнее дозировать сцепление. И ничего не перепутать.

Заглох всего два раза, других ошибок не было, вроде.

У Фольцваген поло движок — зверь. На холостых, 800 оборотов, в гору стартует и едет. В итоге, если освоить точную работу сцеплением, можно в горку стартовать не с ручника а с рабочего тормоза, потихоньку отпуская его после того, как сцепление стало схватывать. Мне так даже проще показалось.

Все, площадку прошел, завтра первое занятие «в городе».

original post http://vasnake.blogspot.com/2014/09/blog-post_15.html

PEP 8, Version Bookkeeping

Изучаем PEP 8 по частям. Часть 6, Version Bookkeeping.

Тут говорится о том, что:

Если вам очень надо, чтобы вашем коде находилось барахло, связанное с системой контроля версий (Subversion, CVS, RCS), записывайте это как-то так:

__version__ = "$Revision: e98737176f1d $"
# $Source$

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

http://legacy.python.org/dev/peps/pep-0008/

http://docs.python-guide.org/en/latest/writing/style/

Добавлю от себя, что рецепт по добавлению «барахла» из Git есть здесь:

http://stackoverflow.com/questions/5581722/how-can-i-rewrite-python-version-with-git

original post http://vasnake.blogspot.com/2014/09/pep-8-version-bookkeeping.html

Горка

Опять про контору «Автошкола-онлайн».

Проблема с эстакадой (ака горка, ака трогание на подъем), которая заключается в том, что на нашей площадке эстакады нет, решилась очень просто и, как водится, в уже привычном стиле Автошколы-онлайн.

Я приехал в центральный офис на Волгоградке, спросил в приемной — где у них можно найти человека отвечающего за оборудование площадок. Мне ответили — посмотрите в кабинете 7. В этом седьмом кабинете меня выслушали и предложили провести одно занятие не на моей площадке а на ихней, при конторе, на Волгоградке же. Выдали координаты инструктора и сказали — звони, договаривайся о времени и всё тебе будет.

На вопрос, а нет ли площадки с эстакадой поближе к моему Речному Вокзалу, последовал короткий перечень ебеней на разных окраинах дефолт-сити. Из чего я сделал вывод, что с площадками в школе полный швах. В смысле, с правильными площадками. Так, мне гарантировано еще одно посещение филиала у м. Волгоградский проспект.

Забавно, автодром на Волгоградке - треугольный:

http://maps.yandex.ru/?um=pqFUwsBpM7OBmP2aXsARHtDR3HFG93Ed&l=sat%2Cskl

original post http://vasnake.blogspot.com/2014/09/blog-post_11.html

Правильный инструктор

Автомобильное. Че та я торможу, давно надо было новый тег сделать. Хотя, умные люди говорят как-то так: не надо классифицировать, надо иметь толковый поиск.

Не знаю кому как, а мне (при обучении вождению) сложнее всего было освоить маневр «параллельная парковка задним ходом». Основная проблема — так угадать траекторию движения на завершающем этапе, чтобы вписаться в карман. То слишком близко к тротуару получается, то слишком близко к левой полосе.

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

В интернетах основная масса рекомендаций сводится к дрессировке обезьяны — видим вешку там — крутим руль, видим вешку здесь — крутим руль. Это все фигня и годится только для первоначального обучения, чтобы хоть как-то почувствовать маневр. Потом надо привыкать к правильному — планировать траекторию исходя из реальных условий.

Короче, нарыл я обучающие ролики от «Илья Ф», в которых доходчиво и, главное, правильно рассказано и показано, как выполнять упражение.

Ключевых моментов в параллельной парковке з.х. два.

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

Второй момент сложнее — после выравнивания колес, надо сдавать назад (под углом 45 град) до тех пор, пока ваша правая передняя фара не поравняется с левой задней фарой передней машины, что гарантирует безаварийный вьезд морды в карман. Но! При этом корма должна быть на достаточном расстоянии от тротуара, чтобы хватило места для завершающей дуги. Если это условие выполнено, завершается маневр без проблем, выкручиваем руль влево и сдаем назад.

Вот это комбо и надо тренировать.

В общем, смотрите ролик:

http://youtu.be/IY98K4HNq-I?list=UUCmewnOZRqdX4dgx_KC-UKQ

Дополнение.

Есть очень неплохой симулятор для обучения вождению, «City Car Driving», ранее известный как «3D Инструктор»

http://citycardriving.ru/home/ccd

Игрушка стоит всего 400 рублей (416, если учитывать комиссию Интеркассы).

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

Плюс, после отработки упражнений на площадке, можно (нужно!) покататься по виртуальному городу. И кататься до тех пор, пока для вас не будет проблемой рефлекторно отмечать все знаки, линии разметки, перемещения машин и пешеходов вокруг вас. И правильно реагировать на ситуацию. Короче, тренироваться на симуляторе нужно до тех пор, пока существует ощущение, что вы не успеваете отреагировать на какие-либо события на дороге. Плюс, вы должны замечать и помнить все знаки и ограничения движения от перекрестка до перекрестка. Опять же, рефлекторно.

Приятных тренировок.

original post http://vasnake.blogspot.com/2014/09/blog-post_8.html

PEP 8, Comments

Изучаем PEP 8 по частям. Часть 5, Comments.

Тут говорится о том, что:

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

Комментарии должны быть завершенными (полными) предложениями/высказываниями. Если комментарий это фраза или высказывание, его первое слово должно начинаться с большой буквы, если только это не идентификатор, начинающийся с маленькой буквы (ни в коем случае не меняйте написание идентификаторов!).

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

Следует ставить два пробела после завершающей фразу точки.

Когда пишете на английском языке, следуйте правилам языка (The Elements of Style, Fourth Edition by William Strunk Jr., E. B. White).

Кодеры не из англоязычных стран, записывайте комментарии на английском, можете писать на своем языке только если вы на 146% 120% уверены, что ваш код никогда не попадет на глаза человеку не владеющему вашим языком.

Блочные комментарии обычно относятся к коду следующему за ними и выровнены также как этот код. Каждая строка комментариев начинается с символа # и пробела, если только это не отбитый текст внутри комментария.

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

Пореже используйте инлайн комментарии.

Инлайновый комментарий это коммент в той же строке, что и выражение. Комментарий отделяется от выражения двумя пробелами минимум и символом # с последующим пробелом.

Инлайновые комментарии часто не нужны и даже отвлекающи, когда декларируют очевидное. Но иногда они полезны.

x = x + 1                 # Compensate for border

Соглашение по написанию хороших докстрингов увековечены в PEP 257.

* Записывайте докстринги для всех публичных модулей, функций, классов и методов. Докстринги не обязательны для непубличных методов, но следует иметь комментарии, описывающие суть метода. Такой комментарий должен быть на строке следующей за «def ...».

* Закрывающие докстринги кавычки «”””» для многостроковых докстрингов, должны быть на отдельной строке.

* Для одностроковых докстрингов располагайте закрывающие кавычки на той же строке, что и открывающие.

http://legacy.python.org/dev/peps/pep-0008/

http://docs.python-guide.org/en/latest/writing/style/

Без комментариев. Хотя, про два пробела между фразами я как-то не очень понимаю. Нафейхоа? А так, все настолько очевидно, что комментариев не требует :)

original post http://vasnake.blogspot.com/2014/09/pep-8-comments.html

Запреты

Автомобильное.

Небольшая справка для освежения памяти.

ПДД, перечисления где/когда запрещены:

• остановка
• стоянка
• разворот
• движение задним ходом
• обгон

Остановка запрещена

0. Там, где это запрещено знаками/разметкой «остановка запрещена», что очевидно.

1. На разделительной полосе.

2. На проезжей части, если есть обочина.

3. На левой стороне дорог. Исключение: в нас.пунктах на узких дорогах (или односторонних) без рельсов.

4. На тротуаре (даже на краю), если нет знака «место стоянки» с табличкой про тротуар. Буквально запрещена стоянка на тротуаре, но обычно это трактуется как остановка/стоянка на трот. Любым грузовикам на тротуар вообще хода нет.

5. На рельсах и рядом, если создается помеха трамваям. Конечно, на ж/д переездах нельзя останавливаться.

6. В тоннелях, на/под эстакадах, мостах, путепроводах. Исключение: можно останавливаться на эстакадах/мостах/путепроводах если есть 3 полосы и более на вашей половине дороги.

7. Где вы оставляете менее 3 метров ширины для проезда других ТС.

8. На пешеходных переходах и ближе 5 метров перед ними.

9. У опасных поворотов и перевалов, на проезжей части, при видимости менее 100 метров. На обочине — можно.

10. На перекрестках, точнее: на пересечении проезжих частей и ближе 5 метров от края пересечения. Исключение: т-образный перекресток, сплошная осевая на верхней палочке (буквы), можно встать напротив нижней палочки.

11. На полосе для велосипедистов.

12. Ближе 15 метров от остановок маршрутных ТС. Исключение — посадка/высадка пассажиров без создания помех маршрутным ТС.

13. В любых местах, где стоящее ТС закрывает знаки, сигналы, не дает вьехать/выехать; мешает движению пешеходов.

14. На автомагистралях (и дорогах для автомобилей) вне спец.площадок.

15. На выделенной для маршрутных ТС полосе. Исключение: посадка/высадка пассажиров не создавая помех.

16. На дороге в темноте или недостаточной видимости без включенных габаритов.

Стоянка запрещена

0. Там, где это запрещено знаками/разметкой «стоянка запрещена».

1. Там, где запрещена остановка.

2. На дороге вне нас.пункта (даже на обочине), если стоянка длительная (ночлег, к примеру).

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

4. Ближе 50 метров от железнодорожных переездов.

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

Положено ставить авто в один ряд, параллельно краю проезжей части, за исключением постановки в «кармане». Иначе нельзя.

Разворот запрещен

0. Там, где это запрещено знаками «разворот запрещен», знаками «движение только прямо/направо». Кстати, важно помнить, что знак «место разворота» и «зона разворота» запрещают поворот налево. Но не наоборот.

1. Не из крайнего положения на проезжей части (как и поворот). Если есть трамвайные пути слева и нет знаков «полосы...», надо заехать на попутные рельсы, не создавая помех трамваю. Исключение: на узкой проезжей части можно развернуться от правого края проезж.части.

2. На пешеходных переходах.

3. В/на/под тоннелях, мостах, путепроводах, эстакадах.

4. На железнодорожных переездаж.

5. Где видимость дороги меньше 100 метров в любую из сторон.

6. На остановках маршрутных ТС.

7. На автомагистралях и «дорогах для автомобилей».

8. На дорогах с односторонним движением (такого правила нет, но, очевидно, на встречку — нельзя).

При развороте и повороте налево положено пропускать встречный транспорт.

Движение задним ходом запрещено

1. Там, где запрещен разворот.

2. Если создаются помехи или опасность.

3. На перекрестках.

Обгон запрещен

0. Там, где это запрещено знаками «обгон запрещен».

1. На широких дорогах (4 и более полос).

2. Когда встречка не свободна, создаются помехи, опасность, нет возможности вернуться на свою полосу.

3. Переднее ТС обгоняет или объезжает, или подает сигнал левым поворотником.

4. Заднее ТС начало обгон.

5. На регулируемых перекрестках.

6. На нерегулируемых перекрестках на неглавной дороге.

7. На пешеходных переходах при наличии пешеходов.

8. На жел.дор. переездах и ближе 100 метров перед ними.

9. На/под/в тоннелях, мостах, путепроводах, эстакадах.

10. В конце подъема, на опасных поворотах и в других местах с ограниченной видимостью (х.з. на сколько метров ограничена, в ГОСТ есть таблица http://shkolazhizni.ru/archive/0/n-22085/).

В любых случаях нельзя обгонять спецмашины с синими-красными мигалками и крякалками.

http://avto-russia.ru/pdd/pdd_rf.html

http://pddmaster.ru/pdd/gde-zapreshhena-ostanovka-i-stoyanka.html

http://www.gibdd.ru/docs/pprf/314/

original post http://vasnake.blogspot.com/2014/09/blog-post_9.html