#python #web2py
#python #web2py
Вопрос:
Я пытаюсь понять, как работает веб-фреймворк web2py, и есть этот вызываемый элемент request.client access.py , который я не могу понять, откуда он взялся. Я извлек код отсюда, и он начинается следующим образом:
import base64
import os
import time
from gluon.admin import apath
from gluon.fileutils import read_file
from gluon.utils import web2py_uuid
from pydal.contrib import portalocker
# ###########################################################
# ## make sure administrator is on localhost or https
# ###########################################################
http_host = request.env.http_host.split(':')[0]
Мой вопрос: когда мы не знаем, откуда в коде появляется элемент, каков способ его найти?
Комментарии:
1. Посмотрите документацию библиотеки. В каждой законной библиотеке он будет.
2. вы пытались вызвать >>> справка (запрос.client)? вы можете найти там полезную информацию.
Ответ №1:
Как объясняется здесь, файлы модели, контроллера и представления web2py выполняются платформой в среде, которая уже заполнена основными объектами API, включая request , response , session , cache , DAL Field , HTML-помощников и средства проверки формы (другие части API, такие как Auth, Mail, Services, Scheduler,и многие дополнительные инструменты и внесенные библиотеки содержатся в модулях и импортируются как обычно).
В частности, request объект создается (при каждом запросе) внутри основного приложения WSGI (gluon.main.wsgibase) в этой строке, и впоследствии он передается в gluon.main.serve_controller в этой строке. serve_controller Функция добавляет request объект в среду выполнения, а затем выполняет файлы модели, контроллера и просмотра в этой среде.
В дополнение к файлам модели, контроллера и представления ваше приложение может включать свои собственные модули. Модули в приложениях не выполняются платформой (они должны быть импортированы) — следовательно, эти модули должны получать доступ к объектам API ядра web2py посредством импорта из gluon (объекты, зависящие от запроса, такие как request и response , доступны через current локальный объект потока, как описано здесь ).
Также может быть полезно просмотреть разделы документации о рабочем процессе, библиотеках и среде выполнения.
Ответ №2:
Файл, на который вы ссылаетесь, access.py , request впервые упоминает имя в строке 13:
http_host = request.env.http_host.split(':')[0]
Этот символ, request , не import редактируется ниоткуда. Это неортодоксальный способ написания программ на Python в целом, и по отдельности это выглядит невозможным. Но это возможно, если символ request был добавлен в глобальную рабочую область этого файла каким-либо другим файлом, который завершает выполнение access.py . Вот минимальный пример:
d = { 'request' : some_object() }
execfile( 'access.py', d ) # run the named file using d as its global workspace
Итак, в данном конкретном случае способ исследования — найти файл, который выполняется access.py .
[ В ответ на ваш комментарий об изучении каждого файла в библиотеке: для такого анализа и в целом для улучшения качества жизни программиста вам понадобится какой-нибудь инструмент, который может искать определенную строку во всей иерархии файлов (например, инструмент командной строки grep в Linux иmacOS или, как и многие сторонние текстовые редакторы и IDE в Windows, но не вечно ненадежная функция Windows «Search», которая утверждает, что может это сделать). ]
В ответ на ваш более общий вопрос о поиске того, откуда берутся вещи: В других ответах и комментариях упоминаются такие атрибуты, как __file__ и / или __module__ . Это может помочь, если у вас есть способ заставить ваш код выдавать отладочную информацию. Поскольку вы работаете с неконсольной (веб-) платформой, это может быть нетривиально, но одним из быстрых и грязных способов может быть вставка строки, подобной этой, в access.py :
open('some_temporary_file_somewhere.txt', 'wt').write('n'.join([
repr( request ),
request.__module__,
request.__class__,
])
Это должно дать вам подробную информацию о том, где request был определен класс (но не обязательно имя файла, в котором request был создан фактический экземпляр с именем).
Ответ №3:
При попытке выяснить, как элемент был импортирован в Python, вам нужно посмотреть на явные import инструкции в интересующем файле. В хорошо написанном коде это будет очевидно.
Если вы импортируете интересующий объект в оболочку python, вы можете использовать .__file__ атрибут для поиска файла байт-кода, из которого был импортирован этот объект. Существуют и другие подобные атрибуты, которые могут оказаться полезными, например
.__name__
.__path__
.__package__
Если вы используете IPython, что настоятельно рекомендуется, вы можете легко получить список этих методов двойного подчеркивания, введя <obj>.__ и нажав tab.
Глядя на файл, который вы связали, я не уверен, где request был импортирован. client , хотя, является атрибутом request объекта.
Комментарии:
1. Извините, но ваши предложения мне совсем не помогают, я ищу метод, который нацелен на источник элемента, я мог бы проверить все библиотеки, упомянутые в импорте, но это не очень умно, не так ли?