Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Alexander Walters
...just when I thought I have solved the registry headaches I have been dealing with... I am not saying this proposal will make the registry situation worse, but it may break my solution to the headaches Python's registry use causes with some non-standard module installers (and even the

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Glenn Linderman
On 2/3/2016 12:15 AM, Alexander Walters wrote: On a very personal note (like the rest of this wasn't my personal issues with possibly making my life slightly more difficult), I would much rather see python stop touching the registry all together - but I have no strong argument for that. Me

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Paul Moore
On 3 February 2016 at 09:50, Glenn Linderman wrote: > On 2/3/2016 12:15 AM, Alexander Walters wrote: > >> On a very personal note (like the rest of this wasn't my personal issues >> with possibly making my life slightly more difficult), I would much rather >> see python

Re: [Python-Dev] Opcode cache in ceval loop

2016-02-03 Thread francismb
Hi, On 02/01/2016 10:43 PM, Yury Selivanov wrote: > > We also need to deoptimize the code to avoid having too many cache > misses/pointless cache updates. I found that, for instance, LOAD_ATTR > is either super stable (hits 100% of times), or really unstable, so 20 > misses is, again, seems to

Re: [Python-Dev] Opcode cache in ceval loop

2016-02-03 Thread Sven R. Kunze
On 03.02.2016 22:22, Yury Selivanov wrote: One way of tackling this is to give each optimized opcode a counter for hit/misses. When we have a "hit" we increment that counter, when it's a miss, we decrement it. Within a given range, I suppose. Like: c = min(c+1, 100) I kind of have

Re: [Python-Dev] Opcode cache in ceval loop

2016-02-03 Thread Yury Selivanov
On 2016-02-03 3:53 PM, francismb wrote: Hi, On 02/01/2016 10:43 PM, Yury Selivanov wrote: We also need to deoptimize the code to avoid having too many cache misses/pointless cache updates. I found that, for instance, LOAD_ATTR is either super stable (hits 100% of times), or really

Re: [Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

2016-02-03 Thread Victor Stinner
> There is an old discussion about the performance of PyMem_Malloc() memory > allocator. Oops, I forgot to mention that my patch is a follow-up of a previous patch showing nice speedup on dict: http://bugs.python.org/issue23601 (but I said it in my issue ;-)) Well, see

[Python-Dev] Modify PyMem_Malloc to use pymalloc for performance

2016-02-03 Thread Victor Stinner
Hi, There is an old discussion about the performance of PyMem_Malloc() memory allocator. CPython is stressing a lot memory allocators. Last time I made statistics, it was for the PEP 454: "For example, the Python test suites calls malloc() , realloc() or free() 270,000 times per second in

[Python-Dev] Git for Mercurial Users

2016-02-03 Thread Nikolaus Rath
Hello, With the upcoming move to Git, I thought people might be interested in some thoughts that I wrote down when learning Git for the first time as a long-time Mercurial user: http://www.rath.org/mercurial-for-git-users-and-vice-versa.html Comments are welcome (but probably more

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 1120, Alexander Walters wrote: Uh its C:\Anaconda[2]\ for anyone running the installer with the privileges to edit the registry... (It wont ask to elevate unless you install for all users, and that's where all users will install). So on that point alone, this saves nothing

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 1851, eryk sun wrote: On Wed, Feb 3, 2016 at 7:33 PM, Eric Snow wrote: Just wanted to quickly point out another use of the WIndows registry in Python: WindowsRegistryFinder [1]. This is an import "meta-path" finder that locates modules declared (*not*

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread eryk sun
On Wed, Feb 3, 2016 at 7:33 PM, Eric Snow wrote: > Just wanted to quickly point out another use of the WIndows registry > in Python: WindowsRegistryFinder [1]. This is an import "meta-path" > finder that locates modules declared (*not* defined) in the registry. > I'm

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Eric Snow
On Tue, Feb 2, 2016 at 10:15 PM, Steve Dower wrote: > I was throwing around some ideas with colleagues about how we detect Python > installations on Windows from within Visual Studio, and it came up that > there are many Python distros that install into different locations

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 0015, Alexander Walters wrote: I am not saying this proposal will make the registry situation worse, but it may break my solution to the headaches Python's registry use causes with some non-standard module installers (and even the standard distutils exe installers, but that is being

Re: [Python-Dev] Git for Mercurial Users

2016-02-03 Thread Chris Angelico
On Thu, Feb 4, 2016 at 10:38 AM, Nikolaus Rath wrote: > Hello, > > With the upcoming move to Git, I thought people might be interested in some > thoughts that I wrote down when learning Git for the first time as a > long-time Mercurial user: > >

[Python-Dev] speed.python.org

2016-02-03 Thread Zachary Ware
I'm happy to announce that speed.python.org is finally functional! There's not much there yet, as each benchmark builder has only sent one result so far (and one of those involved a bit of cheating on my part), but it's there. There are likely to be rough edges that still need smoothing out. When

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 0923, eryk sun wrote: On Wed, Feb 3, 2016 at 10:46 AM, Steve Dower wrote: sys.path.extend(read_subkeys(fr'HKCU\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 0839, Paul Moore wrote: On 3 February 2016 at 16:29, Steve Dower wrote: Final point I want to reiterate - Python itself is essentially registry free already in that it does not need registry settings to function. That's something we should probably

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Paul Moore
On 3 February 2016 at 17:04, Steve Dower wrote: > Rest of the email is spelling out how to create the scenario above, since I > assume people won't believe it :) > > 1. Take Python 3.4.1, install it (Just for Me), zip up the stdlib into > python34.zip and copy the binaries

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread eryk sun
On Wed, Feb 3, 2016 at 10:46 AM, Steve Dower wrote: > > sys.path.extend(read_subkeys(fr'HKCU\Software\Python\PythonCore\{sys.winver}\PythonPath\**')) > sys.path.extend(read_subkeys(fr'HKLM\Software\Python\PythonCore\{sys.winver}\PythonPath\**')) It seems like a bug (in

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Paul Moore
On 3 February 2016 at 16:46, Steve Dower wrote: > So a few high-level observations: > > * any program can install anywhere on the machine and make its libraries > available to a specific version of Python by creating a subkey under > 'PythonCore\x.y\PythonPath' Yeah,

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Paul Moore
On 3 February 2016 at 19:20, Alexander Walters wrote: > Uh its C:\Anaconda[2]\ for anyone running the installer with the > privileges to edit the registry... (It wont ask to elevate unless you > install for all users, and that's where all users will install). So on

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Alexander Walters
On 2/3/2016 11:17, Steve Dower wrote: I know for PTVS manually adding a python environment to visual studio is trivial - you fill in three locations, and its done. Just today I added a python environment to my system that was not autodetected. It took under a minute and almost no effort to

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Paul Moore
On 3 February 2016 at 16:29, Steve Dower wrote: > Final point I want to reiterate - Python itself is essentially registry free > already in that it does not need registry settings to function. That's something we should probably publicise better. People seem unaware of it

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 0150, Glenn Linderman wrote: Portable software exists, but often is 3rd party hacks of popular FOSS rather than being directly supported by the FOSS development team. Python falls into this category. Happily, I recently found WinPython Zero, which hacks it (somehow) to work

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Steve Dower
On 03Feb2016 0321, Paul Moore wrote: > Some issues with this proposal: > > 1. I don't like the way it states that Python distributions "must" set > keys. I'd rather that it were explicitly stated that a distribution > which sets no registry keys is entirely valid (with the obvious > implication

Re: [Python-Dev] Python environment registration in the Windows Registry

2016-02-03 Thread Matthew Einhorn
On Wed, Feb 3, 2016 at 3:15 AM, Alexander Walters wrote: > ...just when I thought I have solved the registry headaches I have been > dealing with... > > I am not saying this proposal will make the registry situation worse, but > it may break my solution to the headaches