Архив рубрики: Python

Понимаем UnboundLocalError

Опять же на programmingwats.tumblr.com наткнулся на небольшую особенность питона.

my_str_1 = «1: outside of func»
my_str_2 = «2: outside of func»
def func_1():
    my_str_1 = «1: inside the func»
    my_str_2 = «2: inside the func»
    def func_2():
        print(my_str_1)
        print(my_str_2)
        my_str_1 = «1: inside the class»
    func_2()

func_1()
prints:
Traceback (most recent call last):
  File “”, line 1, in
  File “”, line 8, in func_1
  File “”, line 5, in func_2
UnboundLocalError: local variable ‘my_str_1’ referenced before assignment

В принципе на эту тему написано довольно много постов и погуглив можно спокойно найти объяснение. Но т.к. в свое время эта особенность питона попила у меня много кровушки я решил написать небольшой пост.

В чем причина такого поведения?
Причина заключается в том что питон преобразует переменную my_str_1 в локальную для func_2 и во время вызова функции print получает на вход не инициализированную переменную.
Решения проблемы тривиальные — либо убрать print, либо изменить название переменной, или объявить my_str_1 как глобальную.

Кто хочет более подробно ознакомиться с причинами такого поведения см ссылки, особенно с [2]

Ссылки

[1]https://docs.python.org/2/faq/programming.html#why-am-i-getting-an-unboundlocalerror-when-the-variable-has-a-value
[2]http://eli.thegreenplace.net/2011/05/15/understanding-unboundlocalerror-in-python/
[3]http://programmingwats.tumblr.com/page/2

Автор: Евгений Курочкин

python 2 утечка переменных цикла

Проглядывая programmingwats.tumblr.com нашел небольшую особенность python 2.

Посмотрим на пример:

>>>x = «top»
>>>print(list(«a» for x in (1,2)), x)
>>>print([«a» for x in (1,2)], x)

([‘a’, ‘a’], ‘top’)
([‘a’, ‘a’], 2)

Это бага питона, связанная с тем что локальная переменная x, используемая при создании списка становилась доступной в родительском пространстве имен. Думаю понятно чем грозит данная бага.
Данная бага поправлена в python 3.

Ссылки

https://docs.python.org/3/whatsnew/3.0.html#changed-syntax
http://programmingwats.tumblr.com/page/2
http://nbviewer.ipython.org/github/rasbt/python_reference/blob/master/tutorials/key_differences_between_python_2_and_3.ipynb?create=1

Автор: Евгений Курочкин

Когда использовать 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 * вставляет одно пространство имен в другое, что сводит на нет преимущества, которые несет возможность разделения пространств имен.

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

изменяемый объект в аргументах

Тема замусолена до невозможности, но не удержался увидев код Request

def func(f, l=[]):
    l.append(f)
    return l

func является потенциально опасной. Смотрим что происходит при её использовании

>>> print(func(1))
[1]
>>> print(func(2))
[1, 2]


l ссылается на один и тот же объект, который все время и изменяется (вспоминаем концепцию python)

Решение очевидное — определить список в функции

Такое решение используется и в популярном фреймворке request

class Request(RequestHooksMixin):
    def __init__(self,
        method=None,
        url=None,
        headers=None,
        files=None,
        data=None,
        params=None,
        auth=None,
        cookies=None,
        hooks=None):

        # Default empty dicts for dict params.
        data = [] if data is None else data
        files = [] if files is None else files
        headers = {} if headers is None else headers
        params = {} if params is None else params
        hooks = {} if hooks is None else hooks

Ссылки

https://github.com/kennethreitz/requests/blob/master/requests/models.py

Автор: Евгений Курочкин

Ельцин и питон

В доке питона по sqlite3 обнаружил Ельцина

import sqlite3

con = sqlite3.connect(":memory:")
cur = con.cursor()
cur.execute("create table people (name_last, age)")

who = "Yeltsin"
age = 72

# This is the qmark style:
cur.execute("insert into people values (?, ?)", (who, age))

# And this is the named style:
cur.execute("select * from people where name_last=:who and age=:age", {"who": who, "age": age})

print cur.fetchone()


Судя по дате создания модуля sqlite — это именно Борис

Ссылка


https://docs.python.org/2/library/sqlite3.html#cursor-objects

Автор: Евгений Курочкин