И как же именно запросы на питоне слать проще?

я думаю имеется ввиду pytest , всякие там parametrize и прочая машинерия

А та ещё можешь сделать автоапдейт сделать, как в хроме например... Запустился, сходил на сайт... Скачал новый бинарь. Ну это как вариант.

woot?

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

requests.post(url='http://example.com', files={'file': open('data.json', 'rb')}) requests.post(url='http://example.com', json=json.dumps({'field': 'value'}))

Перед ретурном ведь, разве нет?

requests.post(url='http://example.com', files={'file': open('data.json', 'rb')}) requests.post(url='http://example.com', json=json.dumps({'field': 'value'}))

И что мешает тоже самое сделать на go?

Так а чего тогда убрать?

И что мешает тоже самое сделать на go?

На го чуть многословнее выйдет

requests.post(url='http://example.com', files={'file': open('data.json', 'rb')}) requests.post(url='http://example.com', json=json.dumps({'field': 'value'}))

лучше использовать session object, ну и stream upload/download.

пожалуйста, остановитесь

пожалуйста, остановитесь

эх... да.

давайте сразу ссылку на документацию

что за влажные фантазии

Дык если онизакроет прям перед возвратом из функции то уже ничегл и не нужно будет от того запроса

лучше использовать session object, ну и stream upload/download.

Лучше, да Но это просто пример

каким стеком?

иногда, лучше сумдоку

окей. какая функция и что отрабатывает?

я пытаюсь понять смысл фразы "если функция отрабатывает до return то уже нет операций со стеком"

тут 2 варианта - или недочитанная документация, или имеется ввиду, что тело стоит дочитывать до закрытия, если хочется реюзать коннекшн

но формулировка ужасная :(

defer активируется, когда вы выходите из скоупа, на этом все, дальши какие-то ваши догадки, если нет пруфов, пожалуйста, оставьте их себе

defer активируется, когда вы выходите из скоупа, на этом все, дальши какие-то ваши догадки, если нет пруфов, пожалуйста, оставьте их себе

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

то есть ошибки в коде, но причем тут утверждение выше

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

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

я думаю у вас была #3— Not checking for errors

>Because, here, we didn’t check whether the request was successful or not.

причем тут "операции со стеком"?

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

А если до этого времени рутина не закончит работать с запросом?

А если до этого времени рутина не закончит работать с запросом?

странная формулировка

как проблема связана с решением?

А если до этого времени рутина не закончит работать с запросом?

значит проблема с синхронизацией, и ее нужно исправить

А если до этого времени рутина не закончит работать с запросом?

на чем базируется подобное предположение? defer вызовется при выходе из скоупа.

на чем базируется подобное предположение? defer вызовется при выходе из скоупа.

Рутина ж не привязана к скоупу?

какого контроля?

не знаю кто кого лишает, у меня все под контролем

на чем базируется подобное предположение? defer вызовется при выходе из скоупа.

defer вызывается после вызова оператора возврата, скоуп тут непричем

какого контроля в этом предложении не хватает?

мне нравится слово "иногда", оч полезное в программировании

походу кто-то не знает элементарных основ го и дает советы космического масштаба и космической же тупизны)

лан, я понял, вам в готур

тут походу на любой вопрос ответ "вам в готур"

defer вызывается после вызова оператора возврата, скоуп тут непричем

ок, принято.

тут походу на любой вопрос ответ "вам в готур"

ну, готур - очень полезный

ну, готур - очень полезный

никто же не спорит)

и это хорошо, просто не надо свой опыт говнокода кому то советовать как экспертизу

тут походу на любой вопрос ответ "вам в готур"

не отправлять же читать доку и код функций, это непомерный труд

какого контроля нас лишает?

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

5 типичных ошибок и их решения. вы использовали эти решения?

что в этой статье подтверждает вашу точку зрения?

это типичная ошибка, я так писал когда-то

и? что вы этим хотите доказать?

это не решает проблему.

почему, у автора обработка ошибки была, правда там не было выхода из функции, но это его проблема, а не дефер

потому что вы преподносите работу defer как некую магию, которая иногда ведет себя странно.

магии нет, а истинная проблема в обработке ошибок.

Здесь всем

И это плохой совет

>ребята defer c бодиклоузе лишает вас контроля и иногда вызывает панику... ну вот же вы утверждаете.

какого контроля нас лишают и когда эти иногда случаются вы так и не рассказали =(

а потом еще и стек, который оказался сетевым

вполне возможно, но как его существование связано с defer?

Ну это же не про дефер

Это про обработку ошибок, дефер здесь не причём

Замените строку с дефер на res.Body.Close

блет

оставлю это здесь: перенести defer на 3 строчки вниз и все заработает

что за проблема такая у вас тут?

или уберите return из обработки ошибки (как было у автора вопрошающего)

что за проблема такая у вас тут?

виноват Раст

имхо дефер стоит поставить после проверки на ошибку

ибо если ошибка будет, то в качестве res вернется nil

имхо дефер стоит поставить после проверки на ошибку

и ты будешь прав!