Обновить
5
Сергей Паньков@trapwalker

Backend, python

17
Подписчики
Отправить сообщение

Странная аналогия у вас. Пользоваться телеграммом-то не запрещалось никогда. А тут как раз запрещается превышать скорость. И виноват нарушитель.
Есть еще аргументы? Не спора ради, но просто я еще не слышал ни одного убедительного довода против камер.

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

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

Какая разница кто первый начал? Нужно решать проблему на всех фронтах сразу, а не ждать пока в головах там у кого-то (не у вас, конечно) наведётся порядок.
jerboa85 прав на 100%. Правила существуют чтобы их не нарушать. Если ненужный знак поставили, чтобы рубить бабло, то это отдельная проблема. Не дать срубить бабла жуликам можно легко — не нарушая указанное ограничение. Конечно с такими рубилами нужно бороться, нужно дать возможность оспорить установку любого знака. Но нет, лучше на говно изойти, что на нас добрых и пушистых паразиты деньги гребут! Да не нарушай ограничения, и никто не будет грести! Не будет денег — исчезнут и лишние знаки, и камеры не нужны станут.
Почему все люто-бешено борются за публикацию камер, а за публикацию всех знаков и ограничений в реальном времени — никто. А, ведь, это на самом деле может улучшить ситуацию на дорогах! Мало ли кто почему и какого знака не заметил. А от этого может зависеть чья-то жизнь. Нет, нам штрафы важнее. А что важнее чем бабло? Только на лишние 10 минут побыстрее влипнуть в пробку на полтора часа, которая, кстати, из-за таких же нарушителей, въехавших друг в друга или в столб.

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

Вот интересно, какого ж черта у нас специальные приборы предупреждают о камерах, а не об ограничениях?
Вот эта вот демагогия противников камер просто вызывает удивление.
— Какой смысл в камерах, если перед ними будут притормаживать а в других местах плевать на знаки?
— А не всегда же знак виден, иногда фура его закрывает или знак плохо виден не нужен или в кустах!
— Так давайте бороться с такими неправильными знаками, а не средствами контроля их соблюдения!


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


Почему бы просто не соблюдать ВСЕ знаки? А вместо радар-детекторов почему бы не использовать "знак-детекторы"? Это позволит избавиться от лишних штрафов, но и от лишних нечаянных нарушений ПДД?
А нарочные нарушения ПДД должны вести к неизбежному штрафу.

Интересно, когда в популярных IDE начнут появляться режимы сокрытия типизации в коде?
Вжух! — и код снова чист и прозрачен, но при этом мы продолжаем получать ворнинги в случае подозрительных махинаций с типами.

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

О, а я думал к чему это мицгол вспомнился, и тут вы со своим каментом.

