Mercurial developers: «You're much more likely to see a Py2.8 fork appear: that's a much easier project.»

А еще мы все умрем.

но первыми умрут(в информационном смысле этого слова) Py2k и те, у кого он прайм тул.

но первыми умрут(в информационном смысле этого слова) Py2k и те, у кого он прайм тул.

«Скажи мне, кудесник, любимец богов», когда это случится? %)

pep8, pychecker, pylint, pyflakes, pyunit.

Понимаю что всех проблем это не решит, но помощь в динамике и особенностях языка - нужная.

А в чем смысл писать на динамическом языке, если в итоге он превращается силами внешних утилит в статический? Со стороны выглядит как «Мы придумали себе проблему и героически её решаем».

А в чем смысл писать на динамическом языке, если в итоге он превращается силами внешних утилит в статический?

Если ты задаешь этот вопрос, то для тебя нет никакого смысла так писать :)

когда это случится?

судя по этому, осталось что-то около 4 лет максимум. http://mail.python.org/pipermail/python-dev/2010-May/099971.html

ОМГ и этим некоторые пытаются заменить git. Ужас.

судя по этому, осталось что-то около 4 лет максимум. http://mail.python.org/pipermail/python-dev/2010-May/099971.html

Ну ты же лгешь нам. Там английским по белому сказано «patchlevel releases for Python 2.7 will probably be made for at least 6 years», это значит, что еще 3.5 года _минимум_ (т.е. обещано минимум до 3 июля 2016). А за такое время любой тормоз успеет перейти на py3.

ОМГ и этим некоторые пытаются заменить git. Ужас.

А вот и троллемодераторы подтянулись.

В чем именно ужас?

за такое время любой тормоз успеет перейти на py3.
перейти

не это ли будет их информационной смертью? так что по-моему всё правильно. а _максимум_, потому что любой тормоз может сделать это и раньше, если пожелает.

правда, я сомневаюсь в том что, прямо таки, никто не останется на Py2k: останутся всякие информационные зомби/некрофилы, как обычно.

Извините, вырвалось :3.

Для меня непонятна идея базирования на старом инструментарии.

Как по мне, так лучше.

Страшно даже спросить, что ты думаешь про RHEL со сроком поддержки 10 лет.

Что здесь плохого? mercurial — удобная штука.

Нуууу смотря для чего.

ОК! А то ещё срач спровоцирую.

ОК! А то ещё срач спровоцирую.

Да, тяжело модераторское бремя :)

А в чем смысл писать на динамическом языке, если в итоге он превращается силами внешних утилит в статический?

у динамики есть очень большие преимущества перед статикой в плане интроспекции, сериализации итп.

В общем, у любой медали две стороны.

Для меня непонятна идея базирования на старом инструментарии.

инструментарий новый, вот яп старый. По ссылке ответ девелоперов почему так получилось.

Я под инструментарием подразумевал ЯП.

у любой медали две стороны

n - 1, где n метрика пространства ☺

Я под инструментарием подразумевал ЯП.

по-большому счёту, не так важно на каком языке написан хороший инструмент... Но осадочек остался, да :)

n - 1, где n метрика пространства ☺

дай угадаю, ты программист хаскелл, да? ☺

только, если медаль - это круг.

на самом деле, медаль - это цилиндр.

а цилиндр - подмножество тривиального касательного расслоения окружности.

логично предположить, что n-мерная медаль - это касательное расслоение (n-2)-сферы.

Не понял. Вот я джаву лучше всего знаю, буду с ней сравнивать. Интроспектируется всё, абсолютно. Разве что байт код метода вытащить надо будет чуток извратиться, всё остальное доступно. Сериализация, естественно, доступна без всяких усилий со стороны программиста (стандартная реализация требует пометить класс интерфейсом-маркером, но это исключительно тараканы тех, кто писал эту стандартную реализацию, доступны другие варианты). И т.п. хотелось бы подробнее понять. Всегда, когда пишу на динамическом языке, не понимаю, что я получаю взамен потери типизации и ловли ряда неприятных ошиьок на стадии компиляции. Минусы вижу, плюсов не вижу. Те плюсы пайтона, которые я вижу, с его типизацией не связаны вообще никак.

