The 3.4 issue where ordering matters is a bug in the MSI, incidentally (there's
an extra upgrade code in one of them).
Python 3.5 does not have the issue and side by side works correctly for both
per-user and all-user installs.
Top-posted from my Windows Phone
-Original Message-
From:
On 28 July 2016 at 17:51, Barry Scott wrote:
> Why do you need SysArchitecture? Surely the 32bit pythons are registered in
> the 32bit registry and the 64 bit pythons in the 64 bit registry.
Per-user installs go in HKEY_CURRENT_USER, which is not
architecture-specific. So you either need SysArch
Lele Gaifax writes:
> Paul Moore writes:
>
>> If you were interested in doing that, I'd suggest opening a tracker issue
>> with a patch.
>
> Excellent, will do that, thank you for the encouragement!
See http://bugs.python.org/issue27645
Thank you in advance for any feedback!
ciao, lele.
--
n
Why do you need SysArchitecture? Surely the 32bit pythons are registered in the
32bit registry and the 64 bit pythons in the 64 bit registry.
you can side by side install python 3.4 but only if you install 64 bit first
then 32 bit second.
Barry
> On 15 Jul 2016, at 23:20, Steve Dower wrote:
On 29 July 2016 at 00:06, Joao S. O. Bueno wrote:
> Maybe then adding a `run_init_subclass` class decorator on the stdlib
> to go along with the pep?
> It should be a two liner that would avoid boiler plate done wrong -
> but more important than thatm is that it being documented alog with
> the _
On 28 July 2016 at 10:53, Nick Coghlan wrote:
> On 28 July 2016 at 23:12, Joao S. O. Bueno wrote:
>> Although I know it is not straightforward to implement (as the
>> "metaclass" parameter is not passed to the metaclass __new__ or
>> __init__), wouldn't it make sense to make it be passed to
>> _
On 28 July 2016 at 23:12, Joao S. O. Bueno wrote:
> Although I know it is not straightforward to implement (as the
> "metaclass" parameter is not passed to the metaclass __new__ or
> __init__), wouldn't it make sense to make it be passed to
> __init_subclass__ just like all other keywords? (the
On 28 July 2016 at 04:26, Nick Coghlan wrote:
> On 28 July 2016 at 13:55, Joao S. O. Bueno wrote:
>> Actually, as documented on the PEP (and I just confirmed at a Python
>> 3.5 prompt),
>> you actually can't use custom keywords for class defintions. This PEP
>> fixes that, but at the same time ma
On 28 July 2016 at 13:55, Joao S. O. Bueno wrote:
> Actually, as documented on the PEP (and I just confirmed at a Python
> 3.5 prompt),
> you actually can't use custom keywords for class defintions. This PEP
> fixes that, but at the same time makes any other class reserved
> keyword impossible in
