Mailman 3 March 2016 - Python-Dev

New OpenSSL - has anyone ever looked at (in)compatibility with LibreSSL
by Michael Felt March 15, 2016

March 15, 2016

As a relative newcomer I may have missed a long previous discussion re: linking with OpenSSL and/or LibreSSL. In an ideal world this would be rtl linking, i.e., underlying complexities of *SSL libraries are hidden from applications. In short, when I saw this http://bugs.python.org/issue26465 Title: Upgrade OpenSSL shipped with python installers, it reminded me I need to start looking at LibreSSL again - and that, if not already done - might be something "secure" for python as well. Michael

7 7

Python environment registration in the Windows Registry
by Steve Dower March 13, 2016

March 13, 2016

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 registry entries. (I knew about this, of course, but this time I decided to do something.) Apart from not being detected properly by all IDEs/tools/installers, non-standard distros that register themselves in the official keys may also mess with the default … [View More]sys.path values. For example, at one point (possibly still true) if you installed both Canopy and Anaconda, you would break the first one because they tried to load the other's stdlib. Other implementations have different structures or do not register themselves at all, which also makes it more complicated for tools to discover them. So here is a rough proposal to standardise the registry keys that can be set on Windows in a way that (a) lets other installers besides the official ones have equal footing, (b) provides consistent search and resolution semantics for tools, and (c) includes slightly more rich metadata (such as display names and URLs). Presented in PEP-like form here, but if feedback suggests just putting it in the docs I'm okay with that too. It is fully backwards compatible with official releases of Python (at least back to 2.5, possibly further) and does not require modifications to Python or the official installer - it is purely codifying a superset of what we already do. Any and all feedback welcomed, especially from the owners of other distros, Python implementations or tools on the list. Cheers, Steve ----- PEP: ??? Title: Python environment registration in the Windows Registry Version: $Revision$ Last-Modified: $Date$ Author: Steve Dower <steve.dower(a)python.org> Status: Draft Type: ??? Content-Type: text/x-rst Created: 02-Feb-2016 Abstract ======== When installed on Windows, the official Python installer creates a registry key for discovery and detection by other applications. Unofficial installers, such as those used by distributions, typically create identical keys for the same purpose. However, these may conflict with the official installer or other distributions. This PEP defines a schema for the Python registry key to allow unofficial installers to separately register their installation, and to allow applications to detect and correctly display all Python environments on a user's machine. No implementation changes to Python are proposed with this PEP. 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. Specification ============= 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. These are:: HKEY_CURRENT_USER\Software\Python\<Company>\<Tag> HKEY_LOCAL_MACHINE\Software\Python\<Company>\<Tag> HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\<Company>\<Tag> On a given machine, an environment is uniquely identified by its Company-Tag pair. Keys should be searched in the order shown, and if the same Company-Tag pair appears in more than one of the above locations, only the first occurrence is offerred. Official Python releases use ``PythonCore`` for Company, and the value of ``sys.winver`` for Tag. Other registered environments may use any values for Company and Tag. Recommendations are made in the following sections. Backwards Compatibility ----------------------- Python 3.4 and earlier did not distinguish between 32-bit and 64-bit builds in ``sys.winver``. As a result, it is possible to have valid side-by-side installations of both 32-bit and 64-bit interpreters. To ensure backwards compatibility, applications should treat environments listed under the following two registry keys as distinct, even if Tag matches:: HKEY_LOCAL_MACHINE\Software\Python\PythonCore\<Tag> HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\<Tag> Note that this does not apply to Python 3.5 and later, which uses different Tags. Environments registered under other Company names must use distinct Tags for side-by-side installations. 1. Environments in ``HKEY_CURRENT_USER`` are always preferred 2. Environments in ``HKEY_LOCAL_MACHINE\Software\Wow6432Node`` are preferred if the interpreter is known to be 32-bit Company ------- The Company part of the key is intended to group related environments and to ensure that Tags are namespaced appropriately. The key name should be alphanumeric without spaces and likely to be unique. For example, a trademarked name, a UUID, or a hostname would be appropriate:: HKEY_CURRENT_USER\Software\Python\ExampleCorp HKEY_CURRENT_USER\Software\Python\6C465E66-5A8C-4942-9E6A-D29159480C60 HKEY_CURRENT_USER\Software\Python\www.example.com If a string value named ``DisplayName`` exists, it should be used to identify the environment category to users. Otherwise, the name of the key should be used. If a string value named ``SupportUrl`` exists, it may be displayed or otherwise used to direct users to a web site related to the environment. A complete example may look like:: HKEY_CURRENT_USER\Software\Python\ExampleCorp (Default) = (value not set) DisplayName = "Example Corp" SupportUrl = "http://www.example.com" Tag --- The Tag part of the key is intended to uniquely identify an environment within those provided by a single company. The key name should be alphanumeric without spaces and stable across installations. For example, the Python language version, a UUID or a partial/complete hash would be appropriate; an integer counter that increases for each new environment may not:: HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6 HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66 If a string value named ``DisplayName`` exists, it should be used to identify the environment to users. Otherwise, the name of the key should be used. If a string value named ``SupportUrl`` exists, it may be displayed or otherwise used to direct users to a web site related to the environment. If a string value named ``Version`` exists, it should be used to identify the version of the environment. This is independent from the version of Python implemented by the environment. If a string value named ``SysVersion`` exists, it must be in ``x.y`` or ``x.y.z`` format matching the version returned by ``sys.version_info`` in the interpreter. Otherwise, if the Tag matches this format it is used. If not, the Python version is unknown. Note that each of these values is recommended, but optional. A complete example may look like this:: HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66 (Default) = (value not set) DisplayName = "Distro 3" SupportUrl = "http://www.example.com/distro-3" Version = "3.0.12345.0" SysVersion = "3.6.0" InstallPath ----------- Beneath the environment key, an ``InstallPath`` key must be created. This key is always named ``InstallPath``, and the default value must match ``sys.prefix``:: HKEY_CURRENT_USER\Software\Python\ExampleCorp\3.6\InstallPath (Default) = "C:\ExampleCorpPy36" If a string value named ``ExecutablePath`` exists, it must be a path to the ``python.exe`` (or equivalent) executable. Otherwise, the interpreter executable is assumed to be called ``python.exe`` and exist in the directory referenced by the default value. If a string value named ``WindowedExecutablePath`` exists, it must be a path to the ``pythonw.exe`` (or equivalent) executable. Otherwise, the windowed interpreter executable is assumed to be called ``pythonw.exe`` and exist in the directory referenced by the default value. A complete example may look like:: HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\InstallPath (Default) = "C:\ExampleDistro30" ExecutablePath = "C:\ExampleDistro30\ex_python.exe" WindowedExecutablePath = "C:\ExampleDistro30\ex_pythonw.exe" Help ---- Beneath the environment key, a ``Help`` key may be created. This key is always named ``Help`` if present and has no default value. Each subkey of ``Help`` specifies a documentation file, tool, or URL associated with the environment. The subkey may have any name, and the default value is a string appropriate for passing to ``os.startfile`` or equivalent. If a string value named ``DisplayName`` exists, it should be used to identify the help file to users. Otherwise, the key name should be used. A complete example may look like:: HKEY_CURRENT_USER\Software\Python\ExampleCorp\6C465E66\Help Python\ (Default) = "C:\ExampleDistro30\python36.chm" DisplayName = "Python Documentation" Extras\ (Default) = "http://www.example.com/tutorial" DisplayName = "Example Distro Online Tutorial" [View Less]