Для меня непонятно, как вообще может взбрести в голову ломать совместимость в широко используемом языке. Можно взять исходник на С 80-го года и скомпилить его компилятором 2012-го года, вот так надо соблюдать совместимость. А если переход на новую версию языка от не слишком большого проекта требует человекогода, неудивительно, что энтузиазмом никто не горит.

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

По поводу типизации. Мне ближе всего подход с интерфейсами (в хаскеле это type classes, для меня это интерфейсы). В питоне можно это сделать через абстрактные классы (ABC) этим мало кто пользуется.

Мне динамическая типизация (=отсутствие таковой) нравится когда надо передавать по сети произвольные объекты без всяких заморочек. (хотя, теоретически, это можно сделать в любом ООП языке где все данные имеют одного родителя типа object). В остальных случаях мне динамика стала мешать, поэтому я повтыкал в код type checker который по аннотации проверяет типы.

как вообще может взбрести в голову ломать совместимость в широко используемом языке.

это называется прогресс. Обратная совместимость мешает прогрессу. Мы же сейчас не сидим на программах из 80-х. А те что остались с тех пор 100500 раз были переписаны.

можно взять исходник на С 80-го года и скомпилить его компилятором 2012-го года

Нифига, я пробовал много древнего хлама собирать. Это помимо того что тупо может не быть нужных либ (какого-нить модуля turbo C). В самом gcc тоже, как известно, есть множество специфичных и ни с чем не совместимых расширений.

Основные недостатки питона, которые меня реально выбешивают, так и остались неисправленными

Какие недостатки?

P.S. не собираюсь разводить холивар, просто интересуюсь питончиком и мало о нём знаю.

Вот с типами уже сложнее. Хотя, надеюсь, новые IDE будут понимать аннотацию к функциям и ловить заранее.

У питона вообще сложный семантический анализ - в противовес парсингу, который намного проще парсинга C++. Чтобы сделать нормальные IDE, надо сделать движок на манер clang, который бы предоставлял для IDE абстрактный API, как это делает OpenGL для игр и как собирается сделать clang для плюсовых сред/редакторов.

Хочу запилить этот аналог, но пока только осваиваюсь с интеграцией clang в QtCreator ;( Хорошо если в январе что-нибудь начну по делу писать.

А функции надо использовать на манер темплейтов в C++ и концептов, так и не вошедших в новый стандарт: при парсинге функции сформировать требования к её формальным аргументам - например «должен быть оператор []» или «должен быть оператор [], возвращающий тип с методом printMe()» - а затем при использовании функции применять эти требования (концепты в C++) к фактическим аргументам. Но это так, задумка.

Хотя, о статике у меня скорей всего идеализированные представления, так как практического опыта явно не хватает.

Ну статические языки и по части эвристик далеко продвинулись - вон, компиляторы C++ уже сами почти всегда угадывают, какая именно переменная/метод и из какого неуказанного неймспейса имелась/имелся ввиду.

я повтыкал в код type checker который по аннотации проверяет типы

А можно подробнее? А то я для таких целей слабал декоратор, но ленюсь им пользоваться;-)

Интроспектируется всё, абсолютно. Разве что байт код метода вытащить надо будет чуток извратиться, всё остальное доступно.

Сложность слишком высокой может оказаться. А так из notepad.exe можно сделать эклипс подменой dll'ок, только где толпы желающих сделать это?

В вебе очень удобно поправить 1 строку и обновить страницу без всяких сборок.

Всегда, когда пишу на динамическом языке, не понимаю, что я получаю взамен потери типизации и ловли ряда неприятных ошиьок на стадии компиляции. Минусы вижу, плюсов не вижу.

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

Вот чё им мешало написать его на православном Си? Налепят на питонах, потом мучаются... и народ мучается, все мучаются... :)

Object[] ? :) Для использования придётся, правда, кастить, утиная типизация нормальными способами невозможна, но неужели оно надо? Используемый язык, конечно, накладывает отпечаток на стиль, но всё равно не могу представить, зачем это может понадобиться.

Сложность слишком высокой может оказаться. А так из notepad.exe можно сделать эклипс подменой dll'ок, только где толпы желающих сделать это?

Сложность интроспекции? Нет там ничего сложного, всё очень просто.

В вебе очень удобно поправить 1 строку и обновить страницу без всяких сборок.

С нормальными средствами разработки на джаве у меня точно так же происходит. Меняю строку, ктрл-ф9, альт-таб, ф5. От смены строки до обновления приложения ну может секунда, если несколько файлов пришлось обновить. Ну и опять же это вопрос инструментов и интерпретируемость/компилируемость, а не типизация, давай не отклоняться от темы :)

Вот чё им мешало написать его на православном Си?

Потому что у них нет в распоряжении армии хомячков, как у Линуса.

мучаются... и народ мучается, все мучаются... :)

Мучаются только не в меру добросердечные наблюдатели %)

я повтыкал в код type checker который по аннотации проверяет типы.

...в рантайме, конечно?

Кто мучается-то? :) «Админы», которые не могут наскрести сотню мегабайт на сервере-репозитории? Смешно. Перфекционисты, которым малейшее несовершенство мира выливается в батхерт? Они должны страдать, пусть.

стандартный линуксячий подход — зачем обновлять одну софтину, если можно обновить весь дистр и всё к херам сломать?

Ну статические языки и по части эвристик далеко продвинулись

Да, и это радует.

Блин, только сейчас дошло: mercurial написан на питоне? Бульбец Титанику!!! Надо срочно сваливать на приличную VCS с этого говнища.

А ведь снаружи — такая удобная была штука, кто бы мог подумать, что внутри сидит жирный червяк питон!

Эдди, где ты таким чудо-упорином затовариваешься?

Это ДНК такая!

Одним HG адептом меньше? Скандалы, интриги, расследования... показать всё что скрыто )))

Блин, только сейчас дошло: mercurial написан на питоне?

Ну ты просто эталонный слоупок. В палату мер и весов тебя бы.

я для таких целей слабал декоратор, но ленюсь им пользоваться;-)

я так же сделал. При запуске python -O декоратор ничего не делает. Это для самоуспокоения, а то я всё время нервничаю что питон тормозит :). К сожалению эта штука не умеет проверять содержимое контейнеров. Мне бы хотелось не просто задавать что этот аргумент, скажем, список, а чтобы оно знало что это список int. Ну и возврящаемое значение оно не проверяет, мне лень дописать три строчки.

Чтобы не вставлять везде декораторы тут есть метакласс.

#!/usr/bin/env python3
from itertools import chain
import inspect
import sys


def assert_isinstance(v, expected):
  if not isinstance(v, expected):
    actual = type(v)
    raise AssertionError(
      "Expected type {expected}, got {actual}".format(**locals()))


#TODO: check return value
def type_check(f):
  try:
    argspec = inspect.getfullargspec(f)
  except TypeError:
    # print("cannot inspect", f)
    return f
  annotations = argspec.annotations
  if not annotations:
    return f
  names = argspec.args
  def wrapper(*vs, **kvs):
    for name, v in chain(zip(names, vs), kvs.items()):
      typ = annotations.get(name, object)
      assert_isinstance(v, typ)
    return f(*vs, **kvs)
  return wrapper


if not __debug__:
  print("notice: type checking disabled", file=sys.stderr)
  type_check = lambda f: f


class CheckTypes(type):
    def __new__(self, name, bases, ns):
        new_ns = {}
        for attr, value in ns.items():
            if callable(value):
              new_ns[attr] = type_check(value)
            else:
              new_ns[attr] = value
        return type.__new__(self, name, bases, new_ns)


if __name__ == '__main__':
  @type_check
  def test(name:str, greeting:str="Hello,"):
    print(greeting, name)

  test("isden", greeting=1)