Mailman 3 September 2018 - Python-ideas

Retire or reword the "Beautiful is better than ugly" Zen clause
by Samantha Quan Sept. 17, 2018

Sept. 17, 2018

31 56

Re: [Python-ideas] SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register
by Wes Turner Sept. 17, 2018

Sept. 17, 2018

Are all current Python builds and C extensions vulnerable to Spectre variants {1, 2, *}? There are now multiple threads: "SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register" - https://mail.python.org/mm3/archives/list/distutils-sig@python.org/thread/4… - https://mail.python.org/pipermail/python-ideas/2018-September/053473.html - https://mail.python.org/pipermail/python-dev/2018-September/155199.html Original thread (that I forwarded to security@): "[Python-… [View More]ideas] Executable space protection: NX bit," https://mail.python.org/pipermail/python-ideas/2018-September/053175.html > ~ Do trampolines / nested functions in C extensions switch off the NX bit? On Sunday, September 16, 2018, Nathaniel Smith <njs(a)pobox.com> wrote: > On Wed, Sep 12, 2018, 12:29 Joni Orponen <j.orponen(a)4teamwork.ch> wrote: > >> On Wed, Sep 12, 2018 at 8:48 PM Wes Turner <wes.turner(a)gmail.com> wrote: >> >>> Should C extensions that compile all add >>> `-mindirect-branch=thunk -mindirect-branch-register` [1] to mitigate the >>> risk of Spectre variant 2 (which does indeed affect user space applications >>> as well as kernels)? >>> >> >> Are those available on GCC <= 4.2.0 as per PEP 513? >> > > Pretty sure no manylinux1 compiler is ever going to get these mitigations. > > For manylinux2010 on x86-64, we can easily use a much newer compiler: RH > maintains a recent compiler, currently gcc 7.3, or if that doesn't work for > some reason then the conda folks have be apparently figured out how to > build the equivalent from gcc upstream releases. > Are there different CFLAGS and/or gcc compatibility flags in conda builds of Python and C extensions? Where are those set in conda builds? What's the best way to set CFLAGS in Python builds and C extensions? export CFLAGS="-mindirect-branch=thunk -mindirect-branch-register" ./configure make ? Why are we supposed to use an old version of GCC that doesn't have the retpoline patches that only mitigate Spectre variant 2? > > Unfortunately, the manylinux2010 infrastructure is not quite ready... I'm > pretty sure it needs some volunteers to push it to the finish line, though > unfortunately I haven't had enough time to keep track. > "PEP 571 -- The manylinux2010 Platform Tag" https://www.python.org/dev/peps/pep-0571/ "Tracking issue for manylinux2010 rollout" https://github.com/pypa/manylinux/issues/179 Are all current Python builds and C extensions vulnerable to Spectre variants {1, 2, *}? > [View Less]

1 0

SEC: Spectre variant 2: GCC: -mindirect-branch=thunk -mindirect-branch-register
by Wes Turner Sept. 16, 2018

Sept. 16, 2018

Should Python builds add `-mindirect-branch=thunk -mindirect-branch-register` to CFLAGS? Where would this be to be added in the build scripts with which architectures? /QSpectre is the MSVC build flag for Spectre Variant 1: > The /Qspectre option is available in Visual Studio 2017 version 15.7 and later. https://docs.microsoft.com/en-us/cpp/build/reference/qspectre?view=vs-2017 security@ directed me to the issue tracker / lists, so I'm forwarding this to python-dev and python-ideas, as … [View More]

1 1

+1 Pre-conditions and post-conditions by Kaufmann
by James Lu Sept. 16, 2018

Sept. 16, 2018

In response to your Sat, 15 Sep 2018 22:14:43: A good and thoughtful read. I agree with all your points. +1.

1 0

Improving fn(arg=arg, name=name, wibble=wibble) code
by Jonathan Fine Sept. 14, 2018

Sept. 14, 2018

I thank Steve D'Aprano for pointing me to this real-life (although perhaps extreme) code example https://github.com/Tinche/aiofiles/blob/master/aiofiles/threadpool/__init__… <code> def open(file, mode='r', buffering=-1, encoding=None, errors=None, newline=None, closefd=True, opener=None, *, loop=None, executor=None): return AiofilesContextManager(_open(file, mode=mode, buffering=buffering, encoding=encoding, errors=errors, … [View More]

5 30