13 31

Re: [Python-Dev] [Webmaster] Python installation problem
by Steve Holden March 12, 2016

March 12, 2016

Hi Sumit, We get a lot of these inquiries. Yes, you can generally assume that Python will be available for the current versions of Linux, Windows and MacOS because the developers generally use those platforms for development work. It is certainly fine on Windows 10, so you should have no problems. You might find https://www.londonappdeveloper.com/setting-up-your-windows-10-system-for-py… helpful in setting up your environment. I have forwarded this query to the developers list, as I noticed … [View More]

1 0

Use utf-8 charset for tracker summaries?
by Terry Reedy March 12, 2016

March 12, 2016

The weeky 'Summariy of Python tracker Issues' ('tracker' should be capitalized if 'Issues' is) starts with Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Names sometimes have not-ascii chars, and they do not get properly displayed for me with Thunderbird on Windows. For instance, Raúl Núñez de Arenas (Raúl Núñez de Arenas) is transmitted as Ra=C3=BAl N=C3=BA=C3=B1ez de= Arenas and displayed as RaÃºl NÃºÃ±ez de Arenas I am rather sure that … [View More]

2 2

Bug in build system for cross-platform builds
by Russell Keith-Magee March 12, 2016

March 12, 2016

Hi all, I’ve been working on developing Python builds for mobile platforms, and I’m looking for some help resolving a bug in Python’s build system. The problem affects cross-platform builds - builds where you are compiling python for a CPU architecture other than the one on the machine that is doing the compilation. This requirement stems from supporting mobile platforms (iOS, Android etc) where you compile on your laptop, then ship the compiled binary to the device. In the Python 3.5 dev … [View More]

2 5

Re: [Python-Dev] Request for Pronouncement: PEP 441 - Improving Python ZIP Application Support
by anais timaure March 11, 2016

March 11, 2016

Por favor quiero descargar este programa para mi teléfono Windows 8 Anais'Timaure♡

1 0

Summary of Python tracker Issues
by Python tracker March 11, 2016

March 11, 2016

ACTIVITY SUMMARY (2016-03-04 - 2016-03-11) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5454 (+19) closed 32842 (+40) total 38296 (+59) Open issues with patches: 2373 Issues opened (39) ================== #16851: Hint about correct ismethod and isfunction usage http://bugs.python.org/issue16851 reopened by haypo #26481: unittest discovery … [View More]

1 0

Summary of Python tracker Issues
by Python tracker March 11, 2016

March 11, 2016

ACTIVITY SUMMARY (2016-02-26 - 2016-03-04) Python tracker at http://bugs.python.org/ To view or respond to any of the issues listed below, click on the issue. Do NOT respond to this message. Issues counts and deltas: open 5435 ( -2) closed 32802 (+38) total 38237 (+36) Open issues with patches: 2370 Issues opened (26) ================== #19450: Bug in sqlite in Windows binaries http://bugs.python.org/issue19450 reopened by schlamar #25910: Fixing links in documentation http://… [View More]

2 1

Connecting
by Irina Papuc March 10, 2016

March 10, 2016

Hi Python, My name is Irene Papuc, and I work for a technical publication known as the Toptal Engineering blog. Our blog covers a variety of topics, across many programming languages and dev/design. I have noticed we share similar areas of focus in our topics including python, which I found here. We’ve recently published an article called "Python Multithreading Tutorial: Concurrency and Parallelism", which has a similar focus on python. Would you be interested in sharing this with your … [View More]

1 0

Web redirect to PyAr
by Facundo Batista March 7, 2016

March 7, 2016

Hello! Sending mail here because I really don't know where this is handled :) At some point in the past we had a redirect from python.org/ar (note the slash, not a point) to a PyAr site. Now it's not working, it 404s. It should be redirected to python.org.ar (note the point). Thanks! -- . Facundo Blog: http://www.taniquetil.com.ar/plog/ PyAr: http://www.python.org/ar/ Twitter: @facundobatista

3 3