Архив метки: Python основы

Импортирование и области видимости

Как  мы  уже  знаем,  невозможно  получить  доступ  к  именам,  определенным в другом модуле, не импортировав его предварительно. То есть вы никогда автоматически не получите доступ к именам в другом файле, независимо от вида импортируемого модуля и вызовов функций в вашей программе. Смысл переменной всегда определяется местоположением операции присваивания в программном коде, а для обращения к атрибутам всегда необходимо явно указывать объект.


Например,  рассмотрим  два  следующих  простых  модуля.  Первый, в файле  moda.py,
определяет переменную X, которая является глобальной только для программного кода в этом файле, и функцию, изменяющую глобальную переменную X 
в этом файле:
X = 88         # Переменная X: глобальная только для этого файла
def f():
    global X   # Изменяет переменную X в этом файле
    X = 99     # Имена в других модулях недоступны
Второй модуль, modb.py, определяет свою собственную глобальную перемен-
ную X, а также импортирует и вызывает функцию из первого модуля:
X = 11         # Переменная X: глобальная только для этого файла 

import moda    # Получает доступ к именам в модуле moda
moda.f()       # Изменяет переменную moda.X, но не X в этом файле
print X, moda.X

При запуске этого модуля функция moda.f изменит переменную X в модуле moda, а не в modb. Глобальной областью видимости для функции moda.f всегда является файл, вмещающий ее, независимо от того, из какого модуля она была вызвана:
% python modb.py
11 99
Другими словами, операция импортирования никогда не изменяет область видимости для программного кода в импортируемом файле – из импортируемого файла нельзя получить доступ к именам в импортирующем файле. Если быть более точным:

  • Функциям никогда не будут доступны имена, определенные в других функциях, если только они физически не вложены друг в друга.
  • Программному коду модуля никогда не будут доступны имена, определенные в других модулях, если только они явно не были импортированы.

Это  поведение  является  частью  понятия  лексической  области  видимости  –
в языке Python области   видимости, доступные части программного кода полностью  определяются  физическим  расположением  этого  программного  кода
в файле. Области видимости не подвержены влияниям вызовов функций или
операции импортирования.

Автор: Няшный Человек
Дата публикации: 2015-10-04T08:43:00.000+03:00

Что бы вы хотели узнать?

Все наверно заметили что большинство статей взяты из книги… что кстати не скрывалось. Из книги копировать скучно и не интересно… 

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

Автор: Няшный Человек
Дата публикации: 2015-05-19T13:12:00.001+03:00

Квалификация имен атрибутов

Здравствуйте посетители и читатели. Перед тем как начну, хочу поздравить всех с наступившим новым 2015 годом и с прошедшими праздниками. Ну и всем удачи и успехов в поисках работы или же просто в работе… так как от нее будет зависеть — то, на сколько Вам сладко придется жить 🙂

Немного напомню, что в моих постах информации из замечательной книги… Сам я в питоне пока не шарю, так как я веб программист который в основном сталкивается с РНР,НТМЛ и т.д. — но в последнее время ЯваСкрипт начинает нравиться… думаю скоро выложить на своем втором блоге — про рнр информацию о том, на сколько нужно шарить, чтоб пройти хотяб на джуниора и немножко выше, а так же я постараюсь создать блог на yii с небольшим обьяснением. Ну и собственно ссылка на мой второй блог — http://phpekurs.blogspot.com/ надеюсь я не буду затягивать со временем выпуска материалов как это бывает с этим блогом. Ну что ж, теперь приступим к теме….

После  ознакомления  с модулями  мы  должны  поближе  рассмотреть  понятие квалификации имен. В языке Pythonдля доступа к атрибутам любого объекта используется синтаксис квалификации имени object.attribute.


Квалификация имени в действительности является выражением, возвращаю-щим  значение,  присвоенное  имени  атрибута,  ассоциированного  с объектом.

Например,  выражение module2.sys в предыдущем  примере  возвращает  значение атрибута sys в объекте module2. Точно так же, если имеется встроенный объект списка L, выражение L.append вернет метод append, ассоциированный с этим списком.

