модули python отсутствуют в шалфее

У меня установлен Sage 4.7.1, и я столкнулся со странной проблемой. Многие из моих старых скриптов, использующих такие функции, как deepcopy() и uniq(), больше не распознают их как глобальные имена. Я смог исправить это, импортировав модули Python один за другим, но это довольно утомительно. Но когда я запускаю интерфейс Sage из командной строки, я могу ввести «list2=deepcopy(list1)» без импорта модуля копирования, и это работает нормально. Как возможно, что командная строка Sage может распознавать глобальное имя «deepcopy», но если я загружаю свой скрипт, который использует то же имя, он его не распознает?

ой, извините, я еще не знаком со stackoverflow. Я набираю: «sage_4.7.1/sage», чтобы запустить интерфейс командной строки; затем я набираю «load jbom.py», чтобы загрузить все функции, которые я определил в скрипте Python. Когда я использую одну из функций из скрипта , он работает в течение нескольких секунд (сложная функция), затем попадает в место, где я использую некоторую функцию, которую Sage обычно имеет в качестве глобального имени (deepcopy, uniq и т. д.), но по какой-то причине загруженный мной скрипт не знает, что это за функция Повторюсь, мой скрипт jbom.py работал, когда я в последний раз работал над этим конкретным исследованием, как я и описал.

Также не имеет значения, использую ли я «загрузить jbom.py» или «импортировать jbom». Оба метода получают функции, которые я определил в своем сценарии (но во втором случае я должен использовать jbom.), и оба получают одну и ту же ошибку о том, что «deepcopy» не является глобальным именем.

ОТВЕТ DSM: Я небрежно описал проблему, за что прошу прощения. Я создал новый скрипт «experiment.py», в первой строке которого есть «import jbom». Выполнение функции в Experiment.py распознает функции в jbom.py, но глубокая копия не распознается. Я попытался загрузить jbom.py как «загрузить jbom.py», и я могу использовать функции так же, как и несколько месяцев назад. Итак, это всего лишь проблема наслоения скриптов без надлежащего использования импорта/загрузки и т. д.?

РЕШЕНО: я добавил «из sage.all import *» в начало jbom.py, и теперь я могу без проблем загружать Experiment.py и выполнять функции, вызывающие функции jbom.py. Из документа Sage по импорту/загрузке я не могу точно сказать, что именно я делал неправильно.


person mjenista    schedule 22.07.2012    source источник
comment
Как вы устанавливали sage? Компиляция из исходников?.. Насколько я помню, там свой питон и все такое. Вы можете принудительно запустить свои старые скрипты с помощью стандартного Python, чтобы изолировать проблемы.   -  person spacediver    schedule 22.07.2012
comment
Что означает загрузить мой скрипт? В Sage 4.7.1 должно быть доступно deepcopy.   -  person DSM    schedule 22.07.2012
comment
Я не могу воспроизвести это, хотя самый старый Sage, который у меня есть, - 4.7.2. Однострочная программа print deepcopy работает для меня, когда я load jbom.py (поскольку это прославленный execfile, и поэтому deepcopy находится в области видимости, даже если она не обрабатывается, потому что это файл .py), но не когда я ее импортирую (поскольку указанный модуль Python не волшебным образом не получить доступ к именам мудрецов и требует from sage.all import *). Не могли бы вы вырезать из файла jbom.py все, кроме того, что необходимо для воспроизведения проблемы, и вставить это?   -  person DSM    schedule 22.07.2012


Ответы (1)


Хорошо, вот что происходит:

Вы можете использовать только import файлы, оканчивающиеся на .py (игнорируя .py[co]). Это стандартные файлы Python и они не подготовлены, поэтому 1/3 == int(0), а не QQ(1)/QQ(3), и у вас нет эквивалента from sage.all import * для игры.

Вы можете load и attach как файлы .py, так и .sage (а также .pyx и .spyx и .m). Оба имеют доступ к определениям Sage, но файлы .py не подготовлены (поэтому y=17 делает y Python int), а файлы .sage готовы (поэтому y=17 делает y Sage Integer).

Таким образом, import jbom здесь работает так же, как и в Python, и вы не получаете доступ к тому, что Sage поместил в область видимости. load и т. д. удобны, но они не так хорошо масштабируются для больших программ. Я предлагал улучшить это в прошлом и сделать сценарии .sage менее гражданами второго сорта, но пока не было достигнуто согласия относительно того, что делать, и энергии для этого. А пока лучше всего импортировать из sage.all.

person DSM    schedule 22.07.2012
comment
Спасибо! Это также может объяснить некоторое странное поведение, которое я видел при использовании деления, и результаты оказались отличными от того, что я ожидал. - person mjenista; 22.07.2012