Задачи | 3 уровень | 8 лекция

Для потомков добавлю, что под реализацию на javarush подойдут только версии sun.xml.bind.jaxb.impl 2.3.х Не 3.х.х и не 4.х.х, а именно 2.3.х краткая история вопроса MKyoung ps Сайт в закладочки

так и есть! в питоне насколько я помню тоже что-то подобное есть) вроде как поетри называется, но это, как говориться, не точно) сейчас же все развивается и в том числе в пайтоне есть инструменты, которые позволяют фактически "превращать" его из ЯП с динамической в ЯП в практически строгой типизацией (исходя из типа данных ожидаемых на вход методам и функциям) и т.д. Та же Джава исходно ООП язык постепенно прирастает функциональщиной. все развивается, обрастает новыми технологиями и т.д. но базовые базы лучше знать чем не знать ...

Ну да согласен! В пайтоне есть такая штука, если вы ее имели ввиду:

def recurse(n: int) -> int:
    if n <= 1:
        return
    for i in range(2, n + 1):
        if n % i == 0:
            print(i, end=' ')
            recurse(int(n / i))
            break


recurse(132)

т.е тут в параметрах функции мы после ":" указываем тип ожидаемого аргумента, а тот тип что функция должна вернуть указываем после "->". Тут у меня и там и там тип "int". Однако заметьте, это не то же самое что в java строгая статическая типизация, это просто рекомендация, некая справочная информация разработчику что там должно в функцию приходить и уходить. Но вы можете все равно написать там что хотите, например вещественное число, ошибки не будет и вас об этом никак не предупредят не на этапе написания кода, не на этапе его выполнения. А вот Java тут же подчеркнет. Да в java есть лямбды (как по мне удобнее чем в пайтоне), правда это дело вкуса, ссылки на методы/конструкторы, стримы... В пайтоне же очень сильные функции, и послабее ООП чем в java, есть сложности с инкапсуляцией в частности там. А вообще оба языка классные и гибкие, очень мощные, каждый по-своему. Ну а так Java более масштабен и фундаментален по ряду причин.

По поводу проблем с инкапсуляцией в питоне - согласен. Спасибо за наглядный пример! На мой взгляд, несколько больнее будет в Пайтоне в том случае, когда в сигнатуре метода (функции) ожидается буллево значение, а прилетает туда что угодно, начиная от целого числа, и, заканчивая строкой (вроде как со строками и списками эту проблему исправили...). Как Вы помните в Пайтоне: bool(1) == 1 True bool(0) == 0 True Т.е. по факту вся логика кода может отработать без ошибок (код - валиден с формальной точки зрения), но результат его выполнения будет не корректен в целом. И такие ошибки в дальнейшем сложно будет выявлять и исправлять. Поэтому по факту каждый параметр в Пайтоне следует проверять на принадлежность даже не к типу (isinstance() - привет ув. Барбаре Лискофф), a на принадлежность к конкретному классу (if type(a) == bool: ...). Но я говорил о конкретном (-ых) инструменте, реализованном для Пайтона, который позволяет избежать эти проверки для каждого параметра метода (функции): библиотеки (модули) dataclasses, inspect Или как вариант написать свои датаклассы с авторской логикой проверки на подаваемый тип (класс) данных. Либо же проверки на типы данных реализовать в сеттерах, а поля с сеттерами определить как properties (для них автоматом отрабатывают сеттеры и геттеры при обращении к объекту класса, и даже его создании)... P.S. Автоматическое приведение в питоне 1 к True, а 0 к False и обратно исправлять (?) навряд ли будут, т.к. это приведет к потере возможности писать элегантный код, - одной из фишек Питона, к слову сказать. Например: <some code> answer = ["no", "yes"] print(answer[some_digit < 0]) <some code>

А какие нужные то в данном случае?

Судя по всему, все по-разному выходят из этой ситуации. В моем случае работает так. File - Project Structure - Project Settings - Libraries -> + -> From Maven... в строку поиска ввести jaxb.impl и выбрать версию 2.3.4 -> ОК -> Apply.

да)