The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]

Выпуск языка программирования Python 3.6

23.12.2016 23:52

После 15 месяцев разработки представлен значительный релиз языка программирования Python 3.6.

Среди добавленных новшеств:

  • Добавлена поддержка форматируемых строковых литералов, позволяющих определить строку, содержащую подстановки. Заданные в фигурных скобках выражения вычисляются и подставляются в текст строки во время выполнения программы и форматируются с использованием протокола format(). Например:
    
       >>> name = "Fred"
       >>> f"He said his name is {name}."
       'He said his name is Fred.'
       >>> width = 10
       >>> precision = 4
       >>> value = decimal.Decimal("12.34567")
       >>> f"result: {value:{width}.{precision}}"  # nested fields
       'result:      12.35'
    
  • Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
  • Определён синтаксис аннотаций для переменных, позволяющий передать интерпретатору информацию о типах переменных. Аннотации сохраняются в атрибуте __annotations__ класса или модуля, но в отличие от языков со статической типизацией не накладывают каких-либо ограничений, а служат для структурирования метаданных, которые могут использоваться сторонними инструментами и библиотеками. Например:
    
       primes: List[int] = []
    
       captain: str  # Note: no initial value!
    
       class Starship:
          stats: Dict[str, int] = {}
    
  • Возможность определения асинхронных генераторов. В прошлой ветке Python 3.5 был реализован новый синтаксис async / await для определения сопрограмм, но в теле одной функции невозможно было одновременно использовать await и yield. В Python 3.6 данное ограничение снято, что позволяет определять генераторы, работающие в асинхронном режиме:
    
       async def ticker(delay, to):
           """Yield numbers from 0 to *to* every *delay* seconds."""
           for i in range(to):
               yield i
               await asyncio.sleep(delay)
    
    
  • Добавлена возможность асинхронной обработки списковых включений (comprehensions) через использование выражения "async for" для списков, множеств и словарей. Также допускается применение выражений await для всех видов списковых включений. Например:
    
       result = [i async for i in aiter() if i % 2]
       result = [await fun() for fun in funcs if await condition()]
    
    
  • Переработана реализация типа dict, которая переведена на более компактное представление, похожее на реализацию от проекта PyPy. В итоге удалось сократить потребление словарями памяти на 20-25% и обеспечить хранение с сохранением порядка следования записей (упорядочивание позиционируется как особенность, которая может измениться в будущем, поэтому до определения упорядочивания в спецификации полагаться на данную возможность не стоит);
  • Представлен новый метод "__init_subclass__", упрощающий настройку подкласса без использования метакласса;
  • Обеспечено сохранение порядка определения атрибутов класса (прядок можно отследить через сохраняемый в классах атрибут "__dict__");
  • Порядок определения аргументов ключевых слов, передаваемых в функцию, теперь соответствует порядку элементов в **kwargs;
  • Добавлена поддержка контрольных вызовов (probe) DTrace и SystemTap. При сборке с опцией "--with-dtrace" Python может устанавливать маркеры для таких событий, как вызов и выход из функции, начало/завершение сборки мусора и выполнение строки кода;
  • Представлена новая переменная окружения PYTHONMALLOC, через которую можно выбрать механизм распределения памяти для Python или включить отладочные хуки. Например, при указании "PYTHONMALLOC=debug" добавляются средства определения выхода за границы буфера, применяется специально заполнение новых и освобождённых блоков и т.п.
  • Стабилизирован API модуля asyncio, значительно увеличена производительность и расширена функциональность;
  • Добавлен протокол для определения путей в файловой системе в виде отдельных объектов pathlib. Например:
    
       >>> import pathlib
       >>> with open(pathlib.Path("README")) as f:
       ...     contents = f.read()
    
  • В функции datetime.datetime и datetime.time из модуля datetime добавлен атрибут fold, информирующий о вхождении в неоднозначные промежутки времени, например в промежуток, возникающий при переводе часов на час назад;
  • В разряд стабильных переведён модуль typing;
  • Значительно переработан модуль tracemalloc, расширены средства диагностики ошибок при распределении памяти;
  • В состав стандартной библиотеки включён новый модуль secrets, предоставляющий средства для генерации криптографически надёжных псевдослучайных чисел, пригодных для формирования различных ключей и токенов;
  • На платформе Linux при вызове os.urandom() обеспечено ожидание завершения инициализации энтропии для генератора urandom;
  • В модулях hashlib и ssl добавлена поддержка OpenSSL 1.1.0.
  • Улучшен набор настроек по умолчанию для модуля ssl;
  • В модуль hashlib добавлена поддержка алгоритмов хэширования BLAKE2, SHA-3 и SHAKE, реализована функция формирования ключа scrypt();
  • Представлена большая порция улучшений, связанных с работой на платформе Windows.


  1. Главная ссылка к новости (http://www.mail-archive.com/py...)
  2. OpenNews: Выпуск Pyston 0.6, реализации языка Python с JIT-компилятором
  3. OpenNews: Выпуск Cython 0.25, компилятора для языка Python
  4. OpenNews: Выпуск PyPy3 5.5, реализации Python 3, написанной на языке Python
  5. OpenNews: Увидел свет язык программирования Python 3.5.0
  6. OpenNews: Выпуск языка программирования Python 3.4.0
Лицензия: CC BY 3.0
Короткая ссылка: https://opennet.ru/45755-python
Ключевые слова: python
При перепечатке указание ссылки на opennet.ru обязательно


Обсуждение (67) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.6, chinarulezzz (ok), 01:00, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Аннотация типов... ммм, представляю сколько костылей навтыкают, прежде чем скажут "готовится python4".
     
     
  • 2.86, ADR (ok), 01:53, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    А что с ней не так?
     

  • 1.10, Аноним (-), 02:40, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    > >>> name = "Fred"
       >>> f"He said his name is {name}."

       'He said his name is Fred.'

    не прошло и 20 лет.

     
     
  • 2.17, Гость (??), 05:46, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –5 +/
    Да уж. Вспомним этот пример из главы 1.2 Кернигана-Ричи:

         PRINTF("%4.0F %6.1F\N", FAHR, CELSIUS);

     
     
  • 3.22, анон (?), 09:35, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Спецы по питону набигают
     
  • 3.36, angra (ok), 11:33, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +9 +/
    Это давно есть в питоне. Кто-то явно не понял в чем новшество.
     
  • 2.45, Имя (?), 12:57, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    оно и раньше было, просто писалось как
    "He said his name is {}.".format (name)
    в фиг. скобках указывается спец. формата.

    или для второго питона
    "He said his name is %s." % name

     
     
  • 3.84, Nas_tradamus (ok), 12:51, 27/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    [btr@mb:~] $ python2.7
    Python 2.7.10 (default, Sep 23 2015, 04:34:14)
    [GCC 4.2.1 Compatible Apple LLVM 7.0.0 (clang-700.0.72)] on darwin
    Type "help", "copyright", "credits" or "license" for more information.
    >>> name = 'Fred'
    >>> "He said his name is {}.".format(name)

    'He said his name is Fred.'
    >>>

     
  • 2.69, oopsy (?), 13:25, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Cовершенно c Вами согласен, коллега.
    Не прошло и 20 лет как неосиляторы продавили ненужную на первый взгляд фичу.

    в python 2.7 (у меня нет более старой версии чтобы проверить) работает и

    name = "Fred"
    print "%(name)s" % locals()

    и (по документации - должно работать с 2.6):

    name = "Fred"
    print "{name}".format(**locals())

    т.е. f'' противоречит dao python в части «There should be one-- and preferably only one --obvious way to do it.». И это настоящий позор.

    Ладно, понизим градус радикализма - эта фича не нужна конкретно мне,
    мне никогда не хотелось писать и не случалось видеть «% locals()» или «.format(**locals())»

    Возможно, что у кого-то это нужно писать в каждой строке. Типа «Although practicality beats purity.»

     

  • 1.16, not inkognito (ok), 05:31, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –6 +/
    Как по мне Разделение символов подчеркиванием Ниочень совсем :(Вроде всегда  везде ставились точки (не  имеюв виду код). 1.000.000.000 выглядит намного лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы визуально. Если точки/запятые никак нельзя использовать то лучше уж вообщеникак тогда по моему.
    а вообще всегда  считал символы выделением или разделением с права  на лево по 3 символа :p
    пример - 61998536
    Выделяем  635+899+16=3+3+2=8 знаков от 7 до 9 знаков у нас миллионы значит имеем 61 млн 998 тыс 536 р.
    :p
     
     
  • 2.20, Blind Vic (ok), 09:30, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    >  вообще всегда  считал символы выделением или разделением с права  на лево по 3 символа

    То, что ты любишь боль, не обязывает других ни к чему

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

    Серьезно?

     
     
  • 3.23, Аноним (-), 09:46, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +7 +/
    Он просто не в курсе про моноширинные шрифты.
     
  • 2.28, Аноним (-), 10:12, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +6 +/
    > ... 1.000.000.000 выглядит намного лучше чем вырвиглазное 1_000_000_000 и даже ...

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

    С подчеркиванием конечно компромис, но он никого не вводит в заблуждение.

     
  • 2.34, Anonisimus (?), 11:13, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Точки? А как тогда целые от чисел с плавающей запятой парсер различать должен?
     
  • 2.41, анонимусимус (?), 12:24, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >[оверквотинг удален]
    > везде ставились точки (не  имеюв виду код). 1.000.000.000 выглядит намного
    > лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы
    > визуально. Если точки/запятые никак нельзя использовать то лучше уж вообщеникак тогда
    > по моему.
    > а вообще всегда  считал символы выделением или разделением с права  
    > на лево по 3 символа :p
    > пример - 61998536
    > Выделяем  635+899+16=3+3+2=8 знаков от 7 до 9 знаков у нас миллионы
    > значит имеем 61 млн 998 тыс 536 р.
    > :p

    Ужас. Что я только что прочитал? Ни в зуб ногой... а порассуждать своим пустым котелком любитель я смотрю.

     
  • 2.47, adminlocalhost (ok), 14:48, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >  Как по мне Разделение символов подчеркиванием Ниочень совсем :(Вроде всегда  
    > везде ставились точки (не  имеюв виду код). 1.000.000.000 выглядит намного
    > лучше чем вырвиглазное 1_000_000_000 и даже вроде меньше места занимает хотябы
    > визуально. Если точки/запятые никак нельзя использовать то лучше уж

    Лучше всего стандартный разделитель "штрих" использовать.

    1'000'000'000

    Который вводится если нажать шифт и ту клавишу, что у тебя на клавиатуре в цифровом ряду самым первым слева, ошибочно отмеченная как "Ё".

     
     
  • 3.65, Аноним (-), 02:38, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Нажимаю Shift+Ё, получаю тильду. ЧЯДНТ?
    И сам же использовал одиночный штрих, что на "Э", а не backtick ('), лживый анон.
     
  • 3.75, Аноним (-), 12:20, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Запятая же - 1,000,000.00 (c) Англосаксы.
    "Большинство стран выбрали в качестве десятичного символа запятую. Однако англоязычные страны предпочли точку, а запятую стали использовать как разделитель групп разрядов."
     
  • 2.48, Аноним (-), 15:10, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В информатике точка является разделителем целой и дробной частей числа. Может, конечно, в вашем вижуальном васике это иначе, а в остальных ЯП это так.
     
     
  • 3.85, Аноним (-), 23:23, 27/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    В визуальном васике тоже точка, а про остальные языки вы не правы, среди них есть с другими разделителями.
     

  • 1.19, Blind Vic (ok), 09:27, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +2 +/
    Не упомянули, что словари теперь упорядочены

    > The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon (this may change in the future, but it is desired to have this new dict implementation in the language for a few releases before changing the language spec to mandate order-preserving semantics for all current and future Python implementations; this also helps preserve backwards-compatibility with older versions of the language where random iteration order is still in effect, e.g. Python 3.5).

    https://docs.python.org/3.6/whatsnew/3.6.html#new-dict-implementation

     
     
  • 2.25, Аноним (-), 10:06, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    А вот это уже серьезное изменение. В целом конечно всем ... как обычно, но я бы не стал так резко менять поведение системных структур. Можно было бы добавить просто новый какой-то подход к записи, что то на подобии <> например или (a. b) как в Lisp... В целом из фичи сделали треш. Про asyncio нужна нормальная документация, так как в 3.5 почти нихрена непонятно было и приходилось смотреть код ... Упоминание про event_loop появилось в целом сравнительно недавно в документации, что реально грустно.
     
     
  • 3.87, ADR (ok), 01:58, 28/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Всегда есть collections.OrderedDict.
     
  • 2.32, Аноним (-), 10:49, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "new implementation is considered an implementation detail and should not be relied upon"

    Т.е. по сути пока недокументированная возможность, которая может измениться в будущих выпусках.

     
     
  • 3.60, Blind Vic (ok), 23:07, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Я уверен, что это станет стандартом. Например, class attribute definition order завязан на новом dict:

    > Since compact dict has landed in 3.6, __definition_order__ has been removed. cls.__dict__ now mostly accomplishes the same thing instead.

    https://www.python.org/dev/peps/pep-0520/


    И **kwargs:

    > Note: in Python 3.6 dict is order-preserving. This virtually eliminates performance concerns.

    https://www.python.org/dev/peps/pep-0468/

     

  • 1.21, Аноним (-), 09:31, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Питон становится похож на perl. К чему бы это?
     
     
  • 2.27, Аноним (-), 10:09, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Питон становится похож на perl. К чему бы это?

    Ну в целом небольшие скриптики уже можно будет переписать с Perl на Python ;-)

     
     
     
    Часть нити удалена модератором

  • 4.31, анон9 (?), 10:42, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    > Ну и да, классы там это просто синтаксический сахар для функции-конструктора,
    > в таком виде они были давно.

    Были-то они давно, только вот кто-то делал методы через прототип, кто-то через конструктор, кто-то смешивал (приватные в конструктор, публичные в прототип). Реализации наследования, опять же, везде разные были.
    С введением этого "сахара" все стали делать однообразно, разве что модификаторов доступа не хватает

     
  • 3.50, leap42 (ok), 15:24, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    зачем? чтобы стали большими? perl был и будет чемпионом в категории "быстрый и 'грязный' скрипт" из-за своей гибкости, лаконичности, мощности и "неприхотливости", а у python другие ниши.
     
     
  • 4.73, Аноним (-), 03:35, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Это не тебя "всегда посылают на грязную работу", просто ты выполняешь любую работу грязно. ©
     
  • 2.62, Вы забыли заполнить поле Name (?), 23:55, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    > становится похож на perl

    В чем? Увидел знакомые символы подчеркивания в числах?

     

  • 1.33, Аноним (-), 10:59, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    На сколько в этот раз разжиреют дистрибутивы вроде убунты? На сколько помню, каждая версия прибавляет сотню другую.
     
     
  • 2.35, Аноним (-), 11:27, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > На сколько помню

    Насколько помню, "на сколько помню" пишется несколько иначе.

     
     
  • 3.37, Аноним (-), 11:34, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    "На сотню-другую" еще, раз на то пошло.
     
  • 2.39, pda (?), 12:21, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Прибавляю сотню-другую чего? Килобайт? Нефти? Прибавляют за счёт чего? Новых пакетов точно нет?
     
     
  • 3.46, Аноним (-), 13:39, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    По моим наблюдениям речь идет о мегабайтах. В убунте пакеты питона вместе с морем зависимостей сейчас занимают ~1 гиг.
     
  • 2.52, Аноним (-), 16:39, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > На сколько в этот раз разжиреют дистрибутивы вроде убунты? На сколько помню,
    > каждая версия прибавляет сотню другую.

    [CODE]
    % pkg rquery %n-%sh python27 python33 python34 python35
    python27-66.7MiB
    python33-80.7MiB
    python34-78.6MiB
    python35-101MiB

    % pkg rall-depends python35
    python35 depends: libffi
    python35 depends: readline
    python35 depends: gettext-runtime
    libffi depends: indexinfo
    readline depends: indexinfo
    gettext-runtime depends: indexinfo

    % pkg rquery %n-%sh libffi readline gettext-runtime indexinfo
    libffi-124KiB
    readline-1.52MiB
    gettext-runtime-802KiB
    indexinfo-11.5KiB

    [/CODE]
    То ли память у вас дырявая, то ли в убунте, как обычно, неосилили ...


     

  • 1.38, saahriktu (ok), 12:20, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –2 +/
    Не хватает поддержки переменной окружения $PYTHONPATH3 из коробки. А то всё заточено на $PYTHONPATH, а об неё спотыкается Python 2, который её тоже знает (а заодно и $PYTHONPATH2). Не из коробки Python 3, конечно, можно и сейчас переучить на $PYTHONPATH3, но неофициальными патчами, ломая совместимость с документированным поведением: "sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' PC/getpathp.c && sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Modules/getpath.c && sed -i 's/\"PYTHONPATH\"/\"PYTHONPATH3\"/' Mac/IDLE/IDLE.app/Contents/MacOS/IDLE".
     
     
  • 2.40, анонимусимус (?), 12:22, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Ты на всех форумах об этом уже отписался или еще нет?
     
     
  • 3.42, saahriktu (ok), 12:26, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Как будто что-то плохое. Плохо, наоборот, когда люди приобретают знания и умения, но не хотят ни с кем делиться.
     
     
  • 4.44, Аноним (-), 12:40, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Патчить седом - сурово, сурово.
     
     
  • 5.49, leap42 (ok), 15:19, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    питонисты редко пользуются vi и ещё реже perl'ом, чем им ещё "патчить" если не sed'ом?
     
     
  • 6.51, saahriktu (ok), 16:22, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Сразу видно человека, который ни разу не читал LFS Book. В ней активно используется sed для наложения патчей. Наверняка, многие маинтейнеры тоже используют sed. Гораздо удобнее чем таскать кругом полноразмерные патчи. Другой вопрос, что далеко не всё можно загнать в правила sed'а, да (поскольку нет смысла). Вот там полноразмерные патчи и используются.

     
  • 6.57, Crazy Alex (ok), 19:19, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Питоном?
     

  • 1.43, Аноним (-), 12:39, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
       >>> name = "Fred"
       >>> f"He said his name is {name}."

       'He said his name is Fred.'

    Теперь придется ещё тщательнее проверять пользовательский ввод в приложениях.
    Или не пользоваться этой фичей.

     
     
  • 2.53, Ordu (ok), 17:16, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Засовывать пользовательский ввод в функции типа printf в качестве _форматной_ строки -- это вообще катастрофически плохая идея, даже если она прикрыта проверкой пользовательского ввода. Это почти так же плохо, как выполнять eval на пользовательском вводе, даже если этот ввод тщательно проверен.
     
  • 2.56, FrBrGeorge (ok), 18:57, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > Теперь придется ещё тщательнее проверять пользовательский ввод

    Вы не можете ввести строку типа f"", только обычный str

     

  • 1.54, chinarulezzz (ok), 18:08, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Хорошо что удалили сообщение о аннотации типов и питон4.

    В php это привело к 7+, в perl к 6 версиям.

     
     
  • 2.58, Crazy Alex (ok), 19:22, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    А куда деваться - с ростом сложности проектов явная типизация становится необходимостью - не только ради отлова ошибок, нои как вариант документации, которая всегда соответствует коду.

    Все там будем :-)

     
     
  • 3.61, chinarulezzz (ok), 23:51, 24/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Насчёт документации, Ларри как-то сказал, емнип, что старался насколько это можно, облегчить программерам написание документации. Вместо того, чтобы принуждать их подстраиваться под правила документирования, лучше как можно проще сделать для них документирование прямо в коде. И глянь на результат, у perl-коммюнити отличная документация.

    Так что, имхо, явная типизация не будет серебряной пулей. А вот отлов ошибок - да.

    >Все там будем :-)

    А как же прототипирование?)

     
     
  • 4.63, Вы забыли заполнить поле Name (?), 00:05, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    > у perl-коммюнити отличная документация.

    Это вы про простыни документации в перемшку с write-only perl кодом? Фигня это все. Кинул вас Ларри с вашими проблемами и 5-ым перлом.


     
     
  • 5.64, chinarulezzz (ok), 00:13, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    >> у perl-коммюнити отличная документация.
    > Это вы про простыни документации в перемшку с write-only perl кодом? Фигня
    > это все. Кинул вас Ларри с вашими проблемами и 5-ым перлом.

    Документацию можно выделить в отдельный pod, можно после кода, можно вместе с кодом. Смотреть и искать документацию можно perldoc'ом, где нет никакого кода. Писать можно с фолдингом, и ничего не мешает.

    P.S. Понимаю, что для новичков любой код на перле writeonly, но тот же DCONWAY, да и многие кто входит в top rated distributions пишут хороший код.

    P.P.S. Если такая уж и проблема, perltidy может перелопатить исходник в тот вид, в котором глазу будет приятно.


     
     
  • 6.67, freehck (ok), 11:31, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • –2 +/
    Да что Вы распинаетесь перед ним? Он же вполне ясно дал понять, что с Perl он знаком на уровне "одна бабка во дворе сказала":
    > Это вы про простыни документации в перемшку с write-only perl кодом?

    Чёртовы толстые тролли, позор зелёного братства.

     

  • 1.59, Blind Vic (ok), 22:59, 24/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    > Обеспечено сохранение порядка определения атрибутов класса (прядок можно отследить через новый атрибут "__dict__");

    Неверный перевод. Атрибут __dict__ совсем не новый.

    > This order is now preserved in the new class’s __dict__ attribute.

     
  • 1.66, freehck (ok), 11:07, 25/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    >>> width = 10
    >>> precision = 4
    >>> value = decimal.Decimal("12.34567")
    >>> f"result: {value:{width}.{precision}}"  # nested fields
    > 'result:      12.35'

    Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что - не понимаю в упор. :)

     
     
  • 2.68, Andrey Mitrofanov (?), 12:54, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> width = 10
    >>>> precision = 4
    >>>> value = decimal.Decimal("12.34567")
    >>>> f"result: {value:{width}.{precision}}"  # nested fields
    >> 'result:      12.35'
    > Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
    > - не понимаю в упор. :)

    sprintf( "result: %*.*f", width, precision, value) какой-нибудь, наверное. Да, sprintf(), как типа синтаксическая фича языка это надо...  Означаетли это что в _языке_ не достаточно средств композиции, синтеза, абстрацкции или чето там? Есть в зале CS-учёные, ну, хотя в объёме 3ёх курсов??---

     
     
  • 3.70, Stax (ok), 14:50, 25/12/2016 [^] [^^] [^^^] [ответить]  
  • +4 +/
    Причем тут вообще композиция и прочее?? Форматированию по имени, а не позиции сто лет в обед, это с каких-то древнейших вторых (если вообще не первых, но тут уже не помню) версий питона работает. И доступ к атрибутам всегда был. См. "Accessing arguments by name" и "Accessing arguments’ attributes" примеры: https://docs.python.org/2/library/string.html#format-examples

    По самой фиче - они просто добавили возможность обращаться к этим аргументам без явной передачи их в format() и синтаксический сахар f"строка" для замены "строка".format(). Путем некого извращения (и это довольно неэффективно с точки зрения того, как это в данном примере выполняется) это можно эмулировать вообще в любом питоне, как третьем, так и втором:

    >>> num=123
    >>> "num={num}".format(**locals())

    'num=123'
    >>> 'num=%(num)d' % locals()

    'num=123'

    Ну а с атрибутами (в примере с Decimal) оно автоматически получилось, т.к. эта возможность существовала и ранее.

     
     
  • 4.74, Аноним (-), 07:32, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    Да это же Сишники, что с них взять.
     
  • 3.76, freehck (ok), 12:33, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    >>>>> f"result: {value:{width}.{precision}}"  # nested fields
    >> Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
    >> - не понимаю в упор. :)
    > sprintf( "result: %*.*f", width, precision, value) какой-нибудь, наверное.

    О, и правда, похоже на то. Спасибо.

     
  • 2.77, Аноним (-), 12:33, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >>>> width = 10
    >>>> precision = 4
    >>>> value = decimal.Decimal("12.34567")
    >>>> f"result: {value:{width}.{precision}}"  # nested fields
    >> 'result:      12.35'
    > Офигеть, какой очевидный пример. Нет, оно что-то делает, очевидно, но вот что
    > - не понимаю в упор. :)

    Тут скорее забавен сам метод "float to string", когда pecision это количество цифр(значащих) а не количество после запятой :)
    Мне почему-то казалось что логически верным было бы приведение типа:
    'result:    12.3457' либо 'result: 1.2346e-1'

     
     
  • 3.83, oopsy (?), 23:19, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +1 +/
    Так получилось потому, что используется формат по умолчанию. А формат по умолчанию в данном случае будет g.

    Укажите явно f или e (например, "result: {value:{width}.{precision}f}" )
    будет как привычно со времён FORTRAN-IV
    'result:    12.3457' или 'result:  1.2346e+1'

    Впрочем, поведение формата g в python соответствует поведению в C.

     

  • 1.72, Аноним (-), 03:06, 26/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • –3 +/
    > Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;

    Обкурились что-ли?
    Было
    grep "0xFFFFFF" -nR .

    Стало
    find . | xargs grep '0xFFFFFF' -nR


     
     
  • 2.78, Аноним (-), 12:34, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
    > Обкурились что-ли?
    > Было
    > grep "0xFFFFFF" -nR .
    > Стало
    > find . | xargs grep '0xFFFFFF' -nR

    Питонисты никогда не страдали заботой о других :)

     
  • 2.79, freehck (ok), 12:36, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +/
    >> Возможность использования символов подчёркивания для улучшения читаемости чисел, например, теперь можно указывать 1_000_000 или 0x_FF_FF_FF;
    > Обкурились что-ли?

    Да ладно. Это было ещё в perl5, это есть в bash... :)

     

  • 1.80, Аноним (-), 15:15, 26/12/2016 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Мда... Ушел дальше программировать на LISP...
     
     
  • 2.81, Аноним (-), 17:52, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • +2 +/
    Не ясно только, чего заходил.
     
     
  • 3.82, Lisp (?), 18:53, 26/12/2016 [^] [^^] [^^^] [ответить]  
  • –1 +/
    Посмотреть на мучения хомячков всегда приятно )
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Партнёры:
    PostgresPro
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2024 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру