LINUX.ORG.RU

Python 3.7

 


5

8

Спустя полтора года после выхода предыдущей мажорной версии, наконец-то состоялся релиз Python 3.7.

В этом выпуске

  • Улучшена поддержка аннотации типов
  • Data classes
  • Атрибуты модулей
  • Отладка с помощью breakpoint()
  • И многое другое

PEP 563, Отложенное исполнение аннотаций типов

Теперь аннотации разрешаются в момент вызова функции, а не в момент загрузки её кода. Это уменьшает время старта программы и делает доступным использование имён, определённых позднее самой функции (forward references).

Такой код вызывал бы ошибку в предыдущих версиях Python

class C:
    @classmethod
    def from_string(cls, source: str) -> C:
        ...

    def validate_b(self, obj: B) -> bool:
        ...

class B:
    ...

Это изменение нарушает совместимость, поэтому до прихода версии Python 4.0 пока требует

from __future__ import annotations

PEP 553, Встроенная функция breakpoint()

Отладка стала ещё проще! Допустим, у вас есть такой код

def divide(e, f):
    return f / e

a, b = 0, 1
print(divide(a, b))

В предыдущих версиях для отладки вам требовалось:

def divide(e, f):
    import pdb; pdb.set_trace()
    return f / e

В 3.7 это выглядит проще и короче

def divide(e, f):
    breakpoint()
    return f / e

Теперь запускайте ваш код:

$ python3.7 bugs.py 
> /home/gahjelle/bugs.py(3)divide()
-> return f / e
(Pdb)

По умолчанию breakpoint() просто заменяется на import pdb; pdb.set_trace(), однако это можно изменить. Скажем, вы можете использовать другой отладчик:

$ PYTHONBREAKPOINT=pudb.set_trace python3.7 bugs.py
Или отключить отладку вовсе
$ PYTHONBREAKPOINT=0 python3.7 bugs.py
ZeroDivisionError: division by zero
Или запустить IPython
$ PYTHONBREAKPOINT=IPython.embed python3.7 bugs.py 
IPython 6.3.1 -- An enhanced Interactive Python. Type '?' for help.

In [1]: print(e / f)
0.0
В конечном счёте, вы можете написать свой собственный обработчик breakpoint()

PEP 557, Data Classes

Новый модуль dataclasses делает более удобным написание классов, основная задача которых — хранить данные. Вы просто используете декоратор, и весь бойлерплейт пишется за вас.

from dataclasses import dataclass, field

@dataclass(order=True)
class Country:
    name: str
    population: int
    area: float = field(repr=False, compare=False)
    coastline: float = 0

    def beach_per_person(self):
        """Meters of coastline per person"""
        return (self.coastline * 1000) / self.population

Методы __init__, __repr__, __eq__, __ne__, __lt__, __le__, __gt__, __ge__ будут сгенерированы автоматически для класса Country

PEP 562, Кастомизация атрибутов модулей

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

PEP 564, Временны́е функции с наносекундным разрешением

Улучшен модуль time, добавлено несколько новых функций

time.clock_gettime_ns()
time.clock_settime_ns()
time.monotonic_ns()
time.perf_counter_ns()
time.process_time_ns()
time.time_ns()
Точность расчёта временных интервалов повышена до наносекунд

Упорядоченные словари

Порядок ключей в словарях теперь гарантированно совпадает с порядком их вставки, это добавлено в спецификацию.

>>> {"one": 1, "two": 2, "three": 3}  # Python <= 3.5
{'three': 3, 'one': 1, 'two': 2}

>>> {"one": 1, "two": 2, "three": 3}  # Python >= 3.6
{'one': 1, 'two': 2, 'three': 3}

Это работало ещё с версии 3.6, однако опиралось на внутреннюю реализацию словарей CPython, и полагаться на такой порядок было нельзя.

Новые ключевые слова: async и await

Корутины с async и await были введены в Python 3.5, однако для обратной совмесимости всё ещё можно было объявить переменные с такими именами. Теперь это будет выдавать ошибку.

>>> async = 1
  File "<stdin>", line 1
    async = 1
          ^
SyntaxError: invalid syntax

>>> def await():
  File "<stdin>", line 1
    def await():
            ^
SyntaxError: invalid syntax

Улучшение модуля asyncio

Модуль asyncio для поддержки асинхронности был представлен в Python 3.4 (введение). В Python 3.7 asyncio получил большое количество новых функций, поддержку контекстных переменных и улучшения производительности. Например, используя asyncio.run(), вы можете легко вызывать корутины из синхронного кода, не создавая event loop.

import asyncio

async def hello_world():
    print("Hello World!")

asyncio.run(hello_world())

PEP 567, Контекстные переменные

Контекстные переменные — это переменные, которые могут иметь различные значения в зависимости от окружения. Они похожи на Thread-Local Storage, в которых каждый исполняемый тред может иметь разное значение переменной, однако контекстные переменные могут иметь разные значение даже в пределах одного треда. Основная область применения — параллельные асинхронные задачи.

import contextvars

name = contextvars.ContextVar("name")
contexts = list()

def greet():
    print(f"Hello {name.get()}")

