Как стать автором
Обновить
3
0
Adrian @ADR

Пользователь

Отправить сообщение

Можете, пожалуйста, показать OpenAPI документацию по этому ендпоинту? А то, мне сложно понять зачем всё это)

Что значат все эти дженерики?

Ctrl+Click обычно помагает.


… у них отличная команда поддержки и документация. Но что, если нам придется поддерживать код, который не имеет всего этого?

Если в них нету документации тогда в случаи с JS мы вообще не знаем что такое dispatch, тогда как в случаи с TS знаем все интерфейсы (+ IDE помогает)


И для ThunkAction<void, {}, {}, AnyAction> и ThunkDispatch<{}, {}, AnyAction> можно сделать псевдонимы типа AnyThunkAction AnyThunkDispatch если они очень часто используются.


Первое, что бросается в глаза — опять пишется больше кода.

userRoute.ts может виглядет так:


class UserRouter extends Router {
    public address = "/users";

    list(req: express.Request, res: express.Response) {
        //get uesrs from DB
        res.json(users);
    }

    create(req: express.Request, res: express.Response) {
        //create user
        res.json(userCreated);
    }
}

Например так выгладит хендлер для CRUD в Python/Django REST Framework с авторизацией, пагинацией, автогенерацией документации и еще много чего (подскажите аналог для TS/JS):


class UserViewSet(ModelViewSet):
    serializer_class = UserSerializer

Где здесь лишний код из за ООП?


П. С.: Лично для меня идеально не писать типы, но чтобы IDE о них знала. В Kotline что-то такое делают.

Я также голосовал по за iPhone пока не смотрел кропи… Баланс белого лучше, детализация хуже.


Правда тут тоже спорно что важнее: соц сети и так режут детализацию, а автоматические фильтры в гугл фото обычно помогают с насыщенностью цветов и балансом белого.

Честно говоря не уверен, что мой пример с С правильный (не успел удалить).
В "строгом" Delphi есть тип PChar (Pointer to char) к которому можно добавить число, но это не мешает ему быть "строгим". Так что, это больше похоже на переопределение методов как в "строгом" Python с "abc" * 3.


Кто-то может привести лучший вариант, почему в С официально слабая типизация? (примеры неявного конвертирования)

Это проблемы слабой, а не динамической типизации.


Пример на C:


printf(3 + "abcdefg"); # stdout: defg

(да, я знаю, что стринга, это указатель в C)

At least for the initial release, slots will not be supported. slots needs to be added at class creation time. The Data Class decorator is called after the class is created, so in order to add slots the decorator would have to create a new class, set slots, and return it. Because this behavior is somewhat surprising, the initial version of Data Classes will not support automatically setting slots.

https://www.python.org/dev/peps/pep-0557/#support-for-automatically-setting-slots

dockerfile в котором всё работает было бы идеально. А то у всех проблемы разные :)

пожалуйста, выберите один пример и мы обсудим

Лично я говорил только о DELETE /delete vs DELETE /.


И мы сошлисть на том, что пункт "Never use CRUD function names in URIs" оправдан. Можно пройтись и по другим пунктам.


Это всё что я хотел сказать.

вас точно не смущает слово "tips" по ссылке выше?

Нет.


Один запрещает использовать глаголы в URI; второй разрешает только те, которые нельзя выразить с помощью HTTP-методов, используя для этого свои понятия, которые отсутствуют в REST. Другие же честно разделяют обязательные и необязательные ограничения. Это порождает просто чудовищную путаницу в головах, превращая REST в хреновину, которую никто не может может толком описать.

Не согласен, но сейчас не об этом.


он ничем не лучше.

Я скажу чем хуже: +одно слово +0 информации (не я один такой умный, поэтому, это уже описали в этих "tips")
Вы согласны?

Повторю вопрос:
В стандартном, указаном вами, гайде в разделе в разделе Never use CRUD function names in URIs предлагают делать DELETE /, но вы защищаете вариант с DELETE /delete


(пожалуйста не расширяйте фокус вопроса. можете даже проигнорировать то что сверху и ответить только на следующий вопрос)


Чем DELETE /delete лучше за DELETE /?

При этом ~0,2 А уходит на его текущую работу в спящем режиме.

В этом обзоре сказано, что P9 Lite держится 79 часов в режиме ожидания что равно:
3000мАг / 79г * 3.7В = 140.5 мВт
Что сильно меньше указанных вами 0.2А * 5В = 1000 мВт


