- 1
- 2
In [42]: os.path.join(r'c:\asd', r'c:\www')
Out[42]: 'c:\\www'-
Python / Говнокод #24306
+1
Нахуя???
Запостил:
syoma,
23 Мая 2018
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
Всё очень секурно. Думаешь защититься от обхода каталога? А вот хер тебе об твой лысый череп?
Как сделать чтобы os.path.join(path1, path2) не выходил за пределы path1? Ваши версии?
Ы-ы-ы :D
Самое простое: если isabs вернет true или в строке есть '\\..\\', то послать нахуй. Или есть функция, которая позволяет узнать, дочерний ли это каталог?
Согласен.
Как минимум от ".." оно не защищает.
З.Ы. Поведение документировано.
> З.Ы. Поведение документировано.
А нахер оно нужно? Как же принцип наименьшего удивления? Какая логика за ним стоит? Или поставили знак "битая дорога" - и можно не ремонтировать?
Как я понял, ради простого использования в конфигах и командной строке, чтобы isabs() не дёргать…Других причин не могу придумать.
Почему нельзя сделать что-то вида
А в libcversion.h - что-то вида
Выбираешь себе версию - и вперёд. Страж включения, конечно, придётся сделать более тонким (по стражу на версию, чтоб в разных частях включать разные версии), но это реализуемо.
Аналогично - в Питонии, только там даже проще реализовать.
Ну это, по сути, просто новая либа. А старую задепрекейтили и когда-нибудь выпилят. Можно было просто написать os2 с тем же успехом.
> os:latest
Для любителей мазохизма и поломанных билдов? :)
И потом программа не запускается только потому, что в 2030 году кто-то из соображений перфекционизма в сигнатурах решил выбросить код, стабильно работавший в 2010 и 2020.
Надо хотя бы в репозитории оставить старую библиотеку, не включая в стандартную поставку, чтобы старую прогу можно было запустить в любое время просто после вызова какого-нибудь pip resolve program.py.
>> os:latest
> Для любителей мазохизма и поломанных билдов? :)
Для обычных людей? Сейчас, в общем-то, обычные люди так и живут с os:latest. Разве что, такое версионирование развялало бы руки посильнее.
На которую тут же забьют болт и даже баги не будут править, как во многих модулях двойки? Да что там модулях, там даже сырые строки не сырые.
Править её надо только если где-то внизу (в ОС, например) что-то поменялось так, что без правок код os_old уже не работает.
Для нового кода - новая версия без багов. Для старого - возможность запускаться как раньше без потребности каждую версию питона отмечать проверками совместимости.
К слову, в libc были такие изменения. К примеру, когда завезли потоки и errno превратилось в макрос. Куча старого софта, где errno любили юзать напрямую, тупо перестала запускаться.
Но так это придётся поддерживать только в стандартной библиотеке. Интерфейсы обычных библиотек должны быть независимыми от версии стандартной (можно один раз выбрать LIBC_V2 и на ней писать).
Но стандартная библиотека не должна поддерживать старые версии, они просто останутся в коде. Изменять их опасно, т.к. на них полагаются. Тут можно даже баги документировать. Изменяться будет только последняя версия, пока поверх неё не появится новое наложение.
Ну т.е. в твоей стандартной либе не будет даже банальных string и vector? Только тоненькая обёртка над ядерным API (которое обязано быть обратно-совместимым иначе вся твоя идея с запуском старых прог развалится), только хардкор?
В стандартной библиотеке будет несколько ревизий нужных функций, поддерживаться и изменяться серьёзно будет только последняя, старые будут только сохранять их контракт и свою работоспособность. В некоторых случаях старые версии могут быть переписаны через новые (если API ОС вдруг сильно изменилось и т.п., когда новая функция более общая), когда это проще для сохранения их работоспособности.
>> интерфейсы должны быть независимыми от версии стандартной
Это про интерфейсы обычных библиотек, которые используют стандартную.
Библиотека Васи Пупкина должна работать согласно её документации, пользователь должен заботиться только о её версии, а не о версиях использованных ей библиотек.
Если стандартная либа не будет юзаться как базис для связи либ и прог между собой — нет смысла делать что-то сложнее тоненькой обёртки над ядром.
Тут либо надо запрещать использовать те же имена для разных версий, либо в новых версиях только добавлять поля в структуры.
Возможно, стандартные конвертеры тоже придётся запиливать.
Библиотеки можно тогда привязывать к конкретным версиям стандартной библиотеки, описывая это чётко в документации, чтобы пользователь знал, какие точно типы данных там будут и сильнее этого с версиями не возился. (можно реализовать и многоверсионный вариант просто естественным образом переходя на новую версию стандартной библиотеки и замораживая разработку под прошлую версию - тут с учётом фиксированности старых версий стандартной библиотеки поддерживать вообще ничего не надо, если контракт соблюдали)
Сишного говна в сетевой библиотеке более чем дохера. Все эти кальки с сишного api в socket, когда даже в перле любой сокет (клиентский, серверный) со всеми параметрами создавался одним конструктором.
Любой сокет одним вызовом. А в питоне как? И кроме socket() я еще нигде ничего не видел.
Слушающий тоже? Почитай по ссылке.
Не видел в реальном коде.
Потому что реальный код писали сишники, которых socket() не напрягает?
А остальные юзают высокоуровневые протоколы, реализованные сишниками (http и т.п.)
>Ну а SocketServer и SocketClient тебе чем не нравятся?
А create_connection не видно за горой хлама.
Кстати, некто Борманд недавно запилил на своём сервере штуку, которая пишет все доступные ей версии комментариев.
Борманд, берегись, большой Борманд следит за тобой!
Вот за это я и ненавижу доки питона.
К слову о сокетах — какого хуя там есть sendall (отправить буфер целиком), но нету recvall (вернуть ровно N байт или кинуть исключение при EOF)?
Доки самого питона неплохие, но напрягает что они недоступны из ide/консоли. А вот в сторонних либах уже как повезёт.
А в c recvall есть? Что он должен делать? Вообще, всё это нахуй не нужно. makefile() и дальше работаешь как с файлом. В жавке так и сделано (FilteredStream, кажется), можешь считать из потока int и вызов заблокируется, пока в сокет не придут данные в нужном объеме.
Хм, спасибо, попробую.
> Что он должен делать?
Вот это: вызов заблокируется, пока в сокет не придут данные в нужном объеме.
> А в c recvall есть
Так там и sendall нету. Вот эта неконсистентность и бесит. Зачем делать один хелпер, но не делать второй?
Да, тип того.
Да должен, по идее, судя по доке он просто читает в цикле.
З.Ы. Ждёт, всё ок. Спасибо.
>З.Ы. Ждёт, всё ок. Спасибо.
Пожалуйста :)
Да.
Да, так и работает.
А как себя read() поведёт? Вернёт меньше байтов? Жавка хоть исключение бросала.
Только если сказать это питонисту - он глазёнки выпучит и побежит на тебя в штыковую. За что я питонокомунити и не люблю (привет, питон.ссу!). Даже пыхари здесь имхо адекватнее.
Что толку знать что парметр foo типа bar это anchor если ты не знаешь что такое anchor?
Кроме того в питоне тяжело делать референс потому что может быть 28 видов вызова функции с разными kwargs
Мне больше всего нравится (внезапно!) MSDN по win32api: там и Remarks очень мощный и референс подобный
зацени
https://msdn.microsoft.com/en-us/library/windows/desktop/bb762153(v=vs.85).aspx
маны у никсов еще иногда бывают ничего (ну кроме опендесктопа конечно)
> win32api
Низкоуровневое говно.
А потом ты видишь код, работающий не так как надо, сидишь и смотришь на него как баран на новые ворота.
Во-первых, можно по каждому аргументу написать, что туда написать.
Во-вторых, 28 непересекающихся наборов - это уже говнокод, а 5-6 вполне можно оформить как перегрузки.
И сделать конфетку как на cplusplus.com
Но для того, чтобы проверять как положено, должны быть специальные библиотечные функции, которые учитывают всё, что можно, прошли месяцы/годы проверок в реальных ситуациях, аудит или хотя бы множественное прочтение сообществом.
Тупые функции, которые ничего не проверяют, можно и самому написать. А секьюрную питушню надо в стандартную библиотеку и на каменных плитах выдолбить, чтоб своими велосипедами багов не добавляли.
Такое поведение тоже нужно в некоторых случаях. Только недавно сталкивался: надо было взять путь, и если он был не абсолютный, добавить к нему каталог по умолчанию.
Авторам надо было реализовать оба варианта, т.к. оба на практике нужны.
Я бы порекомендовал бы зафильтровать пользовательскую питушню максимально до предела по регулярке, чтоб туда проникли только латинские символы, цифры, дефис и т.п., а точка могла бы быть только как расширение - между двумя непустыми наборами вышеупомянутых символов.
Тем более, если это вэб-сервер. Хрен знает, что там будет на выходе - старшие байты обрежутся, символ после приведения к инварианту станет точкой, кто-нибудь засунет полусимвол, который вызовет исключение в декодере или ещё какая питушня произойдёт. JSFuck смог пролезть через 6 символов, а тут тысячи их. Тем более, на вэб-сервере это перейдёт в безумные xn--p1ai или в %A1%D0. Ну и мировому сообществу кириллица и иероглифы нафиг не нужны, особенно если ссылку надо где-то напечатать.
То есть
c:foo - это файл foo в текущем каталоге на диске c
cc:foo - это поток foo файла cc в текущем каталоге
То есть если понадобится писать в потоки произвольных файлов, надо следить, чтобы их имена не совпадали с именами дисков, иначе перетрутся не потоки, а файлы.
Там вроде ещё COM1 в любом месте пути можно писать было (C:\foo\com1 откроет com1).
Питон на винде до 2016 года архивы нормально создавать не умел.