# Construct contexts and set the context variable name
for first_name in ["Steve", "Dina", "Harry"]:
    ctx = contextvars.copy_context()
    ctx.run(name.set, first_name)
    contexts.append(ctx)

# Run greet function inside each context
for ctx in reversed(contexts):
    ctx.run(greet)

Запуск скрипта приветствует Steve, Dina, и Harry в обратном порядке:

$ python3.7 context_demo.py
Hello Harry
Hello Dina
Hello Steve

Импорт файлов с данными с помощью importlib.resources

Как происходила упаковка ресурсов в пакет до Python 3.7? Обычно выбирали один из трёх способов

  • Захардкоженные пути к ресурсам
  • Поместить файлы внурь пакета и получать к ним доступ с помощью __file__
  • Использовать setuptools.pkg_resources

Первый способ не портируем. Второй подходит лучше, но если Python-пакет находится внутрь zip архива, то там не будет атрибута __file__, что создает проблемы. Третий способ работает, однако слишком медленный.

Теперь появляется ещё один способ: новый модуль importlib.resources в стандартной библиотеке. Он использует уже существующую функциональность импорта модулей для загрузки файлов. Допустим, у вас есть ресурсы внутри пакета:

data/
│
├── alice_in_wonderland.txt
└── __init__.py

Теперь вы можете получить доступ к alice_in_wonderland.txt следующим образом:

>>> from importlib import resources
>>> with resources.open_text("data", "alice_in_wonderland.txt") as fid:
...     alice = fid.readlines()
... 
>>> print("".join(alice[:7]))
CHAPTER I. Down the Rabbit-Hole

Alice was beginning to get very tired of sitting by her sister on the
bank, and of having nothing to do: once or twice she had peeped into the
book her sister was reading, but it had no pictures or conversations in
it, ‘and what is the use of a book,’ thought Alice ‘without pictures or
conversations?’

Похожая функция resources.open_binary() открывает файлы в бинарном режиме.

Оптимизации

Ни один релиз Python не обходится без набора оптимизаций. Python 3.7 не стал исключением:

  • Снижены накладные расходы при вызове многих методов из стандартной библиотеки
  • В целом методы теперь вызываются на 20% быстрее
  • Время запуска самого Python снижено на 10-30%
  • Импортирование typing теперь быстрее в 7 раз.

Различные лучшения CPython

  • Уход от ASCII как от дефолтной кодировки:
  • PEP 552, Воспроизводимые .pycs
  • Новая опция -X
    $ python3.7 -X importtime my_script.py
    import time: self [us] | cumulative | imported package
    import time:      2607 |       2607 | _frozen_importlib_external
    ...
    import time:       844 |      28866 |   importlib.resources
    import time:       404 |      30434 | plugins
    
    Вы также можете использовать -X dev для активации «режима разработки» и -X utf8 для активации режима UTF-8. Полный список опций.
  • PEP 565, улучшенная обработка DeprecationWarning

Новость на Real Python

>>> Официальный обзор изменений

★★★★★

Проверено: tailgunner ()
Последнее исправление: tailgunner (всего исправлений: 5)
Ответ на: комментарий от tailgunner

Что сложного? Да всё практически. Я даже не знаю, с чего начать, если честно. Тут ведь настаивают на том, что питон очень простой язык.

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

Объявление абстрактных классов (и абстрактных методов). Обычно это просто ключевое слово, модификатор, всё тупо и понятно. В питоне же очевидно какая-то глубокая манипуляция непонятно чем, нетривиальная катавасия. Чтобы эти криптические записи приобрели какой-то смысл (а не просто оставались мутной копипастой), надо, видимо, разбираться в питоней замудреной объектной модели. Для вас это просто? Завидую! Но не считаю, что «питон простой язык».

Хорошо, вот тут сообщением выше обсуждает многопоточность в питоне. По наивности некоторые могут посчитать (и считают), что GIL упрощает, т.е. многие операции становятся безопасными. Например доступ к элементами словаря. Но для этого нужно чтобы внутри самого захватывался этот гил в правильных местах (насколько я себе это понимаю). Однозначных железных ответов в документации я не нашел. В книге к примеру Martelli буквально одна-две строчки мутных осторожных слов. Что указывает на пессимистичные варианты. Т.е. мнений понаписано много, но железного и официального я найти не сумел (может плохо искал!). Правда я заметил, что неясность по данному поводу у многих питонистов, не только у меня. Но один специалист мне сказал, что в питоне небезопасен даже инкремент int'а, и вообще гил защищает только сам питон чтоб не сломался. И я склонен верить в пессимистичный вариант. Вся эта длинная история - претензия и к документации (в первую очередь) питона и к самому питону (тоже в первую очередь). Сложности на пустом месте. Скажите как есть, сразу большими буквами admonition: «даже не думайте, берите локи на всё» и делов-то.

anonymous
()
Ответ на: комментарий от anonymous

Инкремент не атомарен. Ты можешь использовать только атомарные операции безопасно, это везде так. GIL немного про другое.

anonymous
()
Ответ на: комментарий от anonymous

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

Да. Или тупо не знаешь, что такое множественное наследование и не заморачиваешься.