Итак, какую роль играет квалификация имен атрибутов с точки зрения правил, рассмотренных нами в главе 17? В действительности – никакую: это совер-шенно независимые понятия. Когда вы обращаетесь к именам, квалифицируя их,  вы  явно  указываете  интерпретатору  объект,  атрибут  которого  требуется получить. Правило LEGB применяется только к кратким, неполным именам. Ниже приводятся принятые правила:
Простые переменные
Использование краткой формы имени, например X, означает, что будет про-изведен поиск этого имени в текущих областях видимости (следуя правилу LEGB).

Квалифицированные имена
Имя X.Y означает, что будет произведен поиск имени X в текущих областях
видимости, а затем будет выполнен поиск атрибута Y в объекте X(не в областях видимости).

Квалифицированные пути
Имя X.Y.Z означает, что будет произведен поиск имени Y в объекте X, а затем
поиск имени Z в объекте X.Y.

Общий случай
Квалификация  имен  применима  ко  всем  объектам,  имеющим  атрибуты:
 модулям, классам, расширениям типов на языке Cи так далее.

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

Автор: Няшный Человек
Дата публикации: 2015-01-13T21:11:00.000+02:00

Когда использовать import

И так, в предыдущем посте, было рассказано о минусах инструкции from и о том, что использование import более надежней и практичней. Поэтому речь пойдет о использовании import.


Единственное,  когда  необходимо  вместо  инструкции  from  использовать  инструкцию import, – когда требуется использовать одно и то же имя, присутствующее в двух разных модулях. Например, когда два файла по-разному определяют одно и то же имя:
# M.py

def func():
    …выполнить что-то одно…

# N.py

def func():
    …выполнить что-то другое…
и необходимо использовать обе версии имени в программе. В этом случае инструкцию from использовать нельзя, потому что в результате вы получите единственное имя в вашей области видимости:
# O.py

from M import func
from N import func     # Перезапишет имя, импортированное из модуля M
func()                 # Будет вызвана N.func
Зато  можно  использовать  инструкцию  import,  потому  что  включение  имени

вмещающего модуля сделает имена уникальными:

# O.py
 
import M, N    # Получить модуль целиком, а не отдельные имена
M.func()       # Теперь можно вызывать обе функции
N.func()       # Наличие имени модуля делает их уникальными
Этот случай достаточно необычен, поэтому вы вряд ли часто будете сталкиваться с ним на практике. Но если такая ситуация все-таки возникнет, инструкция import позволит вам избежать конфликта имен.
Фух, за день две статьи, спасибо за подписи, надеюсь количество увеличиться и увеличится количество статей. Ставим + , приглашаем друзей и комментируйте записи.

Автор: Няшный Человек
Дата публикации: 2014-05-25T11:42:00.002+03:00

Минусы инструкции from

Здравствуйте читатели. Ну что, вот вам еще очередная порция текста по программированию используя Python )
На этот раз речь пойдет о минусах использовании инструкции from.




 — У инструкции from менее явное отображение переменной (имя name несет меньше информации, чем module.name), поэтому некоторые пользователи Python  рекомендуют  использовать  инструкцию  import  вместо from. Но это иногда можно опровергнуть, так как такой использование from происходит довольно таки часто и без страшных последствий.

 — Инструкция from способна повреждать пространства имен, по крайней мере, в принципе – если использовать ее для импортирования переменных, когда существуют одноименные переменные в имеющейся области видимости, то эти переменные просто будут перезаписаны. Эта проблема отсутствует при использовании инструкции import, потому что доступ к содержимому импортируемого модуля возможен только через его имя (имя module.attr не конфликтует с именем attr в текущей области видимости). 
Пока вы понимаете и контролируете все, что может происходить при использовании инструкции from, во всем этом нет большой проблемы, особенно если импортируемые имена указываются явно (например, from module import x, y, z).

С другой стороны, инструкция from скрывает в себе более серьезные проблемы, когда используется в комбинации с функцией reload, так как импортированные имена могут ссылаться на предыдущие версии объектов. Кроме того, инструкция в форме from module import * действительно может повреждать пространства имен и затрудняет понимание имен, особенно когда она применяется более чем к одному файлу, – в этом случае нет никакого способа определить, какому модулю принадлежит то или иное имя, разве только выполнить поиск по файлам с исходными текстами. В действительности форма from * вставляет одно пространство имен в другое, что сводит на нет преимущества, которые несет возможность разделения пространств имен.

Пожалуй, лучший совет, который можн