вью это не только когда в контроллере шаблонизатор используется

когда от пользователя тебе по http приходит сообщение он тоже через вью дёргает твой контроллер

Скиньте, пожалуйста, хорошую статью про метод строки format ... Не могу найти информацию про такую конструкцию: char1, count1 = format(S1)

Скиньте, пожалуйста, хорошую статью про метод строки format ... Не могу найти информацию про такую конструкцию: char1, count1 = format(S1)

это метод, а не функция

это метод, а не функция

Я, вроде, так и написал

Я, вроде, так и написал

нет count1 = format(S1)

Скиньте, пожалуйста, хорошую статью про метод строки format ... Не могу найти информацию про такую конструкцию: char1, count1 = format(S1)

https://docs.python.org/3.6/library/stdtypes.html#str.format

https://docs.python.org/3.6/library/stdtypes.html#str.format

Спасибо

нет count1 = format(S1)

Да, это была функция... Не заметил ?

когда от пользователя тебе по http приходит сообщение он тоже через вью дёргает твой контроллер

>http приходит сообщение >в mvp ... они просто обмениваются сообщениями

в mvp презентер в своём контексте рассматривает сообщение

в mvc юзер прямо через вью дёргает контроллер

не вижу, где здесь появляется интерфейс

почему он обязателен?

в статически-типизированных языках это заметнее

особенно на примере мобильных или десктопных приложений

да, я чувствую, что общаюсь как будто с джавистом

просто на питоне сам по себе интерфейс это что-то пиздец абстрактное до кучи

начинаю понимать

да, я чувствую, что общаюсь как будто с джавистом

так и есть

у меня просто от синтаксического сахара глаза слиплись

так и есть

Всё. Теперь понятно. У вас архитектура очень завязана на реализацию. И сделать нормальное чопорное MVP без абстрактных классов — это ССЗБ и целится себе в ногу.

Они не обязаны общаться

и вот это я не понимал как раз из-за запитонености мозга "а в чём тогда разница?"

Паззл сошелся

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

mvp и mvc - это какая-то абстрактная херня, которая даже в джанге нормально не заимплеменчена

mvp и mvc - это какая-то абстрактная херня, которая даже в джанге нормально не заимплеменчена

в джанге же и не пытались mvp сделать

в джанге же и не пытались mvp сделать

mvc пытались

но Эскобар прав был

ну на питоне делать архитектуру немножко похоже на замок из песка

поясни

что угодно можно лепить?

ну во всяких плюсах и жабах это всё делается, учитывая строгость языков

есть единственная концепция веб-приложения, которая работает - по сраному урлу дергать сраную функцию

все остальное со всякими MVC/MVP - это абстрактная хрень сверху

примерно как REST, который в чистом виде практически не существует, и каждый трактует его по-разному

mvp и mvc - это какая-то абстрактная херня, которая даже в джанге нормально не заимплеменчена

а мне всегда казалось что в вебе MV* по дефолту везде

а мне всегда казалось что в вебе MV* по дефолту везде

в вебе по дефолту везде сраные урлы и сраные функции

начиная от деления на фронтенд и бекенд

начиная от деления на фронтенд и бекенд

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

примерно как REST, который в чистом виде практически не существует, и каждый трактует его по-разному

эм? что значит не существует? на какое правило все забивают обычно?

но MVC тут примерно ни при чем

эм? что значит не существует? на какое правило все забивают обычно?

значит, не существует. Что в REST делать с коллекциями? Как имплементить джойн? Где поддержка в одном API обоих JSON и XML?

на большую часть правил забивают

ну на питоне делать архитектуру немножко похоже на замок из песка

ну, кстати, если вспомнить, как явяне закладывают фундамент (ПАТТЕРН BUILDER), то да, после такого питонопроектирование выглядит как валяние в песочнице

значит, не существует. Что в REST делать с коллекциями? Как имплементить джойн? Где поддержка в одном API обоих JSON и XML?

это всё не про rest же

это всё не про rest же

это все как раз про REST

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

на большую часть правил забивают

их же всего не то 6 не то 5

пять с половиной

и почти все они нарушаются в реальных проектах