Объявление абстрактных классов (и абстрактных методов). Обычно это просто ключевое слово, модификатор, всё тупо и понятно. В питоне же очевидно какая-то глубокая манипуляция непонятно чем, нетривиальная катавасия. Чтобы эти криптические записи приобрели какой-то смысл (а не просто оставались мутной копипастой), надо, видимо, разбираться в питоней замудреной объектной модели. Для вас это просто? Завидую! Но не считаю, что «питон простой язык».

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

Хорошо, вот тут сообщением выше обсуждает многопоточность в питоне. По наивности некоторые могут посчитать (и считают), что GIL упрощает, т.е. многие операции становятся безопасными. Например доступ к элементами словаря. Но для этого нужно чтобы внутри самого захватывался этот гил в правильных местах (насколько я себе это понимаю). Однозначных железных ответов в документации я не нашел. В книге к примеру Martelli буквально одна-две строчки мутных осторожных слов. Что указывает на пессимистичные варианты. Т.е. мнений понаписано много, но железного и официального я найти не сумел (может плохо искал!). Правда я заметил, что неясность по данному поводу у многих питонистов, не только у меня. Но один специалист мне сказал, что в питоне небезопасен даже инкремент int'а, и вообще гил защищает только сам питон чтоб не сломался. И я склонен верить в пессимистичный вариант. Вся эта длинная история - претензия и к документации (в первую очередь) питона и к самому питону (тоже в первую очередь). Сложности на пустом месте. Скажите как есть, сразу большими буквами admonition: «даже не думайте, берите локи на всё» и делов-то.

Зависит от имплементации. Доступ к обычному словорю емнип безопасен. У другогой имплементации может не быть. Инкремент инта - это прочитать инт и присвоить новое значение, поэтому нет. А можно не заморачиватся и писать в один поток.

У питона низкий порог вхождения. Тебе не надо понимать какую-то строгую структуру директорий и файлов, ключевые слова, какие-то концепты ооп. Садишься и пишешь. Будешь закапываться в детали - докопаешься до электронов в транзисторах. Магии не бывает.

anonymous
()
Ответ на: комментарий от anonymous

Считаешь их абстрактными, если вообще знаешь такое понятие

Я кагбэ знаю «такое понятие»

Объявляешь класс с методом. Ключевые слова не нужны.

Какой-то бред. Механизм абстрактных классов в питоне есть, но он не нужен, советы с лора какие-то прям.

У питона низкий порог вхождения.

Нет, тут говорят же питон «простой язык». Порог входа во что? Он такой же. Он даже выше чем у C#/Javя, я считаю.

Моя теория откуда эти байки про порог входа и простоту:

... why you should pick Python as your first coding language to learn. It's free, easy to learn ...

Корень заблуждения в том, что «питон простой язык» в том, что даунята (причем опытные программисты тоже) видят только слова easy и Python, но не видят всей остальной фразы и распространяют это заблуждение. Наверное детям действительно проще познакомиться с программированием в рамках питона.

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

anonymous
()
Ответ на: комментарий от anonymous

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

Да. Или тупо не знаешь, что такое множественное наследование и не заморачиваешься.

А я вот соглашусь с 1-м оратором. В 3-м питоне множественное наследование усложнили в пользу Mixin-ов. Теперь родители ищутся не рекурсивно вглубь, а использую линейнизацию, для того что-бы избавиться от ромбов. Чьи-то классы использовать просто, но когда своё начинаешь писать, придется разобраться и это отличается от привычного наследования в С++, например.

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

+1

anonymous
()
Ответ на: комментарий от anonymous

Нет, тут говорят же питон «простой язык». Порог входа во что? Он такой же. Он даже выше чем у C#/Javя, я считаю.

Я тут давеча прочитал введение (больше 100 страниц) к докментации по sbt (Simple/Scala build tool). ПИТОН ВЕСЬ ЦЕЛИКОМ ПРОЩЕ ЧЕМ ОДНА ТОЛЬКО БИЛДЕЛКА К ЭТОЙ НЕСЧАСТНОЙ СКАЛЕ!1!!! Ничего не хочу доказать, просто иллюстрация.

ugoday ★★★★★
()
Ответ на: комментарий от anonymous

Объявляешь класс с методом. Ключевые слова не нужны.

Какой-то бред. Механизм абстрактных классов в питоне есть, но он не нужен, советы с лора какие-то прям.

Реально не нужен было то Python 3. С новым типом наследования иногда все-таки нужен, чтобы избежать исключений в рантайме при вызове super().method() из «левого» класса.

anonymous
()
Ответ на: комментарий от anonymous

Я кагбэ знаю «такое понятие»

Молодец. А другие не знают. И это не помешает им программировать на питоне. В отличии от жавы или сишарпа.

Какой-то бред. Механизм абстрактных классов в питоне есть, но он не нужен, советы с лора какие-то прям.

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

Нет, тут говорят же питон «простой язык». Порог входа во что? Он такой же. Он даже выше чем у C#/Javя, я считаю.

Неправильно ты считаешь. Чтобы писать на жаве или сишарпе тебе нужно понимать классы и объекты и методы и статические методы, разбираться с компиляторами, выстрелить себе в ногу сравнением строк по ссылке. И всё это за долго до того, как ты доберёшься до абстрактных классов или, чего доброго, тредов.

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

