Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Steve Dower]

On 23Jul2016 1320, Guido van Rossum wrote:

I'll let Paul pronounce. But you should probably have a BDFL-Delegate:
... header.


Yeah, my headers are a bit outdated... I'm not even sure the $Revision$ 
and $Date$ variables are going to be substituted anymore (unless it's a 
pep2html thing rather than a VCS thing?).


I'll definitely update BDFL-Delegate, Post-History, Status and 
Resolution tags for the final PR.


Thanks,
Steve

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 514: Python registration in the Windows registry

[Guido van Rossum]

I'll let Paul pronounce. But you should probably have a BDFL-Delegate:
... header.

On Sat, Jul 23, 2016 at 12:16 PM, Steve Dower  wrote:
> PEP 514 is now ready for pronouncement, so this is the last chance for any
> feedback (BDFL-delegate Paul has been active on the github PR, so I don't
> expect he has a lot of feedback left).
>
> The most major change from the previous post is the addition of some code
> examples at the end. Honestly, I don't expect many tools written in Python
> to be scanning the registry (since once you're in Python you probably don't
> need to find it), but hopefully they'll help clarify the PEP for people who
> prefer code.
>
> Full text below.
>
> Cheers,
> Steve
>
> --
>
> PEP: 514
> Title: Python registration in the Windows registry
> Version: $Revision$
> Last-Modified: $Date$
> Author: Steve Dower 
> Status: Draft
> Type: Informational
> Content-Type: text/x-rst
> Created: 02-Feb-2016
> Post-History: 02-Feb-2016, 01-Mar-2016, 18-Jul-2016
>
> Abstract
> 
>
> This PEP defines a schema for the Python registry key to allow third-party
> installers to register their installation, and to allow tools and
> applications
> to detect and correctly display all Python environments on a user's machine.
> No
> implementation changes to Python are proposed with this PEP.
>
> Python environments are not required to be registered unless they want to be
> automatically discoverable by external tools. As this relates to Windows
> only,
> these tools are expected to be predominantly GUI applications. However,
> console
> applications may also make use of the registered information. This PEP
> covers
> the information that may be made available, but the actual presentation and
> use
> of this information is left to the tool designers.
>
> The schema matches the registry values that have been used by the official
> installer since at least Python 2.5, and the resolution behaviour matches
> the
> behaviour of the official Python releases. Some backwards compatibility
> rules
> are provided to ensure tools can correctly detect versions of CPython that
> do
> not register full information.
>
> Motivation
> ==
>
> When installed on Windows, the official Python installer creates a registry
> key
> for discovery and detection by other applications. This allows tools such as
> installers or IDEs to automatically detect and display a user's Python
> installations. For example, the PEP 397 ``py.exe`` launcher and editors such
> as
> PyCharm and Visual Studio already make use of this information.
>
> Third-party installers, such as those used by distributions, typically
> create
> identical keys for the same purpose. Most tools that use the registry to
> detect
> Python installations only inspect the keys used by the official installer.
> As a
> result, third-party installations that wish to be discoverable will
> overwrite
> these values, often causing users to "lose" their original Python
> installation.
>
> By describing a layout for registry keys that allows third-party
> installations
> to register themselves uniquely, as well as providing tool developers
> guidance
> for discovering all available Python installations, these collisions should
> be
> prevented. We also take the opportunity to add some well-known metadata so
> that
> more information can be presented to users.
>
> Definitions
> ===
>
> A "registry key" is the equivalent of a file-system path into the registry.
> Each
> key may contain "subkeys" (keys nested within keys) and "values" (named and
> typed attributes attached to a key). These are used on Windows to store
> settings
> in much the same way that directories containing configuration files would
> work.
>
> ``HKEY_CURRENT_USER`` is the root of settings for the currently logged-in
> user,
> and this user can generally read and write all settings under this root.
>
> ``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
> user can read these settings but only administrators can modify them. It is
> typical for values under ``HKEY_CURRENT_USER`` to take precedence over those
> in
> ``HKEY_LOCAL_MACHINE``.
>
> On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a special
> key
> that 32-bit processes transparently read and write to rather than accessing
> the
> ``Software`` key directly.
>
> Further documentation regarding registry redirection on Windows is available
> from the MSDN Library [1]_.
>
> Structure
> =
>
> We consider there to be a single collection of Python environments on a
> machine,
> where the collection may be different for each user of the machine. There
> are
> three potential registry locations where the collection may be stored based
> on
> the installation options of each environment::
>
> HKEY_CURRENT_USER\Software\Python\\
> HKEY_LOCAL_MACHINE\Software\Python\\
> HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\
>
> Official 