1Вт это потребления во время "web browsing"
3000мАг / 12г * 3.7В = 925мВт

Но ведь никто не говорит, что такие комментарии нарушают, например, ООП.

Вы правы, тип ошибки указана не верно. Но всё же она есть, согласны?


Вопрос стиля URI это ортогональный вопрос вкуса и внутренних соглашений.

Есть основной стиль, а есть "все другие".
Чем DELETE /delete лучше за DELETE /?

По какому стандарту?)

Ну не стандарту, а стандартному стайл гайду. Это ничего не меняет.


Зачем писать:


POST /add
GET /get
DELETE /delete

вместо стандартного:


POST /
GET /
DELETE /

это то же самое что писать коментарии типа: n += 2 # add 2 to n — никакой новой информации

Мое ИМХО:


DRF это all-inclusive где с коробки есть почти всё что нужно для большинства сервисов.
Благодаря этому для него есть много плагинов, потому что автор плагина знает "ага раз DRF значить Django ORM, DRF Serializers/Views/etc."


С другой стороны есть Flask компоненты для которого нужно собирать словно кубики лего что требует траты много времени на исследованные всех "кубиков". Они к тому же очень часто не совместимы между собой.


А FastAPI это где то по середине. (ближе к Flask, но со некоторыми фишками)


Я бы пока брал DRF для продакшена.

можно проще:


$ python -c "print((569_936_821_221_962_380_720)**3 + (-569_936_821_113_563_493_509)**3 + (-472_715_493_453_327_032)**3)"
3

Хм. В варианте с inner join ошибка: должно быть не "IS NOT NULL", а "IS NULL".


По експлейнах вижу Seq Scan on products в случаи с JOIN.
Интересно что будет если все условия перенести в JOIN:


SELECT COUNT(*) FROM "listings" 
INNER JOIN "products" ON products.id = listings.source_id and (
    "products"."site_id" IS NULL OR "products"."item_id" IS NULL
);
Ну я же говорил, что это из моей личной коллекции «Как не надо писать SQL» :-D

Не увидел, виноват (главное читал же комент))


И, хоть это немного и контринтуитивно, но такой вариант с подзапросом работает ощутимо быстрее вашего примера с JOIN (1 секунда против 8), хотя я сам думал, что ваш будет быстрее.

Не знал о таком. Спасибо)

Мне кажеться та будет быстрее:


SELECT COUNT(*) FROM "listings"
INNER JOIN "products" ON products.id = listings.source_id
WHERE "products"."site_id" IS NOT NULL AND "products"."item_id" IS NOT NULL

то есть без sub query в where которая исполняеться для каждой строчки listing.

Проблема будет при обращении к self внутри проперти:


from inspect import iscoroutinefunction

from asyncio import QueueEmpty, QueueFull
from concurrent.futures import TimeoutError

class ProcessException(object):
    __slots__ = ('handlers',)

    def __init__(self, custom_handlers=None):
        if isinstance(custom_handlers, property):
            custom_handlers = custom_handlers.__get__(self, self.__class__)

        raise_exception = ProcessException.raise_exception

        exclude = {
            QueueEmpty: lambda e: None,
            QueueFull: lambda e: None,
            TimeoutError: lambda e: None
        }

        self.handlers = {
            **exclude,
            **(custom_handlers or {}),
            Exception: raise_exception
        }

    def __call__(self, func):
        handlers = self.handlers

        if iscoroutinefunction(func):
            async def wrapper(*args, **kwargs):
                try:
                    return await func(*args, **kwargs)
                except Exception as e:
                    return handlers.get(e.__class__, handlers[Exception])(e)
        else:
            def wrapper(*args, **kwargs):
                try:
                    return func(*args, **kwargs)
                except Exception as e:
                    return handlers.get(e.__class__, handlers[Exception])(e)

        return wrapper

    @staticmethod
    def raise_exception(e: Exception):
        raise e

class Math(object):
    def __init__(self, error_message: str = 'Cannot divide by zero!'):
        self.error_message = error_message

    @property
    def exception_handlers(self):
        return {
            ZeroDivisionError: lambda e: self.error_message
        }

    @ProcessException(exception_handlers)
    def divide(self, a, b):
        return a // b

assert Math().divide(4, 2) == 2
assert Math().divide(4, 0) == 'Cannot divide by zero!'
assert Math().divide.__name__ == 'divide'

AttributeError: 'ProcessException' object has no attribute 'error_message'

Информация

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