Comments 45
Что бы написать по русски «Привет, Мир!» потребуется скорректировать
модуль routes.py
Добавить строку # -*- coding: utf-8 -*-
А разве это необходимо? Ведь в третьем питоне строки по умолчанию в юникоде.
Since Python 3.0, the language features a str type that contain Unicode characters, meaning any string created using «unicode rocks!», 'unicode rocks!', or the triple-quoted string syntax is stored as Unicode.
The default encoding for Python source code is UTF-8, so you can simply include a Unicode character in a string literal:
P.S. За перевод спасибо.
для чего в первой или во второй строке программы необходимо добавить
специальный комментарий, указывающий тип кодировки:
#!/usr/bin/env python
# -*- coding: UTF-8 -*-А конкретно про utf-8.
В Python > 3 весь текст по умолчанию в utf-8, и обрабатываться он будет как utf-8.
Исключение если мы получаем текст из внешнего источника в другой кодировке.
В том коде что у вас в статье, русские символы обработаются корректно.
Там же у Бизли. Исходные тексты программ на языке Python обычно записываются в стандартной 7-битовой кодировке ASCII. Однако пользователи, работающие
в среде с поддержкой Юникода, могут посчитать это ограничение неудоб-
ным, особенно когда возникает необходимость в создании большого коли-
чества строковых литералов с национальными символами.
Если разобрать, что происходит при запуске программы на python, то мы попадем в модуле site.py в функцию aliasmbcs, где видно, что в случае с виндой и кодировкой все не просто.
def aliasmbcs():
"""On Windows, some default encodings are not provided by Python,
while they are always available as "mbcs" in each locale. Make
them usable by aliasing to "mbcs" in such a case."""
if sys.platform == 'win32':
import locale, codecs
enc = locale.getdefaultlocale()[1]
if enc.startswith('cp'): # "cp***" ?
try:
codecs.lookup(enc)
except LookupError:
import encodings
encodings._cache[enc] = encodings._unknown
encodings.aliases.aliases[enc] = 'mbcs'
Неправильно понимаете, в питоне 3 и строки по умолчанию юникодные, и кодировка файла по умолчанию utf-8 — всё сразу. Писать # -*- coding: utf-8 -*- бессмысленно
Откройте своего Бизли на странице 772, и увидите там:
В Python 3 предполагается, что исходные тексты программ набираются в кодировке UTF-8.
Вот что там говорится:
By default, Python source files are treated as encoded in UTF-8. In that encoding, characters of most languages in the world can be used simultaneously in string literals, identifiers and comments — although the standard library only uses ASCII characters for identifiers, a convention that any portable code should follow. To display all these characters properly, your editor must recognize that the file is UTF-8, and it must use a font that supports all the characters in the file.
Но вот с Windows совсем другое дело, необходимо указывать кодировку, когда она отличная
от UTF-8.
Тогда надо сделать уточнение, что это касается Windows,
а так-же тех случаев когда исходники в отличной от UTF-8 кодировке.
Но вот с Windows совсем другое дело, необходимо указывать кодировку.
Я не понял, откуда такой вывод? Создал сейчас Python-файл в Блокноте без всяких явных указаний кодировок —
2018 год на дворе, почему сайты на питоне до сих пор не оформляют как полноценные самодостаточные пакеты? Пакет с именем app не загрузишь на PyPI. В данном случае, конечно, достаточно переименовать app во что-нибудь адекватное, но меня расстраивает, что это не делают изначально (джанги это тоже касается, кстати)
Простите, а зачем "сайты на питоне" оформлять как "самодостаточные пакеты" и загружать на PyPl?
Конечно спасибо, посмотрю. Конечно интересно!
Нужность загрузки на PyPI действительно спорная (помимо двух упомянутых сайтов у меня есть ещё несколько, которые я не гружу на PyPI, потому что зачем), но тем не менее не вижу смысла не оформлять сайт как пакет изначально, так как пакет удобнее в пользовании (деплой через pip install по-моему намного лучше, чем какой-то убогий git pull) и в будущем передумать будет сильно труднее, чем изначально сделать всё правильно
Ответ прост: «Потому, что можем!»
Если вы используете Microsoft Windows, используйте команду вместо экспорта в команде выше.
Саму команду set пропустили.
virtualenv venv #Создал виртуальную среду
venv\Scripts\activate #Активировал, поигрался
venv\Scripts\deactivate #Деактивировал
Что делать с папкой venv, оставшейся? Её можно просто удалить?
Но у меня несколько отвелечённый вопрос — может быть кто-нибудь знает что-то подобное для PHP и какого-нибудь его фреймворка? Что бы человеку, знающему синтаксис языка, можно было пройти весь путь от проектирования приложения до деплоя.
следует упомянуть про вторую важную функцию, которая включена в режиме отладки — перезагрузка. Это очень полезная функция разработки, которая автоматически перезапускает приложение при изменении исходного файла. Если вы выполните flask run в режиме отладки, можно продолжать работать в своем приложении и при каждом сохранении файла, приложение перезапустится
Что-то вот не перезапускается сервер, если изменять файл шаблона по пути ./app/templates/index.html. Ни export FLASK_DEBUG=1, ни если передать параметр flask run --reload, ни если в ./app/__init__.py прописать app.debug = True не помогают, а изменения в ./app/routes.py, например, отслеживает...
Непонятно откуда в конце появляется файл microblog.py и каково его назначение?
Насколько я понял, приложение создается в __init__.py в строке app = Flask(__name__)
У меня получилось запустить сервер только после импорта set FLASK_APP=__init__.py, но фласк ничего не отдает.
Если накопипасть все в один файл из мануала на сайте фласка и запустить его напрямую
if __name__ == '__main__':
app.run(debug=True))
то работает.
Посмотрите как устроено здесь
Запускать так:
(venv) $ export FLASK_APP=microblog.py(venv) $ flask runЧтобы завершить приложение, вам нужно создать сценарий Python на верхнем уровне, определяющий экземпляр приложения Flask. Давайте назовем этот скрипт microblog.py и определим его как одну строку, которая импортирует экземпляр приложения:
from app import app
И дальше
Чтобы убедиться, что вы все делаете правильно, ниже приведена диаграмма структуры проекта:
microblog/
venv/
app/
. __init__.py
. routes.py
microblog.py
Верьте или нет, но первая версия приложения завершена! Прежде чем запускать его, Flask нужно сообщить, как его импортировать, установив переменную среды FLASK_APP:
(venv) $ export FLASK_APP=microblog.py
Также, хочу отметить, что в файле app/__init__.py, в инструкции импорта, лучше вписать точку, вместо явного определения имени текущего каталога (пакета Python), это не будет вызывать взрыв мозга, что откуда берется и будет ясность. Также, если пакет переименуется, то ничего из этого не сломается. т.е, это:
from flask import Flask
app = Flask(__name__)
from app import routes
лучше заменить на это:
from flask import Flask
app = Flask(__name__)
from . import routes
Также, хочу отметить, что в файле app/init.py, в инструкции импорта, лучше вписать точку, вместо явного определения имени текущего каталога (пакета Python), это не будет вызывать взрыв мозга, что откуда берется и будет ясность.
Меня учили ровно наоборот: при точке непонятно, откуда это дело импортируется, приходится идти путь к текущему файлу смотреть, отрываясь от кода.
Также, если пакет переименуется, то ничего из этого не сломается
Меня учили ровно наоборот: при переименовании или перемещении точка может замаскировать сломавшиеся импорты, поэтому лучше прописывать всё явно, чтобы на сложных случаях вылетел ImportError, а не непонятно что, когда случайно импортировался другой подмодуль с таким же именем. (Хотя, возможно, к __init__ это не относится, но ведь явное лучше неявного же?)
Не знаю, как часто это всё встречается на практике, но такое мнение тоже есть.
Меня учили ровно наоборот
Вполне может быть так лучше, как Вас учили.
но ведь явное лучше неявного же?
В том-то и дело, что в этих строчках нужно напрягаться и вспоминать, так как здесь не явно, что действительно Python умеет и может импортировать:
app = Flask(__name__)
from app import routesНа слух это так: из экземпляра app импортровать routes. Если бы пакет (текущий каталог) был бы назван, например как myapp, то у меня бы вопроса не возникло:
app = Flask(__name__)
from myapp import routesА одна точка (.) — это явное указание, также как и в файловой системе, что импортировать нужно из текущего каталога где этот модуль расположен.
Если вы используете любую версию Python старше 3.4 (включая выпуск 2.7), виртуальные среды не поддерживаются изначально.
Должно быть младше же?
Автор - реальный Годзила по обучению Питону.
Книга "Джанго для девочек", по которой я Джангу учил, по сравнению с этой книгой - это греческий оригинал Библии, по сравнению с Азбукой для детей 1 класса с картинками.
И переводчик, просто красавец, - 23 главы, полный перевод параллельно с автором, и это из песочницы. Поклон.
Мега-Учебник Flask Глава 1: Привет, мир! ( издание 2018 )