Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
0
# Python 2.7
import cgi
print(cgi.parse_qs('a=bagor;+kakoi'))
# {'a': ['bagor']}
# Python 3.7.3
import urllib.parse
print(urllib.parse.parse_qs('a=bagor;+kakoi'))
# {'a': ['bagor']}
# Python 3.9.10
import urllib.parse
print(urllib.parse.parse_qs('a=bagor;+kakoi'))
# {'a': ['bagor; kakoi']}
Что, блядь, это за хуета???
Переводил программу на Python3 и пол дня потратил в попытках понять почему блядь тесты сломались.
Какой-то петух завязался, на ';' сепаратор, который обрезается.
https://docs.python.org/3/library/urllib.parse.html
Changed in version 3.10: Added separator parameter with the default value of &. Python versions earlier than Python 3.10 allowed using both ; and & as query parameter separator. This has been changed to allow only a single separator key, with & as the default separator.
И у меня не 3.10, но да похуй.
Как мне теперь закостылять это говно, не меняя данные?
Запостил: 
3_dar,
03 Февраля 2022
Follow us!
Либо перед тем, как парсить, определяй, каким сепаратором пользуется питух.
On the second thought это хотя смотря в какую сторону это сепаратизм
2: объявить, что в связи с учащением обнаружения уязвимостей, связанных с недостаточно строгой обработке входных данных, для безопасности разделители кроме & не принимаются
3: ???????
4: PROFIT
Ваше первое задание. Есть код
и код
итд
нужно добавить цвет глаз
Храни кортеж неопределенного заранее размера
Тут много вариантов:
1. Обрезать запрос по точке с запятой до передачи в parse_qs.
2. Обрезать каждое значение по точке с запятой после разбора parse_qs.
3. Использовать два яруса: делить строку на части по точке с запятой, потом каждую подстроку передавать в parse_qs либо наоборот, делить строку на части по амперсанду, потом каждую часть передавать в parse_qs, передав последним аргументом точку с запятой.
Невозможно решить задачу, если у неё нет постановки.
Я так и сделал, да.
Это не продакшен код, поэтому так костылять можно.
Совместимость не 100% по сравнению с replace(';', '&').
У тебя есть шанс стать этим психопатом! Этот случай может войти в легенды, его будут приводить в пример, и пугать тобой каждого говнокодера!
5 лет прошло... Ну и что? Это не срок. Людей и после 50 лет находят, а он же не в джунглях исчез.
Допустим, сполежуй-говноед построил дом и говна и соплей.
Дом стоял, пока ты рядом с ним не хлопнул в ладоши.
Но ты хлопнул, и дом упал.
Теперь соплежуй-говноед -- молодец. Он построил дом.
А ты мудак, потому что ты его сломал.
Хорошие дома не падают от хлопков в ладоши, но кого это ебет?
Наказание нашло их спустя более 50 лет.
Представь, что бы с ними сделали, если бы они были живыми?
Погугли "Железнодорожная катастрофа под Уфой", когда долбоёбы газом целую низину наполнили, и ни один долбоёб и глазом не моргнул. Там вроде никого особо не посадили нормально
А всё от недостаточного количества ритуальных сожжений говнокодеров.
Хочу заметить, что исходя из исторических фактов, после показательного выпиливания, выпиленых молодцами не называют. А если кто и называет, то тут есть корреляция между нипи, и выпиленными во вторую очередь.
А точка с запятой где используется? Только при сборке запроса вручную? Видел эту хуету на сайтах, но не могу понять, откуда она берётся.
Ничего, что я читаю?
The enctype and formenctype content attributes are enumerated attributes with the following keywords and states:
• The "application/x-www-form-urlencoded" keyword and corresponding state.
• The "multipart/form-data" keyword and corresponding state.
• The "text/plain" keyword and corresponding state.
The enctype attribute's invalid value default and missing value default are both the application/x-www-form-urlencoded state.
Первый формат описан тут:
https://url.spec.whatwg.org/#application/x-www-form-urlencoded
Парсинг описан так: «Let sequences be the result of splitting input on 0x26 (&).»
Второй формат описан тут: https://datatracker.ietf.org/doc/html/rfc7578
Он громоздкий (с мимими-boundary), поэтому обычно используется только для отправки файлов.
Что за формат text/plain, я не знаю. Нужно почитать повнимательнее.
https://www.w3.org/TR/html4/interact/forms.html#h-17.13.3.2
Либо application/x-www-form-urlencoded с разделителем &, либо multipart/form-data с мимими-boundary.
Ломающие изменения в минорных версиях всегда плохо заканчиваются.
Могли бы собрать всё что они хотят сломать в кучу и выпустить Python 4.
А потом ещё лет 10 переходить на него с тройки. Стало бы лучше?
Руби в 1.9 тоже подобной хуйнёй стало страдать. И где теперь руби?
* Тормознутость
* Плохое реноме после ухода с руби на скалку какого-то вебговна (твитера штоле)
* Сложность, и наличие магии
* Непопулярность у гуглов-яндексов-phd (в отличие от пиздона)
Думаю, что уход со сцены языка -- сложное явление, имеющее множество причин, и так просто его не объяснить. Это из серии "почему одни страны богатые, а другие бедные?"
Нету простого ответа.
И кстати. Вон, в Perl никто совместимость не ломал, а что с ним случилось?
Нинужно никому кроме кегданов.
>уход со сцены языка
Так сказал, будто бы он был на сцене.
Ты о Яибу или о Пёрл?
Яибу и рельса научили вебмакак континиус деливери, CI и конфигурейшен эз коду.
Он был королем веб разработки. Года два.
Перл был (а в тяжелых случаях) и остается пламбер ленгвиджем прыщей и прочих юниксов, ну и он был дефакто скриптухой и вебCGIговном в промежутке 1996-2001 где-то
Хуй-ня. Сказать что PHPшники научили мир монорепам и stateless-серверам будет и то большей правдой.
Яибу — язык одного фреймворка с парой удачных идей, которые очень быстро реплицировали.
> Он был королем веб разработки. Года два.
Король Чуханов.
Разъёб Яибу-мрази.
Сектант: Прастити, а переполнениестека.ком написано на Яибу?
.NETчики: Пошёл вон отсюда, гадина ебучая!
Подумал, что это файка Маца. Перехожу по ссылке, а там какой-то пидор.
Но при этом Яибушник выставил себя анскильным кретином, который хотел дешевой пропаганды чтобы похвалить своё болото. А в итоге ему объяснили, что рельсоподелка никому не нужна.
Типа ты известный чувак, книжки по рельсам пилишь, а своих клиентов так и не выучил.
Кому плохо в крестах или перле, тот пусть покушает наш наколенный DSL для CI, нихуя никем никогда не документированный, без возможсности проверять изменения локально (только на CI) где в случае ошибки билд у тебя всё равно зеленый, но в дебрях лога пара мегабайт XMLя с ошибками высирается.
Вот это треш, а не плюсы с перлами
А я против нахрюков на Malbolge, кстати. Почти всё, с чем я сталкивался в Malbolge, было документировано, и имело какой-то смысл, хотя бы исторический.
А я против нахрюков на JS, кстати. Почти всё, с чем я сталкивался в JS, было документировано, и имело какой-то смысл, хотя бы исторический.
В "C++" тоже многие вещи смысла не имеют.
Да и всегда можно заявить, что в этом есть некий "исторический смысл"
Например, какой смысл не давать возможность определять свойство short-circuit для перегруженных "||", "&&" операторов?
Определить множество значений, на которых цепочка из "&&", "||" прерывается, и дальше ничего не вычисляется
А если мне надо именно операции "&&" и "||" перегружать, чтобы от них были побочные эффекты в зависимости от типа? Ну например в целях логирования и отладки какой-то хуйни
Или пусть && лямбды-продолжения принимает.
Я не знаю как это красиво сделать.
Делать мне больше нехуй
> Я не знаю как это красиво сделать.
Поэтому я против крестов
Например, почему в "std::vector" нет "push_front", "emplace_front" и "pop_front", но при этом есть "emplace", "insert" и "erase"?
В случае insert ты явно просишь какую-то хуйню сделать, и тут уж ты сам себе злобный.
Точно так же, как в list нельзя обратиться по индексу.
Я как раз тут согласен с плюсами. Джавка со своим List куда хуже.
А добавлять/удалять в середину комильфо? Если б не было и "emplace", "insert" и "erase", у меня б вопроса не возникало.
А ты бы хотел, чтобы был заранее неоптимальный метод, который к тому же легко эмулировать через другой, более общий?
Ну блядь, если добавлять в середину официально можно, на кой хер не разрешать добавлять в голову? Не один ли хер? Логика тут где?
Так ведь можно.
vec.insert(vec.begin(), pitux)
> vec.insert(vec.begin(), pitux)
Можно-то можно, но мы тут вроде говорим о какой-то логичности. Какая логика не давать метод добавления сразу в голову, если вставлять в середину один хрен можно?
insert -- это универсальный метод. Его нельзя выкинуть т.к. многие операции над вектором станут невозможными без ручной ёбли.
А вот push_back и push_front -- частные случаи, которые вполне так выражаются через insert. И push_back там исключительно ради удобства и оптимизации. На полноту интерфейса он не влияет.
Вторым?
Предпоследним?
Действительно. Давайте тогда уберем все эти методы вставки в начало и в конец, и оставим только методы вставки хуй пойми куда. А компилятор там как-нибудь пусть соптимизирует
ДАвайте.
Не существует метода вставки в начало у массива. Убрали
И в конец тоже уберите. И для всяких связных списков уберите в начало и в конец
А поскольку вектор растет с нахлестом (в джаве, думаю и в С++ так) имея впереди себя немного свободного места, то обычно это легко.
Ну а начало и конец для связанных списков отлично реализуется, для них вообще нет разницы куда вставлять
В начало тоже легкая, если там есть местечко в адресном пространстве. Хотя это конечно зависит от реализации аллокатора на хипе
Тут можно спросить, а зачем листу метод для добавления в голову, почему не сделать было одинаково insert и там, и там?
Вангую, что добавление в листа компилятор может как-то оптимизировать.
В целом, кресты подталкивают тебя НЕ делать заведомо хуевых вещей, но если хочешь, то можно.
Точно так же я не могу получить Nый элемент листа, но через итератор со счетчиком могу же.
То есть я явно говорю: "сделай неоптимально, я беру на себя ответственность"
Т.е. надо заставить программиста писать какие-то лишние буковки, если ему надо вставлять в голову массива? Ну так почему б тогда и insert аналогичным образом не усложнить? Пусть лишние буковки понапишет, ну типа увеличит размер вектора, сдвинет кусок вектора руками после места вставки, и потом вставляет
тогда не выполнится правило "но если хочешь, то можно".
Зачем добавлять метод, который лучше никогда не использовать? Для чего он?
insert не обязательно же плохой, если ты добавляешь в хвост, то наверное компилятор может как-то остальной массив не трогать.
push_front/pop_front тоже не обязательно плохой, если вектора малого размера
Это правда. Да и на современных процах подвинуть массив не так уж и страшно, всё железо же на массивы заточено.
Однако в общем случае это не так
В общем случае и insert плохой.
Да, именно.
> Ну так почему б тогда и insert аналогичным образом не усложнить?
Зачем? Почему бы не добавить метод, который шлет сообщение в тикток? Потому что он не нужен.
И этот метод тоже не нужен
А зачем тогда push_front не добавить? Ну т.е. почему ты против усложнения insert но не против усложнения push_front?
Какой смысл добавлять push_front у вектора?
Минус я вижу сразу: усложнение интерфейса.
А плюс какой? Экономия пяти байт по сравнению с вызовом insert для того 1% случаев, когда кто-то захочет им пользоваться?
Следуя такой логике, и метода insert у вектора быть не должно. А он есть
push_front ничего бы не дал по сравнению с insert, потому что его трудно оптимизировать
Можно спросить "а зачем push_front у листа? Почему не оставить один insert?"
Как я написал выше, я предполоагаю, что его можно как-то оптимизироовать по сравнению с более обшим insert.
Алсо, им пользуются намного чаще, чем вставляют в голову массива, так что экономия пол строчки тут дает выгоду
Тогда не вижу проблемы добавить и push_front
> push_front ничего бы не дал по сравнению с insert, потому что его трудно оптимизировать
Почему ты так решил? Это зависит от того, как реализована динамическая память, можем ли мы выделить память сразу перед этим самым вектором и как-то это заюзать. Ну т.е. это явно проще, чем insert куда-то в середину
А видишь ли ты проблему с добавлением метода для отправки видео в тик-ток?
>Это зависит от того, как реализована динамическая память, можем ли мы выделить память сразу перед этим самым вектором
Ты предлагаешь перед массивом сделать специальный гэп? А какой?
Специально можно никакого гэпа не делать, это уж как повезет. Если в виртуальном адресном пространстве перед вектором нет места, можно тупо mremap-нуть страницу с вектором в другое место, и сразу перед ним mmap-нуть еще страницу, и туда насрать.
А есть реальные замеры на каком размере вектора это становится эффективнее передвигания элементов?
Хотя раз в тыщу элементов наверное норм.
Это же блядский ад получается. А если вставлять в голову массива, то такая ситуация будет еще чаще?
Ну если со всеми этими "объектами" нужно что-то сделать при изменении их адреса, то естественно надо для них какую-то хуйню вызывать. А как ты хотел?
Или вопрос "надо ли тебе руками специально что-то вызывать, или оно само разберется"?
Просто сам по себе realloc, а тем более ремап, довольно спорные вещи. Гарантированно realloc помогает разве что с одним потоком и последнему блоку. А у ремапа гранулярность большая и он не везде есть. Сложно оптимизировать алгоритмы под них.
По идее же компилятор это может сделать не нарушив стандарт
realloc/remap на них тоже бы прокатили если бы не прокрустово ложе крестовых "аллокаторов".
Даже если аллокатор держит "большие" объекты в отдельных страничках, там не так уж много места для роста.
Про deque я знаю, только это и для vector можно быстро реализовать. Куда быстрее вставки в середину для жирного массива
Почему бы и нет? Но учитывая что комитет mremap() не осилил, это вряд ли
Сделай свою либу с такими контейнерами, может популярной станет. Или в буст втащи.
Ну, оверхед ведь и завязка на платформу. И далеко не каждому вектору это нужно. Т.е. это узкоспециализированный контейнер для какой-то конкретной задачи, где он соревнуется скорее с деком, чем с вектором.
Кстати, почему в крестоговне нет такого варианта вектора, которому можно делать push_front но нельзя push_back? Т.е. чтобы он рос от старших адресов к младшим.
А что плохого в том, чтобы привернуть быстрый pop_front для std::vector? Типа там будет лишняя говнопроверка "тут честный вектор, или такой вектор, где будут пустоты вначале, и поэтому надо как-то по особому его освобождать, ведь указатель на нулевой элемент такого вектора не совпадает с началом куска памяти" А есть ли некий сверхбыстрый метод конвертирования std::vector в std::deque?
вставки в начало/конец за O(1)
можно в критических местах подмассивы соединять, или разъединять например.
Это называется "unrolled linked list"
Ну и что касается std::deque, там не гарантируется непрерывность хуйни:
https://en.cppreference.com/w/cpp/container/deque
> As opposed to std::vector, the elements of a deque are not stored contiguously: typical implementations use a sequence of individually allocated fixed-size arrays, with additional bookkeeping, which means indexed access to deque must perform two pointer dereferences, compared to vector's indexed access which performs only one.
Что уже по-сути говно для некоторых задач. Как вариант можно было б сделать что-то типа std::vector с запасом в начале для запушивания в голову
В том, что чтоб пушить в массив за O(1), его делить на два или более куска совершенно не нужно. Условие непрерывности куска памяти вполне можно соблюсти
А зачем ещё нужна эффективная вставка в начало вектора?
Но вообще если достаточно много запаса вначале и в конце хуйни сделать, перемещения можно уменьшить
Он ведь тоже не такой дешёвый, как кажется.
TLB чистить вилкой. Фрагментация и оверхед пейджтейблов растёт если неплотно странички выделять. Давление на TLB растёт опять же.
З.Ы. А, можно и всем зафорсить автоматом. Только нахуй это надо?
mmap(2)
MAP_HUGETLB (since Linux 2.6.32)
VirtualAlloc
MEM_LARGE_PAGES
но в случае спермы надо еще надо попросить ``SeLockMemoryPrivilege ``
а на прыщах вроде ничего не нада
аллокатору будет чуть просторнее
А форсом только всё испортить можно. Вот захочет он из середины размапать. И придётся ядру расщеплять страницу.
Так хрен бы с ним, даже эффективного удаления из начала вектора нет. А зачем нужно эффективно удалять из начала и эффективно вставлять в конец - это называется "очередь". И из очереди мне может быть нужно читать большие непрерывные куски хуйни, чтобы она не была разбросана хер пойми как
Догадываешься, почему?
[color=auto]Потому что кресты - говно, где неосилили заюзать realloc() и mremap(), очевидно.[/color]
Кстати, почему в крестах нет класса кольцевого буфера, но зато есть функция Бесселя? Функция Бесселя нужнее?
Если в стдлибе есть всякие мапы и связные списки, удивительно видеть там отсутствие такой банальной хрени, как кольцевой буфер
А почему функция Бесселя нужна - тоже объяснят?
Потому что «функция Бесселя» нужна только «ма-те-ма-ти-кам». «Ма-те-ма-ти-ки» не хотят программировать, они хотят взять готовые функции и заниматься «ма-те-ма-ти-кой».
А «кольцевой буфер» нужен только «микроконтроллерщикам». «Микроконтроллерщикам» же что не давай — они всё равно скажут, у них в «микроконтроллерах» такой хуйни нет, и будут пилить свой велосипед на сишке.
Поэтому и смысла нет добавлять в «STL» «кольцевой буфер».
> Что уже по-сути говно для некоторых задач
Так кольцевой буфер тоже нихуя не гарантируент непрерывность хуйни, нет?
Кот, тко, отк, кот?
Всегда только один бит меняется, нету резких перепадов. Собственно поэтому его на крутилках-энкодерах и юзают.
На самом деле разрыв всё равно будет виден, потому что в какой-то момент N+1 станет больше, чем N
А ты отбрось позиционное исчисление, представь, что это просто 3 независимых бита. Можешь даже переставить биты местами или инвертировать и всё продолжит работать.
И контроллер памяти сосент память последовательно (в рамках одного ранка). Мир-то последовательный, его не наебешь
Во-первых, в пределах одной строчки DRAM можно считай что в любом порядке слова забирать.
Во-вторых, насколько помню, продвинутые контроллеры эту фичу юзают и в первую очередь запрашивают именно те слова, которые нужны прямо сейчас, а потом уже остатки кешлайна подтягивают.
Т.е. даже DRAM обходить кодом грея вполне возможно, главное чтобы "медленные" биты попали на строчки (в любом порядке), а "быстрые" на колонки (тоже в любом порядке).
А SRAM и подавно. И джвухпортовую SRAM с адресацией по Грею используют на практике для кольцевых буферов, стоящих на границе между джвумя частотными доменами.
Если ты влез целиком в кеш, то это читерство, и тут понятно, что работать будет.
DRAM тоже можно сделать "двухпортовым" если память двухканальная, и тогда когда у тебя кончится один канал, ты начнешь как раз читать из другого, а он уже перезаряжен, и открыт..
Для "зацикленности" этого как бы и не нужно. Ну т.е. достаточно перегрузить операции, чтоб вместо "ptr+a" делалось "start_ptr+((ptr-start_ptr+a)%sz)"
Только memcpy надо на будет на две части разрезать
А где я утверждал, что кольцевой буфер гарантирует какую-то там непрерывность?
Т.е. если мы читаем или пишем около хвоста такого буфера, не нужно делать специальной хуйни "этот кусок берем от головы, а вот этот - от хвоста". Но это конечно тоже не означает никакой непрерывности
Единообразие методов у разных контейнеров.
А зачем такое единообразие, если паттерны использования их ОБЫЧНО различны?
Если уж человек берет кресты, то явно он упарывается по перфыормансу (иначе писал бы на пхп) а значит ему не всё равно, вектор тут или лист
Для тех случаев, когда они НЕ различны
Часто ли вообще в крестах ты оказываешься в ситуации, что тебе пофиг что там: лист или массив?
ХЗ. Ну иногда оказываюсь. Например, если мне нужно найти максимальный элемент в массиве или листе, мне будет явно пофиг
Ну иногда нужно ведь... А push_back добавили как оптимизацию для того случая, который можно сделать чуть-чуть быстрее чем общий случай через insert(). Если бы конпелятор сам догадался и сократил проверки, он был бы нинужен.
Собрав статью критики в моде, победителей присвоили роль девочек и чекистов — ведь сегодня нельзя не удивляться, когда статья написана крутыми девочками и чекистами.
Но девочки и чекисты, как и все говно моде нашего времени, населяются болезнью. И мы должны спорить о том, выйдет ли хороший образ жизни и построиться ли такое социальное общество как его выбор хорошего образа жизни для нашей повседневной жизни и тесно общение в обществе хорошего образа жизни.
> Сложность, и наличие магии
Кому-то было слишком легко и недостаточно магии?
На самом деле там соснул перформанс. У Руби действительно очень много хуйни делалось в рантайме, а джита не было, и потому MRI из всей скриптушни был самым медленным
Может быть прогретый JIT JVM всё таки лучше MRI: Руби вообще не делался изначально с прицелом на перформанс, первой задачей его было "написать что угодно в малое количество строк", и Мац наверное охуел, когда DHH притащил его в веб, и поставил на рельсы.
JVM правда тоже не делался до хотспота, но он случился давно.
Впрочем, может соснули у них именно рельсы, а не сам руби, надо гуглить.
Проблема в том что скала такое говнище, что сливает и так не очень быстрой Йаже раз в 5-10. Это происходит на той же JVM с тем же Хосподом.
Из-за всяких функциональных примочек, лямбд, ленивостей и прочего ФП-говна, под которое JVM не затачивалась.
https://www.overops.com/wp-content/uploads/2020/09/functional.benchmark.png
А Скала и «компилируется»* раз в 10 дольше Жовы, из-за тонн синтаксиального сахара и свистопеределок, которые нужно распарсить.
И работает раз в 5-10 медленее.
* Хотя мы знаем что там и никакой оптимизирующей компиляции толком ни жавак, ни скалак не делают.
Они просто и без затей транслируют в байт-код жвм. А оптимизации делает Хотстоп
долго типы выводит, долго ищет эксиеншн методы
Хорошо помню как фп-отбросы форсили эту заедуху лет 10 назад: Яжа как Какскель, Яже как Каксель.
На Хаскеле эта никчёмная мразь не могли найти себе работу, а очень хотелось.
Вот мразь и выдумала бездарную поделку. Ну и ладно бы. Но мразь не просто сама обмазалась говном, она назойливо начала советовать всем окружающим поступить также.
У Хаскеля хотя бы была цельность языка и свежесть концепций. Да и компилится он быстрее.
Въебал плюс.
Компилируется долго, зато работает медленно.
А с другой стороны они расставляют грабли и после обновления код начинает ломаться в неожиданных местах без каких-либо предупреждений.
В итоге надо обновляться в цейтноте и фиксить баги из-за этих сраных идеалистов, а не заниматься своей задачей.
В случае с питоном 4 параллельно жили бы 2 ветки. Да 10 лет, да с анальной болью. Но это не издевательство над программистом.
Final regular bugfix release with binary installers: 3.9.12: Monday, 2022-05-16.
After that, it is expected that security updates (source only) will be released until 5 years after the release of 3.9 final, so until approximately October 2025.
Что и требовалось доказать. Особенно весело будет на винде.
Самое гнусное что всё больше системных либ перепиливают свои системы сборки на meson.
Причём новые его версии.
А meson опчему-то не хочет работать на 3.4, 3.5, 3.6, итд ему нужны всё более и более новые версии Притона.
Потому будут багры как с браузерами и придётся угадывать версию это параши:
на слишком старом не работает, а в новом уже всё сломано
Пиздец просто. Скоро начнём вспоминать кошмарный autotools с теплотой и любовью.
Потому что поддержать несколько версий при такой стабильной стандартной либе -- это на грани фантастики?
Хуй с ним, можно в докере собирать.
mesa-драйвер для видеокарты??
Если во внешней системе у либ немного другие ABI, то будет пиздец.
>А что не так?
Было:
хочешь собрать руками софт: поставил autotools/cmake и радуешься.
Стало:
ставишь docker
ставишь python
ставишь meson
...
ПИРДОЛЬ
Только проблема в том что собирая одним докером mesa под разные платформы, и разные дистры, с разными версиями либ, она нахуй развалится.
То есть придётся каждому пилить сборку в докере "падсибя".
Три!!! У меня в дистре python до сих пор резолвится в двойку.
>> с анальной болью
>> не издевательство над программистом
Мсье знает толк.
Минорная это когда 3.10.1 на 3.10.2 обнвлябля
Вторая цифра -- минорная версия, можно добавлять новые фичи, но не ломать старые.
Третья цифра -- номер багфикса, должна быть совместима и вперёд и назад.
У питонят другое понимание этих циферок?
влегкую код из 3.4 может сломаться в 3.9. Свинтаксис не, а стандартная либа -- да
Т.е. мне надо при выходе каждой "мажорной" версии тройки прочитать весь чейнжлог и пофиксить в моём коде все места, которые могут поломаться? Да, с учётом динамичности языка и отсутствия каких-либо инструментов для этого.
Замечательная работа, если больше нечем заняться. Сизиф со своим камнем нервно курит в сторонке.
https://docs.python.org/3/whatsnew/3.8.html#deprecated
>he asyncio.coroutine() decorator is deprecated and will be removed in version 3.10.
The function platform.popen() has been removed, after having been deprecated since Python 3.3: use os.popen() instead. (Contributed by Victor Stinner in bpo-35345.)
Removed the doctype() method of XMLParser. (Contributed by Serhiy Storchaka in bpo-29209.)
Видимо мне надо чаще пить смузи и общаться в твиттере.
Но будем честны: в достаточно крупном коммерческом проекте есть много интересных дел, более интересных, чем менять "petuhz()" на "kurochka()" потому, что петухза задепрекейтили
Ну это примерно как опсосы предупреждают про изменения тарифа заранее. Где-то в жопе своего сайта, который надо не забывать читать.
то есть тесты у нас падают за пять лет до того, как упадет реальный код
депрекейт вызывает ворнинг
Хотя... вот эту хуйню про сепараторы никакие ворнинги не спасут. Тут надо было удалять старую функцию и вводить новую, а не тупо портить семантику.
https://docs.python.org/3/library/warnings.html
>Как включить?
https://docs.python.org/3/using/cmdline.html#cmdoption-W
>портить семантику
тут да
Торвальдс_и_меммов
Правда небезопасность этих функций была признана еще в 90-е вроде, и ключик вот есть
Пофиксил
Так-то да: даже книжку про программирование под виндавоз Пецольд на C#/CLR перевел. Ну а Рихтер свой Windows via C/C++ на CLR via C# перевел еще раньше
Дык он же просто ворнинг выдаёт.
Но да, _CRT_SECURE_NO_WARNINGS — если память не подводит — приходится прописывать в каждом проекте.
Но из-за нестандартности и непереносимости юзать их совсем не хочется.
Подтверждаю.
А нахуя? Если мне надо проверить, имею ли я право скопировать столько-то байтиков оттуда туда, я просто напишу проверку через if()
В любом случае такая говнообертка пишется элементарно
И вот нахуя мне тут нужно писать memcpy_s() и указывать размеры входного и выходного буфера? Это абсолютно бессмысленные и нахуй не нужные в этом случае говнопроверки
https://docs.microsoft.com/en-us/cpp/c-runtime-library/reference/memcpy-s-wmemcpy-s?view=msvc-170х
Нет. Только размер выходного и количество копируемых байт.
https://developer.mozilla.org/ru/docs/Web/HTML/Element/Input/range
https://developer.mozilla.org/ru/docs/Web/HTML/Element/Input/range
вон, даже в девятом IE не работает.
Карт два типа: client-side (когда нарезаешь фигуры в HTML) и server-side (когда сервер обрабатывает координаты).
Server-side image map отправляет две координаты, разделённые запятой.
В принципе, можно кнопки и вообще интерфейс какой угодно сложной формы рисовать, а на сервере разбирать, куда кликнули. Но без всяких подсветок при наведении и прочих плюшек, это оказалось нахрен не нужным.
Проект решил заменить голого планшета на производство компьютеров, которые могут распознавать фразы и продукты и отправлять стихи каждому участнику раз в неделю. Без участия стариков и полицейских, проверяющих правоохранительные органы, каждый мог почитать стихи без контроля и внести обновления в текст. Реализация сделала это проще и быстрее. Помимо стихов, большие компьютеры также распознают и выдают последовательно обратно запись любого пользователя в сеть для посещения места сооб�щения, предоставляя доступ к многим экспертизам и декоммуникациям пользователей. Это можно сделать так, чтобы пользователи могли увидеть прогресс за один день, а средства слежения позволили задержать неисправимого по причине бессовести. Эта система распределилась по всему миру через несколько недель.
https://govnokod.ru/27914#comment756889
Похоже там засели какие-то неадекваты, решившие всё развалить нахуй.
Мне в общем насрать, но ужасает что сборка всех сишных либ в последнее время переводится на сраный meson.
Changed in version 3.9.2: Added separator parameter with the default value of &. Python versions earlier than Python 3.9.2 allowed using both ; and & as query parameter separator. This has been changed to allow only a single separator key, with & as the default separator.
Т.е. это не опечатка, а намеренная попытка скрыть факты и замести своё говно под ковёр.
When the attacker can separate query parameters using a semicolon (;), they can cause a difference in the interpretation of the request between the proxy (running with default configuration) and the server.
Какой же пиздец всё-таки этот веб... Устроили проблему на ровном месте.
Уёб-мразь добровольно села наBottle.
Я теперь понял что питонист Сёма имел ввиду когда говорил сесть набутылку.
https://snyk.io/vuln/SNYK-PYTHON-BOTTLE-1017108
— Пиши пока оба, там разберёмся.
Это вопрос из ряда «а какого хуя в comma-separated values сепаратором выступает не запятая»
https://datatracker.ietf.org/doc/html/rfc1866#page-40
Этот стандарт тоже требует, чтобы браузер при отправке формы разделял паметры знаком &.
Однако, он допускает, что сервер может обрабатывать точку с запятой наравне с &, чтобы в готовых ссылках в HTML-коде не нужно было экранировать амперсанды через &
HTTP server implementors, and in particular, CGI
implementors are encouraged to support the use of
`;' in place of `&' to save users the trouble of
escaping `&' characters this way.
Чтобы было труднее делать CSRF: злоумышленник забудет заменить & на & и обломается.
HTTP server implementors, and in particular, CGI implementors are encouraged to support the use of `;' in place of `&' to save users the trouble of escaping `&' characters this way.
Веб-макаки ленились & писать в ссылках, в общем.
Почему бы тогда честно не написать в доке, что изменение вступило в силу в 3.9.2?
Q: Как понять, что коммунист лжет? Помогите, пожалуйста, ответьте, что я могу вообще сказать по поводу этого.
Ответ: Понимайте один час. Чем коммунист лжет? Проще всего заканчивать этот вопрос с тем, что коммунист — это только работник нерушительной коммунистической партии. Он часто спорит с теми, кто считает коммунистическую партию нерушительной. Он считает ее нерушительной потому, что не преступники �? ведь она не прибыла в целом к программам коммунизма для того, чтобы наживаться на деньгах. Посмотрите ее коммунистическую программу и вы убедитесь, что не наживается на деньгах.
Что мешало сделать новую функцию:
А старую задепрекейтить?
https://youtu.be/uYD5japaxsg?t=72