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
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* defined) in the registry.
I'm
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 not familiar with the Windows
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 but
> write the same reg
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 subst
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:
>
> http://www.rath.org/mercurial-for-git-users-and-vice
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 appropriat
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 somethin
> 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 http://bugs.python.org/iss
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 unstable,
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 average.
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
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 Python's registry use caus
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 that
> point alone, this sa
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 ad
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 th
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 (in much the same way th
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 portably,
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\**'))
sys.path.extend(read_subkeys(fr'HKLM\Software\Python\PythonCore\{sys.winver}\PythonPath\**'))
It seems like a b
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 spirit at least) that this
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 and zip to a "portable"
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, that's horrid but not reall
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 publicise better. People seem
u
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
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 stop touching the registry
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 t
...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 standa
27 matches
Mail list logo
