dynamic vs static

[juan_gandhi]

Я не собираюсь вступать в эту нонешнюю дискуссию. Просто хочу заметить, что речь идёт о "гарвардской архитектуре" супротив "архитектуры фон Неймана".

В первой данные отделены от кода, и задача программиста состоит в том, чтобы состыковать, хоть и через посредников, данные и код, который их обрабатывает; вот и приходится катать всякие конфигурации, эксэмэли, ентити бинзы; всё для того, чтобы уберечь код от данных. Тогда код можно статически проверить и отлить в бронзе. Чтоб не сломался.

Во второй что данные, что код, без разницы; код - это вид данных, а данные могут на определённом уровне интерпретироваться как код, или строить код, который эти данные сынтепретирует (как, помню, была какая-то база, которая строила классы для доступа прямо при открытии таблицы: взял таблицу - вот и классы загрузились; естественно, что динамически.

Ну а так, наверное, стоит почитать, конечно: Егге устраивает разгром в столице статической типизации

Comments

[faceted-jacinth.livejournal.com]

Ну, это помимо того очевидного факта, что обычный CPython таки компилит питон в байткод, сохраняя его в файликах с расширением ".pyc", так что моё утверждение что имена _обычных_ функций (не методов, а обычных функций) могут быть отрезолвлены в адреса на этапе компиляции остаётся не только истинным, но и абсолютно корректным.

[nine_k]

Байткод остаётся таким же динамическим, это просто грамотно уплощённое AST ;)

Т.е. разрешение имён и разрешение порядка наследования(aka MRO) как происходило в runtime, так и происходит. И любой объект (например, метод объекта или функцию), на которое ссылается заданное имя, всё так же можно переопределить в любой точке исполнения.

Потому гарантировать, что в данной точке программы данное имя разрешается в указанный объект в общем случае становится очень трудно в сравнении со статическими более-менее процедурными языками. (В то время как в чистом fp это, конечно, вообще тривиально.)

[faceted-jacinth.livejournal.com]

Я всегда открыт для новых открытий, пусть у меня есть модуль fj, в котором на верхнем уровне лежит

def a():
  print "a"

def b():
 a()

у вас же есть свой модуль, в котором вы можете сделать from fj import *, а потом в какой-то момент вызвать b(). Расскажите пожалуйста, как вы сделаете так, чтобы в результате не напечаталось "а"? Ну, раз всё разрешение имён якобы происходит в рантайме, вы же сможете подсунуть моему b() свою а(), правда?

[nine_k]

С удовольствием подсуну. Но дело, как вы правильно замечаете, хитрее, чем кажется.

$ cat fj.py
def a():
   print "fj's a"

def b():
   a()
   foo()

Добавим для наглядности вызов некоторой неизвестно где определённой функции foo, которую надо искать "снаружи".

$ python
Python 2.4.5 (#2, Apr 17 2008, 13:00:52) 
[GCC 4.2.3 (Debian 4.2.3-3)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from fj import *
>>> b()
fj's a
Traceback (most recent call last):
  File "", line 1, in ?
  File "fj.py", line 6, in b
    foo()
NameError: global name 'foo' is not defined

Всё предсказуемо: зовётся a из нашего модуля, а foo не находится.

>>> def foo():
...   print "foo from outer scope"
... 
>>> b()
fj's a
Traceback (most recent call last):
  File "", line 1, in ?
  File "fj.py", line 6, in b
    foo()
NameError: global name 'foo' is not defined

Ага, foo опять не находится!
Это потому, что scope-ов много, по одному на code block. В частности, у модуля свой scope, имена в импортированном модуле разрешаются только в нём, а "выше", на уровень импортирующего, не заходят. Импортирующий же код не портит нечаянно имена в импортированном.
Но это не значит, что scope модуля нельзя поменять :)

>>> import fj
>>> fj.foo = foo
>>> b()
fj's a
foo from outer scope

Теперь, когда мы имеем удобное имя для модуля, мы лезем в его scope и вписываем туда имя своей функции. И всё срабатывает.
Сстановится вдруг понятно, почему, если 10 импортированных нами модулей вызывают в своём коде функцию a(), они получают каждый свою. И ясно, как подсунуть другую a().

>>> def not_a():
...   print "ceci n'est une a"
... 
>>> fj.a = not_a
>>> b()
ceci n'est une a
foo from outer scope
>>> _

Вот как-то так, мне кажется.

Мои извинения хозяину журнала, которому всё это приходит на почту %) 御免なさい!

[faceted-jacinth.livejournal.com]

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

По поводу импорта -- да, видимо так всё и работает. Я хотел сказать, что происходящее в процессе тоже не вполне укладывается в представление о питоне как о чисто скриптовом, с одной стороны импорт вроде бы просто исполняет модуль и добавляет его имя в локальный scope, с другой -- имеем это вот ровно двухкратное исполнение.

[nine_k]

Кстати сказать, пока я не порылся немного в спецификациях, я тоже думал, что я неправ, и готовился вежливо признать поражение :)

Да, если нужен ещё более "чисто скриптовый" — это, наверное, ruby в его исходной реализации, там напрямую по дереву ходят при исполнении (естетственно, это тормозит). В rubinius вроде сделали фазу компиляции во что-то (но не напрямую в байткод jvm).