__iter__(), keys(), and the mapping protocol
by Elias Tarhini Sept. 13, 2018

Sept. 13, 2018

This has been bouncing around in my head for a while regarding the requisite keys() method on mappings: How come the ** unpacking operator, a built-in language feature, relies on a non-dunder to operate? To me, I mean to say, requiring that classes implement keys() – a method whose name is totally undistinguished – in order to conform to the mapping protocol feels like a design running counter to Python's norm of using dunders for everything "hidden". I am not sure if it feels dirty to … [View More]

6 9

PTPython REPL in IDLE
by James Lu Sept. 13, 2018

Sept. 13, 2018

Have y’all seen ptpython’s autocomplete and syntax highlighting features? Ptpython, usually used as a cli application, might be worth integrating into IDLE.

3 2

Re: [Python-ideas] Python dialect that compiles into python
by David Teresi Sept. 13, 2018

Sept. 13, 2018

Not totally convinced about this. It would require PEP writers to fully implement their proposed feature, people can usually get a pretty good idea of how a feature is supposed to work through PEPs (most of which are extremely well written), and these "mods" wouldn't be used in production code anyway since they're not backwards compatible with the rest of the language.On Sep 10, 2018 8:15 PM, Abe Dillon <abedillon(a)gmail.com> wrote: > > [Steven D'Aprano] >> >> It … [View More]would be great for non-C coders to be able to prototype proposed >> syntax changes to get a feel for what works and what doesn't. > > > I think it would be great in general for the community to be able to try out ideas and mull things over. > > If there was something like a Python Feature Index (PyFI) and you could install mods to the language, > it would allow people to try out ideas before rejecting them or incorporating them into the language > (or putting them on hold until someone suggests a better implementation). > > I could even see features that never make it into the language, but stick around PyFI and get regular > maintenance because: > A) they're controversial changes that some love and some hate > B) they make things easier in some domain but otherwise don't warrant adoption > > It would have to be made clear from the start that Python can't guarantee backward compatibility with > any mods, which should prevent excessive fragmentation (if you want your code to be portable, don't > use mod). > > On Fri, Sep 7, 2018 at 7:30 PM Steven D'Aprano <steve(a)pearwood.info> wrote: >> >> On Fri, Sep 07, 2018 at 11:57:50AM +0000, Robert Vanden Eynde wrote: >> >> > Many features on this list propose different syntax to python, >> > producing different python "dialects" that can statically be >> > transformed to python : >> >> [...] >> > Using a modified version of ast, it is relatively easy to modifiy the >> > syntax tree of a program to produce another program. So one could >> > compile the "python dialect" into regular python. The last example >> > with partially for example doesn't even need new syntax. >> >> [...] >> > Actually, I might start to write this lib, that looks fun. >> >> I encourage you to do so! It would be great for non-C coders to be able >> to prototype proposed syntax changes to get a feel for what works and >> what doesn't. >> >> There are already a few joke Python transpilers around, such as >> "Like, Python": >> >> https://jon.how/likepython/ >> >> but I think this is a promising technique that could be used more to >> keep the core Python language simple while not *entirely* closing the >> door to people using domain-specific (or project-specific) syntax. >> >> >> -- >> Steve >> _______________________________________________ >> Python-ideas mailing list >> Python-ideas(a)python.org >> https://mail.python.org/mailman/listinfo/python-ideas >> Code of Conduct: http://python.org/psf/codeofconduct/ [View Less]

1 0

Off-topic: Email with content: Cannot read property 'get' of null
by Jonathan Fine Sept. 12, 2018

Sept. 12, 2018

This is off-topic, but you might enjoy reading it. I got an email today, whose entire body text was Cannot read property 'get' of null It reminded me of our discussions of None-aware operators. And also Errors should never pass silently. Unless explicitly silenced. -- Jonathan

1 0

PEP 420: implicit namespace sub-package
by Gallian Colombeau Sept. 12, 2018

Sept. 12, 2018

Hello, the PEP 420 (Implicit Namespace Packages) is quite descriptive about the problem and the solution implemented back in Python 3.3 but I feel there may be a part missing (but maybe this is categorized as an implementation detail). As I understand, for a package to allow being extended in this way, it must be a namespace package and not contain a marker file. As a matter of fact, no sub-package until the top level package can have a marker file: Lib/test/namespace_pkgs project1 … [View More]

3 2