[Python-Dev] Looking for examples: proof that a list comp is a function

Guido has stated that this parallel is desired and important: result = [f(x) for x in iter if g(x)] result = list(f(x) for x in iter if g(x)) Obviously the genexp has to be implemented with a nested function, since there's no guarantee that it'll be iterated over in this way. With current semanti

Re: [Python-Dev] Looking for examples: proof that a list comp is a function

On Mon, May 14, 2018, 03:36 Chris Angelico wrote: > Guido has stated that this parallel is desired and important: > > result = [f(x) for x in iter if g(x)] > result = list(f(x) for x in iter if g(x)) > > Obviously the genexp has to be implemented with a nested function, > since there's no guarant

Re: [Python-Dev] Looking for examples: proof that a list comp is a function

[Chris Angelico ... > With current semantics, you can easily prove that a list comp is > implemented with a function by looking at how it interacts with other > scopes (mainly class scope), but Tim's proposal may change that. Absolutely not. I haven't considered for a nanosecond that anything _e

Re: [Python-Dev] Looking for examples: proof that a list comp is a function

On 14 May 2018 at 04:05, Tim Peters wrote: > I say "pretty much" because, for whatever reason(s), it seems to be > trying hard _not_ to use the word "function". But I can't guess what > "then passed as an argument to the implicitly nested scope" could > possibly mean otherwise (it doesn't make l

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On Wed, May 2, 2018 at 8:21 PM, Terry Reedy wrote: > On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote: > >> The bottom line is: Tkinter is currently broken >> > > This is way over-stated. Many modules have bugs, somethings in features > more central to their main purpose. I'll suggest a

Re: [Python-Dev] Python startup time

On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote: > https://refi64.com/uprocd/ very cool -- but *nix only, of course :-( But it seems that there is a demand for this sort of thing, and a few major projects are rolling their own. So maybe it makes sense to put something into the standard

Re: [Python-Dev] Python startup time

On Tue, May 15, 2018 at 1:29 AM Chris Barker via Python-Dev < python-dev@python.org> wrote: > On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez wrote: >> https://refi64.com/uprocd/ > very cool -- but *nix only, of course :-( > But it seems that there is a demand for this sort of thing, and a

Re: [Python-Dev] Python startup time

On Mon, May 14, 2018 at 12:33 PM, INADA Naoki wrote: > It will broke hash randomization. > > See also: https://www.cvedetails.com/cve/CVE-2017-11499/ I'm not enough of a security expert to know how much that matters in this case, but I suppose one could do a bit of post-proccessing on the image

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Sat, May 12, 2018 at 8:14 AM, Skip Montanaro wrote: > > I have found 2to3 conversion to be remarkably easy and painless. > > > And the whole Unicode thing is much easier. > Another point here: between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it easier to write py2/py3

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On 05/14/2018 09:34 AM, Chris Barker via Python-Dev wrote: between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it easier to write py2/py3 compatible code. u"string", b'bytes %i' % something -- and when where the various __future__ imports made available? If these had been

Re: [Python-Dev] Python startup time

On Tue, 15 May 2018 01:33:18 +0900 INADA Naoki wrote: > > It will broke hash randomization. > > See also: https://www.cvedetails.com/cve/CVE-2017-11499/ I don't know why it would. The mechanism of pre-initializing a process which is re-used accross many requests is how most server applications

Re: [Python-Dev] bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)

13.05.18 20:42, Christian Heimes пише: I was against the approach a good reason. The PR adds additional CPU instructions and changes memory access pattern in a critical path of CPython. There is no reason to add additional overhead for the majority of users or X86 and X86_64 architectures. The m

Re: [Python-Dev] Python startup time

I'm sorry, the word *will* may be stronger than I thought. I meant if memory image dumped on disk is used casually, it may make easier to make security hole. For example, if `hg` memory image is reused, and it can be leaked in some way, hg serve will be hashdos weak. I don't deny that it's usefu

Re: [Python-Dev] Python startup time

Le 14/05/2018 à 19:12, INADA Naoki a écrit : > I'm sorry, the word *will* may be stronger than I thought. > > I meant if memory image dumped on disk is used casually, > it may make easier to make security hole. > > For example, if `hg` memory image is reused, and it can be leaked in some > way,

Re: [Python-Dev] Python startup time