anonymous
()
Ответ на: комментарий от anonymous

Чтобы писать на жаве или сишарпе тебе нужно понимать классы и объекты и методы и статические методы,

У меня не возникало с этим проблем последние лет 10 как минимум.

зачем тебе в питоне понадобились абстрактные классы. Можно на примере

Я знаю, куда ты меня хочешь втянуть, в конечном итоге в даунске споры про кокококмпозицию, для меня это пройденый этап. Фигу, не ведусь на это.

Всё же ты не доказал мне, что «питон простой язык».

anonymous
()
Ответ на: комментарий от anonymous

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

Нет, проблемы у питона. Он переусложнен, чудовищно сложен (чудовищно - от слова неоправдано, без соответствия тому, что он дает и чем является). Он крив, у него ужасная документация.

anonymous
()
Ответ на: комментарий от anonymous

У меня не возникало с этим проблем последние лет 10 как минимум.

Тебе нужно разжевать «порог вхождения»? Или к чему ты написала про 10 лет?

Я знаю, куда ты меня хочешь втянуть, в конечном итоге в даунске споры про кокококмпозицию, для меня это пройденый этап. Фигу, не ведусь на это.

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

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

Всё же ты не доказал мне, что «питон простой язык».

Ну пиши на жаве. И тебе хорошо, и мне на душе спокойно.

anonymous
()
Ответ на: комментарий от anonymous

В питоне не принято писать явные интерфейсы

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

bread
()
Ответ на: комментарий от bread

А потом встречайте жуткие разношерстные интерфейсы с кишащей багами реализацией.

Что-то жаву явные интерфейсы не сильно спасли. А было, что и вовсе костыли вокруг них говнокодили.

anonymous
()
Ответ на: комментарий от ugoday

ПИТОН ВЕСЬ ЦЕЛИКОМ ПРОЩЕ ЧЕМ ОДНА ТОЛЬКО БИЛДЕЛКА К ЭТОЙ НЕСЧАСТНОЙ СКАЛЕ

Я бы не был так уверен. Почему-то учебники по питону, охватывающие все его фичи и тонкости, по объёму сравнимы с таковыми для крестов. Например Learning Python - 1500 страниц. Это простой язык? Для сравнения Learning Perl всего 390 страниц.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Почему-то учебники по питону, охватывающие все его фичи и тонкости, по объёму сравнимы с таковыми для крестов

Как действующий программист на Си++ и бывший программист на Python, я могу сказать, что Python ГОРАЗДО проще Си++.

Для сравнения Learning Perl всего 390 страниц.

А книга «Си++ за 21 день для анацефалов» - 10 страниц.

tailgunner ★★★★★
()
Ответ на: комментарий от no-such-file

Например Learning Python - 1500 страниц. Это простой язык? Для сравнения Learning Perl всего 390 страниц.

Learning Python — графомания, негодный пример. А Learning Perl по сути первый том букваря (как ни смешно это звучит). Там еще по ссылкам и объектам отдельная книга, advanced темка, не хухры-мухры. А camel book это вовсе монументальный талмуд. В общем перл монстр тот еще. Но хоть читать все это любопытно, а книги по питону какой-то треш.

bread
()
Последнее исправление: bread (всего исправлений: 1)
Ответ на: комментарий от bread

Learning Python — графомания, негодный пример.

да, у питона даже сторонние книги - туфта, графоманские крипичи