и почти все они нарушаются в реальных проектах

ну значит это не REST

всё просто

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

ну значит это не REST

ну так я про то выше и написал. В чистом виде он не существует практически нигде

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

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

но MVC, опять же, тоже в чистом виде нигде не существует

но MVC, опять же, тоже в чистом виде нигде не существует

ох вау, а тут-то что происходит?

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

ох вау, а тут-то что происходит?

ничего ? что такое Controller в MVC?

и где он, скажем, в джанге или фласке?

если ты сейчас скажешь, что контроллер у нас во views.py - это будет очень забавно

ну, кстати, если вспомнить, как явяне закладывают фундамент (ПАТТЕРН BUILDER), то да, после такого питонопроектирование выглядит как валяние в песочнице

хоть представляешь каково это - делать под каждый json паттерн отдельный класс?

Что лучше, если нужно задать очень маленькую переменную N = -10**9 или N = float('-inf') ... В плане оптимизации

Что лучше, если нужно задать очень маленькую переменную N = -10**9 или N = float('-inf') ... В плане оптимизации

смотря какая у тебя логика в приложении

ERROR: S client not available

тут экономия на спичках, вообще без разницы

смотря какая у тебя логика в приложении

У меня есть ограничения по входу некоторой переменной и мне нужно сделать так, чтобы эта перменная при первом входе всегда была больше переменной N

тут экономия на спичках, вообще без разницы

Окей

У меня есть ограничения по входу некоторой переменной и мне нужно сделать так, чтобы эта перменная при первом входе всегда была больше переменной N

тогда сравнивай их во время ввода и проверяй

не надо на маленькие значения завязываться

и где он, скажем, в джанге или фласке?

я не сильно разбираюсь, но разве весь джангокод, который ты пишешь, это не создание котроллера?

я не сильно разбираюсь, но разве весь джангокод, который ты пишешь, это не создание котроллера?

так вот и никто не разбирается, потому что концепция абстрактная и к жизни не имеет отношения

А ещё можете посоветовать хорошую "шпаргалку" для python, чтобы можно было расспечатать ... ( Все методы строк, списков и т.д.)

так вот и никто не разбирается, потому что концепция абстрактная и к жизни не имеет отношения

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

а это совсем коротко https://pythonworld.ru/uploads/mementopython3-russian.pdf

А ещё можете посоветовать хорошую "шпаргалку" для python, чтобы можно было расспечатать ... ( Все методы строк, списков и т.д.)

держи

держи

Большое спасибо!

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

понятия не имею. Судя по описанию архитектуры, модель - это описание в коде сущностей, которыми он оперирует, и это состояние сохраняется между вызовами

этому описанию в джанге не соответствует ничего, кроме самой БД, ибо модели инстанциируются и создаются каждый раз заново при вызовах

опять абстрактная хрень

понятия не имею. Судя по описанию архитектуры, модель - это описание в коде сущностей, которыми он оперирует, и это состояние сохраняется между вызовами

>понятия не имею ага

понятия не имею. Судя по описанию архитектуры, модель - это описание в коде сущностей, которыми он оперирует, и это состояние сохраняется между вызовами

да, так и есть

модель это представление данных

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

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

представление это не отображение, это логика отображения

если же вьюхи считать за представления - то тоже хрень, ибо во вьюхах бизнес-логика, а из представления там функция render() только

представление это не отображение, это логика отображения

без разницы, говорю же, концепция абстрактная слишком

ну никак не маппится она на реальную жизнь

вообще в вебе mv* хорошо ложится только на spa

если же вьюхи считать за представления - то тоже хрень, ибо во вьюхах бизнес-логика, а из представления там функция render() только

там не рендер вью, а то, что происходит в браузере у пользователя

по-моему в вебе надо сделать отдельно сервак с апи, отдельно к нему морду, которая этим апи будет пользоваться

там не рендер вью, а то, что происходит в браузере у пользователя

то есть html + css?

и js

и апи это и есть та самая общая абстракция, от которой зависят и морда и бэкенд

ZODB вам в помощь...

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

чем тебе твоё html+css с логикой отображения не view? чем тебе БД с логикой взаимодействи не model?

шта это