╔══════ D:\temp ═════╗
║x Name   │ Name     ║
║…        │          ║
╟─────────┴──────────╢
║. Up     12.09.19 16║
╚ 0 (0/0) ═══ 147 G ═╝
Ещё есть аккорды же.
Можно стихи длинными аббревиатурами записывать.
Можно химические формулы юзать.
А есть еще топонимы всякие интересные
Ну что вы придираетесь? Автор, наверно, в первый раз что-то на питоне написал и уже хочет нас чему-нибудь полезному научить, а вы просто неблагодарный сноб=). Похвальный альтруизм должен вызывать у вас улыбку. Шутки шутками, а лучше так, чем <что-нибудь плохое> в <неподобающее для этого время и месте> делать.
Это безусловно. Я просто попытался понять мотивацию автора в именовании методов. Это не делает идею хорошей.
Вот кто-то сейчас после этого поста чертыхнулся и добавил-таки в базу паролей все шахматные дебюты (чтоб не забыть как в прошлый раз). И с этого момента плохой идее будет любой шахматный дебют разумной длины использовать.
Наверно, может быть, в учебных целях?..
Но тут я с вами согласен. Мне кажется автору стоило сделать еще один шаг и реализовать правильную библиотеку. А в идеале — вообще опубликовать на гитхабе как полностью оформленную библиотеку с тестами. Можно даже как отдельную статью сделать и это новичкам принесёт куда больше практической пользы, чем даже знакомство с этой структурой данных.
Не помешали бы также тесты производительности по сравнению с штатными списком и деком.
Ну и пару придирок вдогонку:
  • автору стоило использовать __slots__
  • имеет смысл сделать «ящики» неизменяемыми (immutable), ла еще и на основе typing.NamedTuple. Будет боле по-питоновски.
  • как выше уже намекнули, хорошо бы использовать «магические» методы
  • Не нужно лениться делать нормальные __repr__ и __init__
  • полезно оформить в пакет, прописать зависимости от версии питона,
  • сделать тесты
  • сделать итератор по элементам
  • хранить в контейнере ссылку на последний элемент тоже. Это O(1) по памяти, но делает вставку в конец тоже O(1), а сейчас O(N). Как-то нелогично же.
  • Для собственного развития автора реализовать бы такую же по свойствам структуру на основе словаря, но с бонусом в O(1) для вставки в любое место связного списка. У вас-то сейчас O(N)/
  • Можно сделать ту же структуру на основе бинарного дерева. Посравнивать производительность получившихся структур данных.

Со всем этим багажом автора с руками оторвёт любая компания, которая набирает джунов.
elif re.search(r'\ ', call):
    webbrowser.open_new_tab('https://yandex.ru/search/?text='+call)
else:
    webbrowser.open_new_tab('https://yandex.ru/search/?text=' + call)


Эти две ветки совершенно идентичны, а следовательно можно было бы заменить все на:
import webbrowser
import re
call = input('Введите ссылку или запрос: ')
if re.search(r'\.', call):
    webbrowser.open_new_tab('https://' + call)
else:
    webbrowser.open_new_tab('https://yandex.ru/search/?text=' + call)

И ничего не поменяется. Или автор просто запутался в том. что хотел сделать.
Как выше отметили уже, регулярные выражения не нужны для проверки вхождения подстроки в строку:
import webbrowser
call = input('Введите ссылку или запрос: ')
if '.' in call:
    webbrowser.open_new_tab('https://' + call)
else:
    webbrowser.open_new_tab('https://yandex.ru/search/?text=' + call)

В любом случае детектировать URL исключительно по точке — плохая идея.
сорок тысяч обезьян в ж...
А ваш этот сервис локально в закрытом контуре можно запустить? Дорого получится?
Не думали продавать аппаратные решения в виде сертифицированных по чем только можно маленьких железных серверов с вашей дадатой внутри? Купил поставил и знай себе только заливай обновления время от времени.
А можно для протяженных объектов строить упрощенную геометрию и хранить её для детальной фильтрации.
Ещё можно строить индекс на основе дерева квадрантов, при этом протяженные объекты закреплять за теми квадрантами, в которые объект помещается полностью.
Можно индекс на основе того же дерева квадрантов строить для первичного грубого поиска, тогда все протяженные объекты можно «рендерить» на грубую растровую карту в виде битовых «примесей» к пикселям, на которые объект грубо накладывается.
Огромное количество разных способов оптимизации этой задачи.
Долго думал что вы хотели этим сказать:
Низкое качество свзано с использованием Matplotlib, за то там видны размеры по
осям.

Так и не понял.
Говоря о качестве вы имеете в виду «ступеньки», которые неизбежно появились при чересстрочном разрезании изображения?
При таком «ресайзе» произошла потеря 3/4 растровой информации. Для качественного уменьшения размеров следовало бы каждый пиксель результирующего изображения вычислять усреднением четырёх соответствующих пикселей исходной картинки.
Для этого, кстати, можно было попиксельно сложить и поделить на 4 все четыре получившихся среза.

Информация

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