[Python-Dev] PEP 514: Python registration in the Windows registry

[Steve Dower]

PEP 514 is now ready for pronouncement, so this is the last chance for 
any feedback (BDFL-delegate Paul has been active on the github PR, so I 
don't expect he has a lot of feedback left).


The most major change from the previous post is the addition of some 
code examples at the end. Honestly, I don't expect many tools written in 
Python to be scanning the registry (since once you're in Python you 
probably don't need to find it), but hopefully they'll help clarify the 
PEP for people who prefer code.


Full text below.

Cheers,
Steve

--

PEP: 514
Title: Python registration in the Windows registry
Version: $Revision$
Last-Modified: $Date$
Author: Steve Dower 
Status: Draft
Type: Informational
Content-Type: text/x-rst
Created: 02-Feb-2016
Post-History: 02-Feb-2016, 01-Mar-2016, 18-Jul-2016

Abstract


This PEP defines a schema for the Python registry key to allow third-party
installers to register their installation, and to allow tools and 
applications
to detect and correctly display all Python environments on a user's 
machine. No

implementation changes to Python are proposed with this PEP.

Python environments are not required to be registered unless they want to be
automatically discoverable by external tools. As this relates to Windows 
only,
these tools are expected to be predominantly GUI applications. However, 
console
applications may also make use of the registered information. This PEP 
covers
the information that may be made available, but the actual presentation 
and use

of this information is left to the tool designers.

The schema matches the registry values that have been used by the official
installer since at least Python 2.5, and the resolution behaviour 
matches the
behaviour of the official Python releases. Some backwards compatibility 
rules
are provided to ensure tools can correctly detect versions of CPython 
that do

not register full information.

Motivation
==

When installed on Windows, the official Python installer creates a 
registry key

for discovery and detection by other applications. This allows tools such as
installers or IDEs to automatically detect and display a user's Python
installations. For example, the PEP 397 ``py.exe`` launcher and editors 
such as

PyCharm and Visual Studio already make use of this information.

Third-party installers, such as those used by distributions, typically 
create
identical keys for the same purpose. Most tools that use the registry to 
detect
Python installations only inspect the keys used by the official 
installer. As a
result, third-party installations that wish to be discoverable will 
overwrite
these values, often causing users to "lose" their original Python 
installation.


By describing a layout for registry keys that allows third-party 
installations
to register themselves uniquely, as well as providing tool developers 
guidance
for discovering all available Python installations, these collisions 
should be
prevented. We also take the opportunity to add some well-known metadata 
so that

more information can be presented to users.

Definitions
===

A "registry key" is the equivalent of a file-system path into the 
registry. Each

key may contain "subkeys" (keys nested within keys) and "values" (named and
typed attributes attached to a key). These are used on Windows to store 
settings
in much the same way that directories containing configuration files 
would work.


``HKEY_CURRENT_USER`` is the root of settings for the currently 
logged-in user,

and this user can generally read and write all settings under this root.

``HKEY_LOCAL_MACHINE`` is the root of settings for all users. Generally, any
user can read these settings but only administrators can modify them. It is
typical for values under ``HKEY_CURRENT_USER`` to take precedence over 
those in

``HKEY_LOCAL_MACHINE``.

On 64-bit Windows, ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` is a 
special key
that 32-bit processes transparently read and write to rather than 
accessing the

``Software`` key directly.

Further documentation regarding registry redirection on Windows is available
from the MSDN Library [1]_.

Structure
=

We consider there to be a single collection of Python environments on a 
machine,
where the collection may be different for each user of the machine. 
There are
three potential registry locations where the collection may be stored 
based on

the installation options of each environment::

HKEY_CURRENT_USER\Software\Python\\
HKEY_LOCAL_MACHINE\Software\Python\\
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\\

Official Python releases use ``PythonCore`` for Company, and the value of
``sys.winver`` for Tag. The Company ``PyLauncher`` is reserved. Other 
registered
environments may use any values for Company and Tag. Recommendations are 
made

later in this document.

Company-Tag pairs are case-insensitive, and uniquely identify each 
environment.

Depending on the purpose 

Re: [Python-Dev] Convert from unsigned long long to PyLong

[MRAB]

On 2016-07-23 05:23, Tian JiaLin wrote:

Hey Guys,

I found the mistake I made, basically I'm using a tool called Sentry to
capture the exceptions.
The value returned from the Python is 2^64-1, which is -1
from mysql_affected_rows.
Sentry is using JSON format as the a kind of storage, apparently the MAX
SAFE INTEGER

 is
2^53 -1.


[snip]
JSON itself doesn't put a limit on the size of integers.

That link is about how JavaScript handles JSON.

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Brett Cannon]

On Sat, 23 Jul 2016 at 05:27 Ronald Oussoren  wrote:

> [SNIP]
>


> What is the best way forward after that? As before this is a change in
> behavior that, unsurprisingly, few core devs appear to be comfortable with
> evaluating, combined with new functionality that will likely see little use
> beyond PyObjC (although my opinions of that shouldn’t carry much weight, I
> thought that decorators would have limited appeal when those where
> introduced and couldn’t have been more wrong about that).
>
> Ronald
>
> P.S. The PEP itself: 

If the PEP is ready to be reviewed after that then either getting Guido to
pronounce or for him to assign a BDFL delegate.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] The devguide is now hosted on GitHub

[Brett Cannon]

On Fri, 22 Jul 2016 at 22:11 Benjamin Peterson  wrote:

> Should we just make the RTD one canonical and serve redirects on
> docs.python.org?
>

My hope was to eventually have dev.python.org point at the RTFD instance,
but I'm not up for spearheading that ATM and I would want the PSF to pay
for a gold membership for the account (currently it's just my personal free
account).

-Brett


>
> On Fri, Jul 22, 2016, at 13:04, Brett Cannon wrote:
> > https://github.com/python/devguide
> >
> > I have also moved all issues over as well and hooked up Read The Docs so
> > that there's a mirror which is always up-to-date (vs.
> > docs.python.org/devguide which is on a cronjob).
> > ___
> > Python-Dev mailing list
> > Python-Dev@python.org
> > https://mail.python.org/mailman/listinfo/python-dev
> > Unsubscribe:
> > https://mail.python.org/mailman/options/python-dev/benjamin%40python.org
>
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Martin Panter]

FYI there is also a bug tracker report about this:
https://bugs.python.org/issue27587

On 23 July 2016 at 13:22, Christian Heimes  wrote:
> On 2016-07-22 16:36, Guido van Rossum wrote:
>> Somebody did some research and found some bugs in CPython (IIUC). The
>> published some questionable fragments. If there's a volunteer we could
>> probably easily fix these. (I know we already have occasional Coverity
>> scans and there are other tools too (anybody try lgtm yet?) But this
>> seems honest research (also Python leaves Ruby in the dust :-):
>>
>> http://www.viva64.com/en/b/0414/
>
> I had a closer look at the report. About half of the bugs, maybe more
> are not in the C code of CPython but in OpenSSL code. I really mean
> OpenSSL code, not _ssl.c and _hashopenssl.c. It's safe to assume that
> they forgot to exclude external dependencies.
>
> The issues in ASN1_PRINTABLE_type() [N2], BN_mask_bits() [N4 bn_lib.c,
> digest.c, evp_enc.c], dh_cms_set_peerkey() [N5, dh_ameth.c] and
> cms_env_set_version() [N6, cms_env.c] are all OpenSSL issues and should
> be reported to OpenSSL.
>
> Guido, did the company contact you or do you have Pavel Belikov's email
> address?

Perhaps you can contact him via the email address at
.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Should we fix these errors?

[Christian Heimes]

On 2016-07-22 16:36, Guido van Rossum wrote:
> Somebody did some research and found some bugs in CPython (IIUC). The
> published some questionable fragments. If there's a volunteer we could
> probably easily fix these. (I know we already have occasional Coverity
> scans and there are other tools too (anybody try lgtm yet?) But this
> seems honest research (also Python leaves Ruby in the dust :-):
> 
> http://www.viva64.com/en/b/0414/

I had a closer look at the report. About half of the bugs, maybe more
are not in the C code of CPython but in OpenSSL code. I really mean
OpenSSL code, not _ssl.c and _hashopenssl.c. It's safe to assume that
they forgot to exclude external dependencies.

The issues in ASN1_PRINTABLE_type() [N2], BN_mask_bits() [N4 bn_lib.c,
digest.c, evp_enc.c], dh_cms_set_peerkey() [N5, dh_ameth.c] and
cms_env_set_version() [N6, cms_env.c] are all OpenSSL issues and should
be reported to OpenSSL.

Guido, did the company contact you or do you have Pavel Belikov's email
address?

Christian

___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

[Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

[Ronald Oussoren]

Hi,

It’s getting a tradition for me to work on PEP 447 during the EuroPython 
sprints and disappear afterwards. Hopefully I can manage to avoid the latter 
step this year…

Last year the conclusion appeared to be that this is an acceptable PEP, but 
Mark Shannon had a concern about a default implementation for __getdescriptor__ 
on type in  
(follow the link for more context):
 
> "__getdescriptor__" is fundamentally different from "__getattribute__" in that
> is defined in terms of itself.
> 
> object.__getattribute__ is defined in terms of type.__getattribute__, but
> type.__getattribute__ just does 
> dictionary lookups. However defining type.__getattribute__ in terms of
> __descriptor__ causes a circularity as
> __descriptor__ has to be looked up on a type.
> 
> So, not only must the cycle be broken by special casing "type", but that
> "__getdescriptor__" can be defined
> not only by a subclass, but also a metaclass that uses "__getdescriptor__" to
> define  "__getdescriptor__" on the class.
> (and so on for meta-meta classes, etc.)
My reaction that year is in 
. As I 
wrote there I did not fully understand the concerns Mark has, probably because 
I’m focussed too much on the implementation in CPython.  If removing 
type.__getdescriptor__ and leaving this special method as an optional hook for 
subclasses of type fixes the conceptual concerns then that’s fine by me. I used 
type.__getdescriptor__ as the default implementation both because it appears to 
be cleaner to me and because this gives subclasses an easy way to access the 
default implementation.

The implementation of the PEP in issue 18181 
 does special-case type.__getdescriptor__ 
but only as an optimisation, the code would work just as well without that 
special casing because the normal attribute lookup machinery is not used when 
accessing special methods written in C. That is, the implementation of 
object.__getattribute__ directly accesses fields of the type struct at the C 
level.  Some magic behavior appears to be necessary even without the addition 
of __getdescriptor__ (type is a subclass of itself, object.__getattribute__ has 
direct access to dict.__getitem__, …).

I’m currently working on getting the patch in 18181 up-to-date w.r.t. the 
current trunk, the patch in the issue no longer applies cleanly. After that 
I’ll try to think up some tests that seriously try to break the new behaviour, 
and I want to update a patch I have for PyObjC to make use of the new 
functionality to make sure that the PEP actually fixes the issues I had w.r.t. 
builtin.super’s behavior.

What is the best way forward after that? As before this is a change in behavior 
that, unsurprisingly, few core devs appear to be comfortable with evaluating, 
combined with new functionality that will likely see little use beyond PyObjC 
(although my opinions of that shouldn’t carry much weight, I thought that 
decorators would have limited appeal when those where introduced and couldn’t 
have been more wrong about that).

Ronald

P.S. The PEP itself: ___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com