[Python-Dev] Summary of Python tracker Issues
ACTIVITY SUMMARY (2016-07-08 - 2016-07-15) 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: open5562 (+12) closed 33715 (+39) total 39277 (+51) Open issues with patches: 2429 Issues opened (33) == #27469: Unicode filename gets crippled on Windows when drag and drop http://bugs.python.org/issue27469 reopened by eryksun #27470: -3 commandline option documented differently via man http://bugs.python.org/issue27470 opened by mgilson #27471: sre_constants.error: bad escape \d http://bugs.python.org/issue27471 opened by Noah Petherbridge #27472: add the 'unix_shell' attribute to test.support http://bugs.python.org/issue27472 opened by xdegaye #27477: IDLE: Switch dialogs to ttk widgets. http://bugs.python.org/issue27477 opened by terry.reedy #27482: heap-buffer-overflow on address 0x625078ff http://bugs.python.org/issue27482 opened by mtowalski #27483: Expose HEAD_LOCK/HEAD_UNLOCK in pystate.c http://bugs.python.org/issue27483 opened by fijall #27485: urllib.splitport -- is it official or not? http://bugs.python.org/issue27485 opened by gvanrossum #27486: FTPlib hangs on some pasv responses http://bugs.python.org/issue27486 opened by Byoungwoo Song #27487: -m switch regression in Python 3.5.2 (under rare circumstances http://bugs.python.org/issue27487 opened by wolma #27490: ARM cross-compile: pgen built without $(CFLAGS) as $(LIBRARY) http://bugs.python.org/issue27490 opened by Thomas Perl #27491: Errors when building with UNICODE character set http://bugs.python.org/issue27491 opened by Minmin.Gong #27492: Enhance bytearray_repr with bytes_repr's logic http://bugs.python.org/issue27492 opened by xiang.zhang #27493: logging module fails with unclear error when supplied a (Posix http://bugs.python.org/issue27493 opened by rhendrikse #27494: 2to3 parser failure caused by a comma after a generator expres http://bugs.python.org/issue27494 opened by jstasiak #27495: Pretty printing sorting for set and frozenset instances http://bugs.python.org/issue27495 opened by danilo.bellini #27496: unicodedata.name() doesn't have names for control characters http://bugs.python.org/issue27496 opened by zwol #27497: csv module: Add return value to DictWriter.writeheader http://bugs.python.org/issue27497 opened by lsowen #27499: PY_SSIZE_T_CLEAN conflicts with Py_LIMITED_API http://bugs.python.org/issue27499 opened by dholth #27500: ProactorEventLoop cannot open connection to ::1 http://bugs.python.org/issue27500 opened by sebastien.bourdeauducq #27501: Add typing.py class describing a PEP 3118 buffer object http://bugs.python.org/issue27501 opened by Daniel Moisset #27502: Python -m Module Vulnerable to Buffer Over Flow. http://bugs.python.org/issue27502 opened by DhirajMishra #27505: Missing documentation for setting module __class__ attribute http://bugs.python.org/issue27505 opened by ncoghlan #27506: make bytes/bytearray delete a keyword argument http://bugs.python.org/issue27506 opened by xiang.zhang #27507: bytearray.extend lacks overflow check when increasing buffer http://bugs.python.org/issue27507 opened by xiang.zhang #27509: Some tests breaks PGO build on Windows http://bugs.python.org/issue27509 opened by Charles G. #27511: Add PathLike objects support to BZ2File http://bugs.python.org/issue27511 opened by xiang.zhang #27512: os.fspath is certain to crash when exception raised in __fspat http://bugs.python.org/issue27512 opened by xiang.zhang #27513: email.utils.getaddresses does not handle Header objects http://bugs.python.org/issue27513 opened by frispete #27515: Dotted name re-import does not rebind after deletion http://bugs.python.org/issue27515 opened by terry.reedy #27516: Wrong initialization of python path with embeddable distributi http://bugs.python.org/issue27516 opened by palm.kevin #27517: LZMACompressor and LZMADecompressor raise exceptions if given http://bugs.python.org/issue27517 opened by benfogle #27520: Issue when building PGO http://bugs.python.org/issue27520 opened by Decorater Most recent 15 issues with no replies (15) == #27520: Issue when building PGO http://bugs.python.org/issue27520 #27511: Add PathLike objects support to BZ2File http://bugs.python.org/issue27511 #27505: Missing documentation for setting module __class__ attribute http://bugs.python.org/issue27505 #27494: 2to3 parser failure caused by a comma after a generator expres http://bugs.python.org/issue27494 #27491: Errors when building with UNICODE character set http://bugs.python.org/issue27491 #27486: FTPlib hangs on some pasv responses http://bugs.python.org/issue27486 #27482: heap-buffer-overflow on address 0x625078ff http://bugs.python.org/issue27482 #27470: -3 commandline option documented differently via man http://bugs.python.org/issue27470
[Python-Dev] PEP 514: Python registration in the Windows registry
Hi all I'd like to get this PEP approved (status changed to Active, IIUC). So far (to my knowledge), Anaconda is writing out the new metadata and Visual Studio is reading it. Any changes to the schema now will require somewhat public review anyway, so I don't see any harm in approving the PEP right now. To reiterate, this doesn't require changing anything about CPython at all and has no backwards compatibility impact on official releases (but hopefully it will stop alternative distros from overwriting our essential metadata and causing problems). I suppose I look to Guido first, unless he wants to delegate to one of the other Windows contributors? Cheers, Steve URL: https://www.python.org/dev/peps/pep-0514/ Full text --- 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 Abstract This PEP defines a schema for the Python registry key to allow third-party installers to 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. Python environments are not required to be registered unless they want to be automatically discoverable by external tools. 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. 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. 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, resulting in users "losing" their 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. 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). ``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. 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\\ Environments are uniquely identified by their Company-Tag pair, with two options for conflict resolution: include everything, or give priority to user preferences. Tools that include every installed environment, even where the Company-Tag pairs match, should ensure users can easily identify whether the registration was per-user or per-machine. When tools are selecting a single installed environment from all registered environments, the intent is that user preferences from ``HKEY_CURRENT_USER`` will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``. 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. Python environments are not required to register themselves unless they want to be automatically discoverable by external tools. 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. T
Re: [Python-Dev] PEP 514: Python registration in the Windows registry
I was going to delegate to our resident Windows expert, but that's you. :-( Can you suggest someone else? I really don't want to swap in what I once knew about the Windows registry... On Fri, Jul 15, 2016 at 3:20 PM, Steve Dower wrote: > Hi all > > I'd like to get this PEP approved (status changed to Active, IIUC). > > So far (to my knowledge), Anaconda is writing out the new metadata and > Visual Studio is reading it. Any changes to the schema now will require > somewhat public review anyway, so I don't see any harm in approving the PEP > right now. > > To reiterate, this doesn't require changing anything about CPython at all > and has no backwards compatibility impact on official releases (but > hopefully it will stop alternative distros from overwriting our essential > metadata and causing problems). > > I suppose I look to Guido first, unless he wants to delegate to one of the > other Windows contributors? > > Cheers, > Steve > > URL: https://www.python.org/dev/peps/pep-0514/ > > Full text > --- > > 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 > > Abstract > > > This PEP defines a schema for the Python registry key to allow third-party > installers to 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. > > Python environments are not required to be registered unless they want to be > automatically discoverable by external tools. > > 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. > > 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. > > 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, resulting in users "losing" their 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. > > 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). > > ``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. > > 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\\ > > Environments are uniquely identified by their Company-Tag pair, with two > options > for conflict resolution: include everything, or give priority to user > preferences. > > Tools that include every installed environment, even where the Company-Tag > pairs > match, should ensure users can easily identify whether the registration was > per-user or per-machine. > > When tools are selecting a single installed environment from all registered > environments, the intent is that user preferences from ``HKEY_CURRENT_USER`` > will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``. > > 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. Re
Re: [Python-Dev] PEP 514: Python registration in the Windows registry
On 15Jul2016 1526, Guido van Rossum wrote: I was going to delegate to our resident Windows expert, but that's you. :-( Can you suggest someone else? I really don't want to swap in what I once knew about the Windows registry... He might not be pleased at the nomination, but Paul Moore would be my first choice. Otherwise Zach still has the obligation that comes with being labelled a Windows expert in the dev guide ;) On Fri, Jul 15, 2016 at 3:20 PM, Steve Dower wrote: Hi all I'd like to get this PEP approved (status changed to Active, IIUC). So far (to my knowledge), Anaconda is writing out the new metadata and Visual Studio is reading it. Any changes to the schema now will require somewhat public review anyway, so I don't see any harm in approving the PEP right now. To reiterate, this doesn't require changing anything about CPython at all and has no backwards compatibility impact on official releases (but hopefully it will stop alternative distros from overwriting our essential metadata and causing problems). I suppose I look to Guido first, unless he wants to delegate to one of the other Windows contributors? Cheers, Steve URL: https://www.python.org/dev/peps/pep-0514/ Full text --- 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 Abstract This PEP defines a schema for the Python registry key to allow third-party installers to 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. Python environments are not required to be registered unless they want to be automatically discoverable by external tools. 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. 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. 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, resulting in users "losing" their 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. 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). ``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. 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\\ Environments are uniquely identified by their Company-Tag pair, with two options for conflict resolution: include everything, or give priority to user preferences. Tools that include every installed environment, even where the Company-Tag pairs match, should ensure users can easily identify whether the registration was per-user or per-machine. When tools are selecting a single installed environment from all registered environments, the intent is that user preferences from ``HKEY_CURRENT_USER`` will override matching Company-Tag pairs in ``HKEY_LOCAL_MACHINE``. 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.
Re: [Python-Dev] PEP 514: Python registration in the Windows registry
On 16 July 2016 at 08:20, Steve Dower wrote: > 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. The second sentence here seems like it should say "... it is not possible ..." (since subsequent paragraphs explain that side-by-side installs of 32-bit and 64-bit versions don't really work properly until 3.5) Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia ___ 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
