Python framework для REST в 2018

Почему тогда он присутствует в спецификации? Или у вас какая-то другая спецификация?

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
6.10 Preprocessing directives

$Спасибо, $я $лучше $буду $писать $на $языке $с \$. $Как-то $короче $получается.

fixed

MySuperRemoveApi.walk_list(list, range)

Ты так и не объяснил, что за программу пытаешься написать. Список чего? Шиндлера? Литры на лето? Миллиардеров forbes? Это, кстати, особо актуально в динамическом языке. В статическом еще можно было бы догадаться по типу list, что ты имел в виду

Я бы твой PR с загадочной переменной «список» не принял:)

Вы бы предпочли django-rest пирамиде? Если не сложно, можете описать причины? Пирамида мне казалась довольно взвешенным фреймворком без оверкилла

Почему тогда он присутствует в спецификации?

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

Это, кстати, особо актуально в динамическом языке. В статическом еще можно было бы догадаться по типу list, что ты имел в виду

Как раз наоборот. В статическом языке выбор имени не стоит так остро, т.к. по типу можно узнать что от тебя хотят. Можно просто везде лепить Type data. А вот в динамическом языке, использовать numbers вместо list в качестве параметра - это эталонный говнокод. Что за numbers? Список? Объект? НЁХ? Обычно пишут что-то вроде numbersList и т.п. но часто использование не специфично, т.е. по смыслу нужно использовать просто имя list.

не объяснил, что за программу пытаешься написать

А тебе хочется перейти на личности? Мы вроде-бы тут обсуждаем общие вещи, а не конкретный код. Если ты хочешь мне помочь, то спасибо, но я не на питоне пишу и у меня обсуждаемая проблема не возникает.

В статическом языке выбор имени не стоит так остро, т.к. по типу можно узнать что от тебя хотят. Можно просто везде лепить Type data. А...

ЯННП. Я же вроде то же самое написал

А тебе хочется перейти на личности?

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

print(list(list[range[0]:range[1]]))

Ты серьёзно сейчас докопался до языка, что он не угадывает за тебя где ты имел ввиду встроенный тип, а где - свою переменную?

Возможно в Python 42, к которому таки слинкуют libastral это и будет работать... но я не представляю конструкцию такого вида, которая работала бы в любом из ныне существующих языков.

Он злится не из-за недогадливости языка, а из-за того, что язык отобрал очевидные слова и не дает наговнокодить в продакшн в стиле moya_laba1.py: def print(list, str)

Могу предложить везде вместо list писать array

Что за numbers? Список? Объект? НЁХ?

Кому вообще может прийти в голову назвать объект «numbers»?

Обычно пишут что-то вроде numbersList

Что за бред? Ещё венгерскую нотацию предложи. Хочется указать тип — укажи его аннотацией, для этого их и завезли.

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

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

Придумали ли что-то лучше для rest приложений, которые легко интегрируются с react, webpack и прочей новомодной фигнёй?

Интеграция не нужна, это не реакт-на-рельсах.

Как собственно и от REST.

GraphQL же есть везде.

Ты это сначала на нормальный язык переведи. Что я, гадать должен, что за фигню ты тут написал?

На любом нормальном языке оно выглядит так же.

GraphQL же есть везде.

Как этой хипстернёй вообще пользоваться в связке с RDBMS, лол? Есть какой-то общепринятый способ трансляции GraphQL в безопасный SQL с джойнами? Потому что Graphene-Python, например, тупо делает по запросу на каждую вложенную коллекцию в каждом объекте. В наше время за N + 1 запросов по рукам били, а тут даже не N + 1, а (N + 1) * (M + 1) * (K + 1) * ... - по числу уровней вложенности, коих может быть потенциально бесконечное количество. Это типа такая поддержка RDoS на уровне API?

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

Иксперты-тиоретики объясняют, откуда в питоне проблемы, никогда на нём не писав. walk_list($list = list()).list$.list_.factory_$list)!list вестимо лучше.

на языке идиотов, сидящих в психушке?

Graphene-Python, например, тупо делает по запросу на каждую вложенную коллекцию в каждом объекте.

`resolve_foo` для начала.

Кому вообще может прийти в голову назвать объект «numbers»?

Это как раз таки нормально, лучший вариант. Не понимаю откуда у вас у всех такие дикие представления. И список и вполне объект можно назвать и numbers и list. Это будет нормальный, понятный код.

Добавлю, что многое зависит от контекста.

Можно пример объекта numbers?

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

Это не я докопался, это фанбои питона докопались до $. Я просто натыкал их рожей в их собственное говнецо.

но я не представляю конструкцию такого вида, которая работала бы в любом из ныне существующих языков

$ вполне себе работает. Другой вариант, решение в духе lisp-2, например ruby.

irb(main):001:0> puts "hi"
hi
=> nil
irb(main):002:0> puts = 42
=> 42
irb(main):003:0> puts
=> 42
irb(main):004:0> puts "hi"
hi
=> nil
irb(main):005:0> def foo(puts)
irb(main):006:1> puts puts
irb(main):007:1> end
=> :foo
irb(main):008:0> foo("hi")
hi
=> nil

Можно пример объекта numbers?

Ты что-то совсем уже в бутылку лезешь. Сам же предлагал numbers для списка чисел. Чем объект хранящий список чисел (+ специфичные операции над ними, что б ты не спрашивал зачем объект) отличается от твоего предложения?

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

