Barry Warsaw [mailto:firstname.lastname@example.org] wrote:
> str.format() really isn’t enough to do proper i18n; it’s actually a fairly complex topic.
> 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.
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
nad(a)python.org -- 
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
test__xxsubinterpreters, test_atexit, test_capi, test_httpservers,
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.
Regards from cloudy London,
Pablo Galindo Salgado
Chris Angelico [mailto:email@example.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.
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.
* 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:
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.
** They claim it's "C90", which I gather is C89 for Europeans hipsters
who like obscure, withdrawn standards.
Having tried comp.lang.python with no response, I turn here...
After at least ten years away from Python's run-time interpreter &
byte code compiler, I'm getting set to familiarize myself with that
again. This will, I think, entail debugging a mixed Python/C
environment. I'm an Emacs user and am aware that GDB since 7.0 has
support for debugging at the Python code level. Is Emacs+GDB my best
bet? Are there any Python IDEs which support C-level breakpoints and