Mailman 3 December 2019 - Python-Dev

PEP 587
by Ayush Das 06 Dec '19

06 Dec '19

Hii.I want to download Python 3.8.0 at my mobile.Please help me to download.

2 1

Deprecating the "u" string literal prefix
by Serhiy Storchaka 05 Dec '19

05 Dec '19

The 'u" string literal prefix was removed in 3.0 and reintroduced in 3.3 to help writing the code compatible with Python 2 and 3 [1]. After the dead of Python 2.7 we will remove some deprecated features kept for compatibility with 2.7. When we are going to deprecate and remove the "u" prefix? [1] https://www.python.org/dev/peps/pep-0414/

21 37

Re: Deprecating the "u" string literal prefix
by Anders Munch 05 Dec '19

05 Dec '19

>> I'm struggling to see what i-strings would do for i18n that str.format doesn't do better. Serhiy Storchaka [mailto:storchaka@gmail.com] > You would not need to repeat yourself. > _('{name} costs ${price:.2f}').format(name=name, price=price) A small price to pay for having a well-defined interface with the translator. Security is one reason: A translator could sneak {password} or {signing_key} into an unrelated string, if those names happen to be present in the namespace. That may not seem like a big issue if you've only ever used gettext/.po-file translation, where the translation is pre-built with the program, but in a more dynamic setting where end-users can supply translations, it's a different story. You could parse the strings and require translations to have the same variables, but that is limiting. E.g. that would mean you couldn't translate 'Welcome, {first_name}' into 'Willkommen, {title} {last_name}' Another reason is that you don't want variable names in your program and translations to have to change in lock-step. E.g. you might change your code to: _('{name} costs ${price:.2f}').format(name=prod.short_name, price=context.convert_to_chosen_currency(price)) without needing to change any translations. regards, Anders

2 1

Macros instead of inline functions?
by Skip Montanaro 05 Dec '19

05 Dec '19

As I wander around the code base, I keep seeing macro definitions in the C code. For example, there are four CALL* macros defined in Python/ast_opt.c which contain not entirely trivial bits of syntax. That code is from 2017 (as compared to, say, Modules/audioop.c, which first saw the light of day in 1992) I see the inline keyword used unconditionally in many places. I don't think stable code which uses macros should be changed (though I see the INCREF/DECREF macros just call private inline functions, so some conversion has clearly been done). Still, in new code, shouldn't the use of macros for more than trivial use cases (constant defs, simple one-liners) be discouraged at this point? Skip

5 8

Re: Deprecating the "u" string literal prefix
by Anders Munch 05 Dec '19

05 Dec '19

Barry Warsaw [mailto:barry@python.org] wrote: > str.format() really isn’t enough to do proper i18n; it’s actually a fairly complex topic. Obviously. > I’m not convinced that PEP 501 would provide much benefit on the technical side. My point exactly. > flufl.i18n - https://flufli18n.readthedocs.io/en/latest/ This seems to retrieve variables from the surrounding scope, in a manner reminiscent of f-strings (though obviously implemented very differently). I would never use that for translatable strings, partly on security grounds, and partly because it adds coupling between UI texts and code. regards, Anders

1 0

3.8.1rc1, 3.7.6rc1, and 3.6.10rc1 cutoffs ahead
by Ned Deily 05 Dec '19

05 Dec '19

It's that time for another reminder: code cutoffs for the last scheduled releases of 2019 are coming up soon. They are a little earlier than usual to try to avoid the end-of-December rush of various holidays. Łukasz will have more details forthcoming about **3.8.1rc1**. For the **3.7 branch**, the cutoff for **3.7.6rc1** is scheduled for this coming Monday (2019-12-09) by the end of day AOE. I have also now scheduled the cutoff for the next cumulative security source release for the **3.6 branch**, **3.6.10rc1**, for Monday as well. Please review open issues and ensure that any that you believe need to be addressed in any of these releases are either resolved or marked as a **release blocker**. Any assistance you can provide in helping resolve issues will be greatly appreciated. As usual, following the rc1 cutoff, changes merged to the 3.7 branch will be released in **3.7.7** three months from now unless you mark the issue as a release blocker prior to **3.7.6 final**, planned for release on **2019-12-16**, and explain why the change should be cherry-picked into the final release. And as always, any proposed changes for the 3.6 branch need to meet the criteria for security branches and require release manager approval to merge. Thanks for your continued efforts! 3.8 release PEP: https://www.python.org/dev/peps/pep-0569/ 3.7 release PEP: https://www.python.org/dev/peps/pep-0537/ 3.6 release PEP: https://www.python.org/dev/peps/pep-0494/ Security branch criteria: https://devguide.python.org/devcycle/#security-branches -- Ned Deily nad(a)python.org -- []

1 0

Multiple reference leaks in master
by Pablo Galindo Salgado 04 Dec '19

04 Dec '19

Hi, Me (and Victor) have not been able to attend the buildbots for a while unfortunately and today I was checking them out after some fixes to the SSL tests and sadly the refleaks buildbots have many independent issues. At least these tests are failing due to reference leaks: test__xxsubinterpreters, test_atexit, test_capi, test_httpservers, test_threading I am trying to slowly fix them but finding them and debugging often takes several hours per leak. I was tracking them in https://bugs.python.org/issue38962 until I discover that there are multiple sources of leaks so I may open more issues. Please, when you merge a PR, take a look at the buildbots (especially the refleak buildbots that do not report still to the PR in case of failure) so the issues don't keep piling up, as multiple refleaks together are much difficult to deal with. Thanks, everyone! Regards from cloudy London, Pablo Galindo Salgado

4 6

Re: Deprecating the "u" string literal prefix
by Anders Munch 04 Dec '19

04 Dec '19

Chris Angelico [mailto:rosuav@gmail.com] wrote: > The first one is already the case. PEP 414 reintroduced the u"..." literal form, specifically > as a porting tool. Given that it has absolutely zero value in pure Py3 code [...] Challenge accepted :) Here comes my https://xkcd.com/1172/ moment. I'm using the u prefix to tag user interface strings for translation. u"..." goes through i18n, "..." doesn't. I have tools that extract and replace texts, identify new strings for translation etc. based on this. I was very happy when 3.3 reintroduced the prefix, because it allowed me to upgrade without losing my very efficient workflow. Not to mention having to make 10.000 code changes to replace the prefix with something or other. If the prefix goes, I'm not going to complain, I know my setup is fairly unique and I can't really demand that you keep vestigial syntax around just for that. But I'd still be sorry to see it go. regards, Anders

2 1

HighwayHash > SipHash?
by Larry Hastings 03 Dec '19

03 Dec '19

My random Googling turned up a new hash function tonight: "HighwayHash". It's a keyed hash function like the SipHash we now use for hashing strings / bytes / etc for our lovely dicts. Key points: * Apache 2 license * Can use SIMD * "5x faster than SipHash" I think they mean 5x faster than /their/ SipHash implementation, which they claim is an optimized implementation (but IIUC doesn't use SIMD). Source is here: https://github.com/google/highwayhash AFAICT they have multiple implementations to leverage different processor features, but one is vanilla portable C** so it should run everywhere Python 3 does. In fact it already has a Python 3 package ("pip3 install highwayhash-cffi") in case you want to play around with it. Since the choice of SipHash is a private implementation detail, and since we all like fast things, is it worth considering switching to HighwayHash? Don't ask me, I'm only a release manager (for a version nobody cares about anymore). These things are above my pay grade. Cheers, //arry/ ** They claim it's "C90", which I gather is C89 for Europeans hipsters who like obscure, withdrawn standards.

2 1