вот если с сишарпом даже сравнивать, даже то что не сам MS извадал, а то же гнилое орайли (c# албахари тот же) совсем другой уровень. это при том, что MS есть нормальная бесплатная документация, качественная

anonymous
()
Ответ на: комментарий от anonymous

Обычно годные книги пишут авторы, либо чуваки из core team. Но у питона и тут не заладилось почему то. Какие-то чучоные растекаются мыслью, или инженегры гугля копипастят доки.

bread
()
Ответ на: комментарий от bread

Обычно годные книги пишут авторы, либо чуваки из core team. Но у питона и тут не заладилось почему то. Какие-то чучоные растекаются мыслью, или инженегры гугля копипастят доки.

Сейчас с книгами по Python-у всё очень плохо. Его продвигают как простой язык для начинающих и полки магазинов забили творения про 2+2. Причем, пишут люди далекие от программирования.

anonymous
()
Ответ на: комментарий от no-such-file

Например Learning Python - 1500 страниц. Это простой язык? Для сравнения Learning Perl всего 390 страниц.

Я думаю, мы используем неверную терминологию. Правильнее говорить Питон — лёгкий язык. Вот, например, машина Тьюринга может быть описана на одной странице. Она простая, но совсем не лёгкая. И перл тоже не лёгкий. А питон лёгкий. И простой. 1500 страниц — это конечно много, но у питона лозунг «батарейки в комплекте». Если каждую батарейку хорошо описывать, там и больше может быть. В конце-концов, если у Перла начать CPAN описывать, там оver9k страниц будет. Ну и возможно, это просто детали издательского бизнеса, им удобно продавать толстые книги за много денег.

ugoday ★★★★★
()
Последнее исправление: ugoday (всего исправлений: 1)
Ответ на: комментарий от anonymous

Доступ к обычному словорю емнип безопасен

Пожалуйста, укажите источник, где вы это прочли.

anonymous
()
Ответ на: комментарий от anonymous

Множественное наследование - оно сложно само по себе, догадываюсь.

В нём нет ничего сложного.

Объявление абстрактных классов (и абстрактных методов).

Забей на них.

Rodegast ★★★★★
()
Ответ на: комментарий от Rodegast

В нём нет ничего сложного.

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

anonymous
()
Ответ на: комментарий от Rodegast

Объявление абстрактных классов (и абстрактных методов).

Забей на них.

Типичный бидлокодер. Ему сказали что нужно, он будет верить. Скажут что это ненужно, будет верить. Своей головы нет, сложней хеловорда ничего не писал.

anonymous
()
Ответ на: комментарий от ugoday

Правильнее говорить Питон — лёгкий язык

Ну, если не ходить дальше туториала, то да, лёгкий. Но так ведь любой язык лёгкий.

1500 страниц — это конечно много, но у питона лозунг «батарейки в комплекте». Если каждую батарейку хорошо описывать, там и больше может быть

Там не описываются батарейки, только язык. 1500 страниц описывается язык. Я так понимаю, что книгу ты не читал и стало быть с питоном знаком только по журналу мурзилка туториалу.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Я бы не был так уверен. Почему-то учебники по питону, охватывающие все его фичи и тонкости, по объёму сравнимы с таковыми для крестов. Например Learning Python - 1500 страниц. Это простой язык? Для сравнения Learning Perl всего 390 страниц.

Programming Perl - 1176 страниц. И что дальше?

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

anonymous
()
Ответ на: комментарий от anonymous

Programming Perl - 1176 страниц. И что дальше?

Половина этой книги включает обзор практики использования перла, батареек, и формальный reference material, чего в learning python нет, а если бы было, то было бы не 1500, а 3000 страниц.

не умеют подробно и понятно писать, это ясно всем, кто видел их язык

И всё равно этот язык проще питона. Хорошо только то, что большинство питонофанбоев дальше туториала не ушли и лепят наивный код, a la современный бейсик (в чём они сами в этом треде признаются и за это агитируют). Иначе код на перле показался бы тебе идеалом простоты и ясности.

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 1)
Ответ на: комментарий от no-such-file

Половина этой книги включает

Не читал, верю.

И всё равно этот язык проще питона. Хорошо только то, что большинство питонофанбоев дальше туториала не ушли и лепят наивный код, a la современный бейсик (в чём они сами в этом треде признаются и за это агитируют). Иначе код на перле показался бы тебе идеалом простоты и ясности.

Код на перле никому и никогда не может показаться идеалом простоты и ясности. Его ужасность - главная причина, почему перл был отправлен на свалку истории.

anonymous
()
Ответ на: комментарий от no-such-file

Ну, если не ходить дальше туториала, то да, лёгкий. Но так ведь любой язык лёгкий.

Нет.

RazrFalcon ★★★★★
()
Ответ на: комментарий от no-such-file

Но так ведь любой язык лёгкий.

Нет, не любой. Как правило, нужно дофига чего знать, чтобы что-то сложнее хелловорлда заставить работать. Тут, конечно, можно полезать спорить мол, java как язык — особая статья, её стандартная библиотека — другое дело, nexys/ivy/maven — третье. И это формально даже в чём-то корректно, но факт остаётся фактом. В одном случае, для работы нам нужно знать и уметь заботиться о радикально большем количестве вещей, чем в другом.

Я так понимаю, что книгу ты не читал и стало быть с питоном знаком только по журналу мурзилка туториалу.

Вот, видите. В одном случае, чтобы программировать чего-то осмысленное нужно окончить университет, а в другом — прочитать журнал мурзилка. На всякий случай, как человек совершивший и то, и другое отвественно заявляю, прочитать журнам мурзилка намного _легче_.

ugoday ★★★★★
()
Ответ на: комментарий от ugoday

В одном случае, чтобы программировать чего-то осмысленное нужно окончить университет, а в другом — прочитать журнал мурзилка.

Для того чтобы программировать достаточно окончить 3 месячные программистские курсы. Университеты дают много непрактичного шлака и притом умудряются растянуть это удовольствие на 4-6 лет.

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

anonymous
()
Ответ на: комментарий от no-such-file

так ведь любой язык лёгкий

Нет, он правильно сказал. Словарь(или память пользователей) русского языка не имеет достаточно точных слов для детализации понятия «простой». Питон - сложен из довольно большого количества всякой всячины и в этом смысле «сложный»=«не простой». Он же (обычно) «простой» в сопровождении(скажем «не трудный»?). Он же «лёгкий» («не тяжёлый»?) как в физике, по кол-ву требуемой для начала движения работы. Ещё, наверное, есть несколько полезных измерений.

И они все почти ортогональны/независимы, и не универсальны. ad absurdum: unlambda простой=несложный - весь состоит из несколькиих функций, описываемых на одной странице. «тяжёлый» - что-то на нём написать нужен таки универ, наверное. И «трудный» - понять потом нереально(если верить автору, я не пробовал). С - несложный, довольно тяжёлый, трудный. Perl - сложный, трудный, средней тяжести. Ну и т.д.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

PS: порывшись в словаре

ещё нашёл. Простой-прихотливый(java?) - для определения требовательности к инструментам(навороченные редакторы, отладчики, etcы), без которых слишком трудно. Простой-замысловатый(haskell?) - по «высоте» используемых абстракций.

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от ugoday

В одном случае, для работы нам нужно знать и уметь заботиться о радикально большем количестве вещей, чем в другом

Нет, не нужно. Продолжая экскурс в литературу, Learning Java всё того же издательства - 970 страниц. В это включается обзор стандартной библиотеки, сервлеты, JavaBeans и даже Swing и работа с мультимедиа.

отвественно заявляю, прочитать журнам мурзилка намного _легче_

А я тебе ответственно заявляю, что прочитать 970 страниц легче, чем 1500 + доки к батарейкам.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Чтобы успешно писать на питоне достаточно прочитать 1 главу любого учебника и открыть для себя команды dir() и help() в интерактивной сессии. Где твой бог теперь? Для вебни ещё по шаблонизаторам справку. Вообще хватит мерить простоту изучения графоманскими высерами, бесите уже.

anonymous
()
Ответ на: комментарий от DonkeyHot

С - несложный, довольно тяжёлый, трудный. Perl - сложный, трудный, средней тяжести. Ну и т.д.

У perl есть такой слоган «make the easy things easy, and the hard things possible». Я считаю что на любой язык нужно смотреть с этого ракурса, потому что существуют сложные задачи и нет ничего, что могло бы их упростить. Никакие магические языки не сделают трудную задачу лёгкой. Поэтому когда кто-то утверждает, что питон - лёгкий, это означает что этот кто-то просто не решает тяжёлых задач.

А теперь если подумать, для чего в питон напихали столько всего, что учебник получается минимум в 2 раза толще любого другого (кроме разве что крестов)? Чтобы лабать на нём простенькие скриптики для которых достаточно 10% от всех возможностей? Вообще тут в теме не зря вспоминали PL/I, питон действительно продолжатель этих традиций «мы сделаем язык программирования максимально похожим на английский» путём запихивания в него сахара на все случаи жизни. Вот что понимается, когда говорят что питон easy to learn. Как показала история, это порочная практика ведущая в тупик, т.к. язык постепенно превращается в переусложнённый, неповоротливый кусок говна. Python way?

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от anonymous

Чтобы успешно писать на питоне достаточно прочитать 1 главу любого учебника и открыть для себя команды dir() и help() в интерактивной сессии

Уверен, что ты и многие другие питонофанбои так и делают. Т.е. всё программирование сводится к тому чтобы дёргать suprer_lib.foo(«hello world») в разных вариациях. Максимум - скопипастить пример из доков.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Чтобы успешно писать на питоне достаточно прочитать 1 главу любого учебника и открыть для себя команды dir() и help() в интерактивной сессии

Уверен, что ты и многие другие питонофанбои так и делают

Все так делают. Даже ты.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Все так делают

Нет не все, это ложь.

Даже ты

В том числе я так не делаю. Так что это тоже ложь.

PS: если ты не готов конструктивно что-то обсуждать, зачем набрасывать? Чешется что ли?

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

питон действительно продолжатель этих традиций «мы сделаем язык программирования максимально похожим на английский» путём запихивания в него сахара на все случаи жизни.

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

anonymous
()
Ответ на: комментарий от no-such-file

Все так делают

Нет не все, это ложь.

Все. Но некоторые стесняются признаться.

если ты не готов конструктивно что-то обсуждать, зачем набрасывать?

Ты же набрасываешь, с чего бы мне не набросить.

tailgunner ★★★★★
()
Ответ на: комментарий от tailgunner

Ты же набрасываешь, с чего бы мне не набросить

Ну я думал, что ты не всегда ведёшь себя как мартышка. Ладно, сдаюсь, больше не буду даже пытаться разглядеть в тебе человека.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Ну я думал, что ты не всегда ведёшь себя как мартышка.

Не всегда. Но если оппонент ведет себя так, я тоже.

tailgunner ★★★★★
()
Ответ на: комментарий от no-such-file

Т.е. всё программирование сводится к тому чтобы дёргать suprer_lib.foo(«hello world») в разных вариациях.

Если задача решаема простым путем, то к чему сложности?

Solace ★★
()
Ответ на: комментарий от anonymous

Чтобы успешно писать на питоне достаточно прочитать 1 главу любого учебника и открыть для себя команды dir() и help()

Так невозможно ничего написать. Это глупости.

anonymous
()
Ответ на: комментарий от anonymous

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

Нет. Высшее образование нужно для нормальных инженеров.

Другое дело, что основная масса вакансий на IT-рынке труда не инженеры, а простые техники. Тут действительно будет достаточно какого-нибудь ПТУ для кодеров.

anonymous
()
Ответ на: комментарий от anonymous

Анонимус всё правильно сказал.

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

А теперь если подумать, для чего в питон напихали столько всего, что учебник получается минимум в 2 раза толще любого другого (кроме разве что крестов)?

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

ugoday ★★★★★
()
Ответ на: комментарий от no-such-file

потому что существуют сложные задачи и нет ничего, что могло бы их упростить

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

для чего в питон напихали столько всего

Очевидно же. «Сложность»(в указанном выше смысле) - забота автора и пользователей не волнует. Возможность «упростить»(в любом из других перечисленных смыслов) за его счёт жизнь клиентов - целесообразна(ибо их больше и они не такие ловкие). Вероятно потому питон - за счёт сложности внутри простой «снаружи» - популярен.

не решает тяжёлых задач

Известный факт - подавляющее большинство задач тривиальны. Если дать средство их решения в руки любителей, время специалистов можно будет сконцентрировать на менее тривиальных(и им будет не так нудно). win-win же.

постепенно превращается в переусложнённый, неповоротливый кусок говна

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

DonkeyHot ★★★★★
()
Ответ на: комментарий от ugoday

зациклились на размере этого учебника

Потому что это объективный показатель сложности языка, а не мнение какого-то Васяна с ЛОРа. Чем больше требуется объяснений, тем сложнее предмет, это же очевидно. А то ведь твой коллега уже совсем в метафизику ударился, у него уже питон простой потому что он сложный. Диалектика бытия питона.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

1500 страниц

зациклились на размере этого учебника

Потому что это объективный показатель сложности языка

Ты отождествляешь сложность и размер, а это ведь разные вещи.

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

Конечно, ты можешь заявить, что те, кто не освоил в совершенстве метаклассы, генераторы, декораторы и пр. примочки, на самом деле не знают Python, это твоё право. Вот только в индустрии и такие «незнайки» вполне востребованы, а тогда так ли оно важно, это знание всех нюансов?

Вот ещё что придумалось. Если представлять язык как граф концепций, то размер — он про количество вершин в этом графе, а сложность — про количество рёбер. В Python много вершин, но мало рёбер (слабая связность), поэтому я называю его несложным, но большим.

Crocodoom ★★★★★
() автор топика
Ответ на: комментарий от Crocodoom

Генераторы и декораторы примитивные и очень полезные вещи (хотя может они могли бы быть реализованы чуть удобней и интуитивней, но это уже придирки), а вот метаклассы это какая-то левизна, больше похожая на побочный эффект устройства самого языка, нежели «фичу».

anonymous
()
Ответ на: комментарий от no-such-file

питон простой потому что он сложный

звучит логично ващет. Си вот сложный потому что простой. И асм тоже. Получается плюсы сложные просто потому что это си.

anonymous
()
Ответ на: комментарий от Crocodoom

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

Это же можно сказать о любом скриптовом языке. Учится за неделю. Но в отличие от питона целиком и никаких «остальных концепций» выяснять потом не нужно.

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

Именно так.

Вот только в индустрии и такие «незнайки» вполне востребованы, а тогда так ли оно важно, это знание всех нюансов?

Не сомневаюсь. Но я уже устал тут повторять всем и каждому, что:

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

2.Если по большому счёту это всё что требуется «индустрии», то питон является необоснованно переусложнённым языком и его «фичи» просто не нужны.

поэтому я называю его несложным, но большим

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

no-such-file ★★★★★
()
Последнее исправление: no-such-file (всего исправлений: 2)
Ответ на: комментарий от no-such-file

просто не знают питон и не сталкивались со сложностями ... его «фичи» просто не нужны.

Отут ошибка. Если фичи не нужны «незнайкам» это не означает, что они не нужны тем, кто обеспечивает им возможность не знать. Вполне вероятно, что без чёрной магии в кишках системы будет невозможно создать видимость простоты снаружи. И что же в этом необычного - «везде» есть «пользователи», которым нужно предоставить простой очевидный интерфейс, и «ижненеры», которые знают, из каких костылей это состоит. И это есть хорошо.

DonkeyHot ★★★★★
()
Ответ на: комментарий от DonkeyHot

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

В других языках не требуется никакой чёрной магии для этого. Отсюда следует, что питон просто broken by design, если он не может обойтись без чёрной магии, там где другие могут, и весь python way это дорога в ад.

Зря ты пытаешься оправдать сложность питона магическими свойствами присущими только питону.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

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

Это же можно сказать о любом скриптовом языке. Учится за неделю. Но в отличие от питона целиком и никаких «остальных концепций» выяснять потом не нужно.

4.2

anonymous
()
Ответ на: комментарий от no-such-file

В других языках не требуется никакой чёрной магии для этого. Отсюда следует, что питон просто broken by design, если он не может обойтись без чёрной магии, там где другие могут, и весь python way это дорога в ад.

Напиши, хоть, в каких языках и какая конкретно черная магия

anonymous
()
Ответ на: комментарий от no-such-file

В других языках не требуется никакой чёрной магии

JS - не магия, но бесконечное количество «ритуалов», а то типы заглючат, области видимости пересекутся. Я не говорю о том, что зазеваешься - и вот уже у тебя множатся копии объектов и едят память, вместо подразумевавшегося вызова функции в цикле.

Вообще, питон - годная замена турбо-паскалю. Естественно, когда за типами следишь (или следит IDE)

Shadow ★★★★★
()
Последнее исправление: Shadow (всего исправлений: 1)
Ответ на: комментарий от anonymous