А вот переменные пожалуйста (это упрощенная примерная версия из реального проекта):

class iface_sysfs_object():
    def get_path_numbers(eth_ifname):
        # ...
        # ...
        # ...
        return numbers

class dev_tree_poll_watcher():
    def get_exclusion_list(equipment_type):
        # ...
        # ...
        # ...
        return list

конечно вы можете говорить device_path_numeric_components (и еще варианты) и equipment_we_dont_support или хотя бы exclusion_list вместо просто list (и т.п.), но это вовсе не всегда нужно. Контекст решает, аналогично и со string и с set (последнее вообще лишь _набор_, _множество_).

Я понимаю, что иногда бывает так, что назвавшие переменную list, cделали это вне подходящего контекста, а использовавшие array, вовсе не имели в виду, скажем, disk array.

Но всё же, когда вы говорите про имена типа list

наговнокодить

то вы совсем неправы.

никогда на нём не писав

Ты, дружище, эталонный дурачок. Я не пишу на питоне, не означает, что я на нём никогда не писал.

Кроме того, самоочевидный пример - это имена типа list в функциях общего назначения вроде flatten(list_of_lists) -> list.

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

Или whatever_to_string(whatever) -> string может внутри использовать string. И в данном случае, использование string в качестве имени переменной, вероятно, будет наиболее (если не единственно) верным вариантом (ведь the very idea функции такова).

Чем , что б ты не спрашивал зачем объект) отличается от твоего предложения?

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

очевидные слова и не дает наговнокодить в продакшн в ст
иле moya_laba1.py: def print(list, str)

grep -r klass /usr/lib64/python3.6/

Я надеюсь не будет возражений мол «это же класс а я просил list и str». Думаю что это достаточно близко. Короче, вы глубоко не правы.

Как ты обзываешь локальные переменные — это твое личное дело. Мы ведь про API говорили. Ты же не назвал агрументы функций просто str. Постеснялся?

Ты же не назвал агрументы функций просто type
Постеснялся?

Твой пример - антипример какой-то. Вполне, почему бы и нет.

def list_eths(type)

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

это я про «Постеснялся?»

«латиницей», конечно

Тогда не забудь воткнуть docstring, описывающий, что за type такой

Тогда не забудь воткнуть docstring

Я как-нибудь без тебя разбируюсь что мне делать. Я в программировании хоть и с перерывами и разной степенью вовлеченности с середины 2000х годов.

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

например ruby.

Хм... забавный подход. Однако цена - особое положение понятия функции. Тебя больше устраивает особое понятие функции. В python принято уравнивать функции с другими переменными.

>>> hi = print
>>> hi
<built-in function print>
>>> hi(123)
123

это фанбои питона докопались до $. Я просто натыкал их рожей в их собственное говнецо.

Меня собственно не волнуют чьи-то там проблемы с $. Меня волнует что вместо того, чтобы обсуждать заданный вопрос «как сделать REST на Python», ты пытаешься рассказывать что Python «плохой язык». Может просто не твой.

Многое делается руками (например нужно запускать тесты - напиши сам или ищи пакеты). Но больше всего паяет request - огромный объект в котором «всё», даже response. Меня пугают большие объекты с кучей методов. А так - работает и ладно.

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

вахтер?

При этом ни docstrings, ни эти mypy аннотации сами по себе не делают код ни лучше, ни понятнее, ни надежнее

Зависит от того, что подразумевается по «сами по себе»

Я сам пишу API на loopback, но если python очень советую присмотреться к crudl.io. Ребята сделали очень качественный «велосипед» для админок, но не только. Готово к интеграции к вашему python API, подробная документация.

Пока не готов продать душу окончательно.

Посмотри на Sails. Подписать вот тут. -> _________

наговнокодить в продакшн в стиле moya_laba1.py: def print(list, str)

Могу предложить везде вместо list писать array

шел бы ты отсюда, балабол «продакшенский»

https://github.com/python/cpython/blob/master/Lib/json/encoder.py#L277

твои докстрингс не приветствуются, твой труд вообще вреден. за юнит-тесты еще топить начни давай, быдлокодер.

Однако цена - особое положение понятия функции

Нет, не особое. Просто переменная может содержать два значения, одно обычное, а второе - функция. def присваивает функциональное занчение, а «=» обычное. Нужное значение выбирается исходя из контекста, а если требуется явно вызвать функцию записанную в обычное значение, то нужно писать foo.call

вместо того, чтобы обсуждать заданный вопрос «как сделать REST на Python», ты пытаешься рассказывать что Python «плохой язык»

Но ты же обсуждаешь $ и проблемы в питоне, а не заданную тему. Зачем ты мне написал, я тебя не просил ничего обсуждать, тем более не по теме.

Приводить в пример JSON-сериализатор для встроенных типов

А ты очень умный, да?

А чем это всё принципиально отличается от $foo?

на правах кэпа - отличается тем, что в случае пистона «если нельзя, но очень хочется - то можно». а на пыхе хоть ты обосрись, а нормальные имена переменным давать не сможешь никогда - жри что дают, говноед ;) а все остальное дело вкуса.

Я просто натыкал их рожей в их собственное говнецо.

ЧСВ свое раздутое можешь сдуть используя _ в качестве первого символа в названиях своих переменных, дабы было понятно, откуда прогер пришел.

Оно синхронное. 2018 год на дворе, синхронный код будешь писать - будешь плохо спать, совесть замучает

Некрофилы не нужны. А для ассинхронности есть actix.