Александр Шаповал: Такой подход - 99.99% знак говнокода. Или даже 100%. Не должны методы знать такую информацию. В нормальной архитектуре это ни к чему.
Я советую человеку как сразу правильно сделать. PayPal автоматом информацию в налоговую сливает. Payoneer скоро должен будет по закону начать тоже.
Да и толку-то. Разве приятно все время шхериться, хранить деньги под матрасом, и не иметь возможности на них ничего купить: ни машину, ни квартиру. Т.к. при покупках от 600 тыс надо объяснять происхождение денег.
А если не зарабатывать на квартиру/машину, то лучше в магазин кассиром работать пойти. Стабильность и меньше нервотрепки.
Та блин, весь код на PHP, который я видел, даже без обфускаторов невозможно понять, тем более, переиспользовать. ) Ну это серьезно мой личный опыт. Поэтому я более 15 лет за PHP не берусь. Но иногда из любопытства заглядываю, че там люди пишут. За 15 лет ничего серьезно не поменялось.
Vadim kyklaed: Правильно создать свою модель пользователя, унаследованную от django.contrib.auth.models.AbstractUser, указать на нее Django в settings.AUTH_USER_MODEL. И в этой модели хранить все нужные поля, вместо размазывания их по нескольким моделям/таблицам.
Vadim kyklaed: Если они и поддерживаются Django, то только потому что существуют тонны уже написанного кода с использованием функций в качестве view. В новом коде нет никакого смысла писать функции-view. Если вы проанализируете свой код, то увидите, что почти все в нем - boilerplate, рыба, которая повторяется в каждом view. Чтобы не писать одно и то же снова и снова, и были сделаны Class Based Views. Изучать и практиковаться на функциях нет никакого смысла.
Так же как нет никакого смысла делать отдельные профили через ForeignKey/OneToOneField. Ровным счетом никакого. Я вам уже писал, что это лишь создаст огромный лишний геморрой на всех этапах разработки и поддержки вашего приложения. Но вы упорно цепляетесь за метод, который использовался целую эпоху назад, в 2006-ом году, когда только-только вышел Django 1.0. Сейчас это не нужно, и это усложняет ваш код, взаимодействие с кодом других библиотек и приложений, миграции, понимание кода другими разработчиками, вообще все. Вам два человека уже сказали, что это грабли, которые вы намеренно оставляете у себя на пути (и на пути следующих разработчиков, которым «посчастливится» поддерживать ваш код). Если не верите, поищите в Google/на StackOverflow другие мнения.
Никто уже так не пишет профили, потому что это костыли и очень неудобно в долговременной перспективе. Зачем вы с таким упорством учитесь неправильному?
А проверить элементарно: UserData.objects.filter(user=request.user).exists()
Мы вам писали, что это самый неправильный способ организации профиля пользователя. Вы с самого начала учитесь делать неправильно. Потом этот велосипед будет сосать кровь из вас и ваших преемников, потому что работать с такой конструкцией неудобно и непродуктивно. Кроме того, тогда уж действительно надо было использовать OneToOneField.
И собственно сам вопрос непонятен. Если вам надо проверить, авторизован ли пользователь, то это request.user.is_authenticated(). Или декоратор @login_required. Или миксин LoginRequiredMixin.
И я вам там же писал, что view-функции уже устарели. Лучше использовать Class Based Generic Views из Django. И код будет раз в 5 короче, и не факт, что в Django 2.0 останется поддержка функций. Почему вы так упорно цепляетесь за самый неудобный и неправильный способ все делать?
Ребята! Ну это же в первых строках документации по Django расписывается.... А если лень читать, то можно увидеть ./manage.py debugsqlshell и сразу видеть, какие запросы и в какой момент времени выполняются.
Андрей: так неправильно. Это ведь сервис не для того, чтобы за кого-то делать работу или домашние задания бесплатно целиком. Я практически разжевал решение.
Если вы сисадмин, то должны были бы легко решить это сами при помощи curl и json-grep (какого-нибудь из многих) в командной строке. Ну или хотя бы знать, чем JSON отличается от POST (как теплое от мягкого).
Это к python вообще не относится. GET/POST - методы протокола HTTP. json - формат представления данных. Вам хотя бы самые основы того, как веб устроен, надо знать.
Видно, что ноль. Вам надо все-таки сначала разобраться хотя бы в том, что такое HTTP, что такое GET, что такое POST, и в чем их отличие от json. Без этого вы вряд ли чего-то добьетесь.
sim3x правильно пишет. Сначала прочитайте туториал и документацию по Django. Так как вы, профиль никто уже не делает лет 8. Нет нужды костылить OnetoOneField.
AntonIgin: Да, не поняли. find_all - не понимает семантику HTML/CSS, он тупо ищет текстовое совпадение. А encoding error от того, что в консоль надо выводить закодированные в utf-8 данные: print(data.encode('utf-8') (если это не консоль Windows, там не знаю, что используется, возможно cp-1251 до сих пор).
Ну, это даже не говнокод, а лишняя работа непонятно зачем. Зачем читать файл по строкам, если он нужен целиком? То же самое и с записью. Лишняя работа как для вас, так и для компьютера.
for line in file.readlines():
result = result+line
file.close()
лучше хотя бы result = file.read()
Ваш код делает совершенно напрасную работу. С записью почти то же самое — нет никакого смысла записывать по одной строке в данном случае, можно file2.write('\n'.join(result))
Как вы в автомате за кофе платите 20 рублей, если у вас в кошельке по одному рублю? Засовываете в монетоприемник по одному рублю. Так и здесь. Притом все многократно описано в литературе, полный процесс, как это происходит.
.*+?