какая конкретно черная магия

Мне сюда все 1500 пресловутых страниц скопипастить? Сходи и почитай.

в каких языках

Тут другой анонимус уже приводил пример с абстрактным классом на метаклассах. Почему-то в пыхе никаких метаклассов и другой магии для этого не нужно.

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

Да взять хоть ООП: если требуется что-то чуть сложнее словаря с методами, начинаются дикие пляски с бубном. Нигде не видел более неуклюжей примитивной и одновременно сложной в применении объектной модели.

bread
()
Ответ на: комментарий от Shadow

или следит IDE

в том-то и дело, что в динамическом языке IDE не может помогать с типами.

anonymous
()
Ответ на: комментарий от anonymous

в динамическом языке IDE не может помогать с типами

Это не совсем так, потому что аннотации типов вполне неплохо работают в этом отношении.

no-such-file ★★★★★
()
Ответ на: комментарий от no-such-file

Тут другой анонимус уже приводил пример с абстрактным классом на метаклассах. Почему-то в пыхе никаких метаклассов и другой магии для этого не нужно.

То что не нужно без причины использовать мета и абстрактные классы писали уже неоднократно. Это просто надо принять «как есть». Константы, приватные и защищенные методы помечаются используя правила именования (верхний регистр, двойной и одинарный символ подчеркивания). И все, рисуйте дерево класса любой сложности - ненужно никакой магии. Кстати, сомневаюсь, что для любителя php это аргумент, но даже с метаклассами и дескрипторами «магии» все-равно меньше чем в Ruby. Пример продуманного пыха:

("x" == 0) === true
("1x" == 0) === false
У Гвидо хоть какой-то здравый смысл был, когда он к типам операторы приделывал.

anonymous
()
Ответ на: комментарий от no-such-file

Чем больше требуется объяснений, тем сложнее предмет, это же очевидно.

Михаил Сергеевич Горбачём мог 3 часа болтать абсолютно ни о чём. Это не показатель сложности «ни о чём». Это показатель способностей генсека.

ugoday ★★★★★
()
Ответ на: комментарий от Shadow

питон - годная замена турбо-паскалю

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

grem ★★★★★
()
Ответ на: комментарий от no-such-file

других языках не требуется никакой чёрной магии

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

Я надумал согласиться с чьим-то мненем выше об объективной природе сложности. Постулируем «Закон неубывания». Никакой магический инструмент не может уменьшить сложность. Её можно только перераспределить - между «прикладным» и «библиотечным» кодом. И это неминуемо добавит дополнительную сложность. Которую можно попытаться спрятать в язык, или вывалить на «прикладника» и/или «библиотекаря». Больше просто некуда(можно в другой язык, но это юниксвей и офтопик).

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

DonkeyHot ★★★★★
()
Последнее исправление: DonkeyHot (всего исправлений: 1)
Ответ на: комментарий от anonymous

не нужно без причины использовать мета и абстрактные классы писали уже неоднократно

Я даже больше скажу, их вообще не нужно использовать. Никогда. В питоне они на практике никому не нужны.

Пример продуманного пыха

А я где-то утверждал что пых продуманный? Пых язык практичный, а это означает что в нём есть костыли, т.к. на практике просто невозможно создать идеально продуманный «язык всего», будь ты хоть Гвидо, хоть сам Христос. Создатели пыха хотя бы не строят из себя святых. И кстати говоря про == обсуждается возможность его выкинуть, оставить только ===.

no-such-file ★★★★★
()
Ответ на: комментарий от DonkeyHot

В батарейки она не пролезет - никто не станет писать их добровольно, и никто не станет покупать их достаточно дорого, чтобы окупить труд рабов

Что называется «начал за здравие, кончил за упокой». Ты опять апеллируешь в «волшебному свойству». Только раньше это было свойство языка, а теперь это свойство сообщества.

никто не станет писать их добровольно

Конечно станет, и пишут. И для питона пишут, и для других языков.

no-such-file ★★★★★
()
Ответ на: комментарий от anonymous

Высшее образование нужно для нормальных инженеров.

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

Также, бывает так, что встречаешь вежливого интеллигентного очкарика со среднеспециальным образованием.

Вот и думаешь: «а на куя оно, это высшее образование».

anonymous
()
Ответ на: комментарий от no-such-file

волшебному свойству ... сообщества

Лень и нежелание «трудиться»(в противовес «развлекаться») - это вовсе не магические свойства человеков. Они были бы магическими, если бы отсутствовали.

DonkeyHot ★★★★★
()
Ответ на: комментарий от anonymous

бывает так, что встречаешь вежливого интеллигентного очкарика со среднеспециальным образованием.

Вот и думаешь: «а на куя оно, это высшее образование».

Высшее образование - оно точно не для очков и вежливости :)

tailgunner ★★★★★
()
Ответ на: комментарий от anonymous

Бывает так,
Также, бывает так,
Вот и думаешь

А не надо из отдельных частных случаев делать обобщённые выводы.

anonymous
()
Ответ на: комментарий от no-such-file

Пых язык практичный, а это означает все что в нём есть - костыли

fixed :) Когда из языка для создания home page начали делать пародию на джаву, иначе и быть не может.

Linfan ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.