2018年5月15日(火) 2:17 Antoine Pitrou : > > Le 14/05/2018 à 19:12, INADA Naoki a écrit : > > I'm sorry, the word *will* may be stronger than I thought. > > > > I meant if memory image dumped on disk is used casually, > > it may make easier to make security hole. > > > > For example, if `hg` memory ima

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

On Monday, May 14, 2018, Ethan Furman wrote: > On 05/14/2018 09:34 AM, Chris Barker via Python-Dev wrote: > > between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it >> easier to write py2/py3 compatible code. >> u"string", b'bytes %i' % something -- and when where the various

Re: [Python-Dev] Python startup time

On Mon, May 14, 2018 at 12:26:19PM -0400, Chris Barker via Python-Dev wrote: > With regard to forking -- is there another way? I don't have the expertise > to have any idea if this is possible, but: > > start up python > > capture the entire runtime image as a single binary blob. > could that b

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] bpo-28055: Fix unaligned accesses in siphash24(). (GH-6123)

On 5/13/18, 12:44 PM, "Python-Dev on behalf of Christian Heimes" wrote: On 2018-05-13 06:57, Serhiy Storchaka wrote: > https://github.com/python/cpython/commit/1e2ec8a996daec65d8d5a3d43b66a9909c6d0653 > commit: 1e2ec8a996daec65d8d5a3d43b66a9909c6d0653 > branch: master > a

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On 5/14/2018 12:20 PM, Chris Barker via Python-Dev wrote: On Wed, May 2, 2018 at 8:21 PM, Terry Reedy > wrote: On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote: The bottom line is: Tkinter is currently broken This is way over-stated.  Many module

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On 14.05.2018 21:58, Terry Reedy wrote: On 5/14/2018 12:20 PM, Chris Barker via Python-Dev wrote: On Wed, May 2, 2018 at 8:21 PM, Terry Reedy > wrote:     On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote:     The bottom line is: Tkinter is currently broken

Re: [Python-Dev] bpo-33257: seeking advice & approval on the course of action

On 14.05.2018 22:05, Ivan Pozdeev wrote: On 14.05.2018 21:58, Terry Reedy wrote: On 5/14/2018 12:20 PM, Chris Barker via Python-Dev wrote: On Wed, May 2, 2018 at 8:21 PM, Terry Reedy > wrote:     On 5/2/2018 4:38 PM, Ivan Pozdeev via Python-Dev wrote:     The bott

Re: [Python-Dev] Python startup time

On 14.05.2018 18:26, Chris Barker via Python-Dev wrote: > > > On Fri, May 11, 2018 at 11:05 AM, Ryan Gonzalez > wrote: > > https://refi64.com/uprocd/ > > > very cool -- but *nix only, of course :-( > > But it seems that there is a demand for this sort of thing

Re: [Python-Dev] PEP 575 (Unifying function/method classes) update

On 05/05/18 04:55, Jeroen Demeyer wrote: Hello all, I have updated PEP 575 in response to some posts on this mailing list and to some discussions in person with the core Cython developers. See https://www.python.org/dev/peps/pep-0575/ The main differences with respect to the previous version

Re: [Python-Dev] (Looking for) A Retrospective on the Move to Python 3

> between 3.0 and 3.6 (.5?) -- py3 grew a lot of minor features that made it >> easier to write py2/py3 compatible code. >> u"string", b'bytes %i' % something -- and when where the various >> __future__ imports made available? >> > > You'll need to be more specific. __future__ has been around for

[Python-Dev] Changes to configure.ac, auto-detection and related build issues

Hi all, Hope this is an appropriate list to send this message to; if not, please redirect me. I am working on updating, fixing, or otherwise changing python's configure.ac. This work is complex, lacks dedicated unit tests, and is easy to miss corner cases. As these changes make it into master I'l

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

Hi Eitan, 2018-05-15 0:01 GMT-04:00 Eitan Adler : > I am working on updating, fixing, or otherwise changing python's > configure.ac. This work is complex, (...) Is your work public? Is there an open issue on bugs.python.org or an open pull request? If not, would you mind to at least describe the

Re: [Python-Dev] Changes to configure.ac, auto-detection and related build issues

On Monday, 14 May 2018, Victor Stinner wrote: > Hi Eitan, > > 2018-05-15 0:01 GMT-04:00 Eitan Adler : > > I am working on updating, fixing, or otherwise changing python's > > configure.ac. This work is complex, (...) > > Is your work public? Is there an open issue on bugs.python.org or an > open