Re: [Python-Dev] PEP 514: Python registration in the Windows registry
On 15 July 2016 at 23:39, Steve Dower wrote: > 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. :-) Thanks for the vote of confidence, Steve - if Guido's OK with it I'd be willing to do this. Paul ___ 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
Good catch, thanks. Top-posted from my Windows Phone -Original Message- From: "Nick Coghlan" Sent: 7/15/2016 23:53 To: "Steve Dower" Cc: "Python Dev" Subject: 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
Re: [Python-Dev] PEP 514: Python registration in the Windows registry
Yup! Paul is now officially the BDFL-delegate for PEP 514. On Sat, Jul 16, 2016 at 2:44 AM, Paul Moore wrote: > On 15 July 2016 at 23:39, Steve Dower wrote: >> 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. > > :-) Thanks for the vote of confidence, Steve - if Guido's OK with it > I'd be willing to do this. > > Paul -- --Guido van Rossum (python.org/~guido) ___ 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] Status of Python 3.6 PEPs?
On Tue, Jul 12, 2016 at 4:26 AM, Victor Stinner wrote: > > "PEP 495 -- Local Time Disambiguation" > https://www.python.org/dev/peps/pep-0495/ > => accepted > > Alexander Belopolsky asked for a review of the implementation: > https://mail.python.org/pipermail/python-dev/2016-June/145450.html Victor, I know your plate is full, but you are best qualified to review the C implementation. Tim reviewed the Python implementation early on and made several valuable suggestions, but he refuses to deal with C these days. :-( I tried to set up a Windows VM capable of building CPython, but gave up after a few futile attempts. It would be great if you could help me with the Windows port. I posted the latest patch at the Bug Tracker: http://bugs.python.org/issue24773 ___ 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
On 15 July 2016 at 23:20, Steve Dower wrote: > Hi all > > I'd like to get this PEP approved (status changed to Active, IIUC). Some comments below. > 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). Certainly there's nothing that impacts existing releases. I've noted an issue around sys.winver below, that as an absolute minimum needs a clarification in the 3.6 docs (the documented behaviour of sys.winver isn't explicit enough to provide the uniqueness guarantees this PEP needs) and may in fact need a code change or a PEP change if sys.winver doesn't actually distinguish between 32-bit and 64-bit builds (I've not been able to confirm that either way, unfortunately). [...] > 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. The PEP seems quite strongly focused on GUI tools, where the normal mode of operation would be to present the user with a list of "available installations" (with extra data where possible, not just a bare list of names) and ask for a selection. I'd like to see console tools considered as well. Basically, I'd like to avoid tool developers reading this section and thinking "it only applies to GUI tools or OS integration, not to me". For example, virtualenv introspects the available Python installations - see https://github.com/pypa/virtualenv/blob/master/virtualenv.py#L86 - to support the "-p " flag. To handle this well, it would be useful to allow distributions to register a "short tag", so that as well as "-p 3.5" or "-p 2", Virtualenv could support (say) "-p conda3.4" or "-p pypy2". (The short tag should be at the Company level, so "conda" or "pypy", and the version gets added to that). Another place where this might be useful is the py.exe launcher (it's not in scope for this PEP, but having the data needed to allow the launcher to invoke any available installation could be useful for future enhancements). Another key motivation for me would be to define clearly what information tools can rely on being able to get from the available registry entries describing what's installed. Whenever I've needed to scan the registry, the things I've needed to find out are where I find the Python interpreter, what Python version it is, and whether it's 32-bit or 64-bit. The first so that I can run Python, and the latter two so that I can tell if this is a version I support *without* needing to run the interpreter. For me, everything else in this PEP is about UI, but those 3 items plus the "short tag" idea are more about what capabilities I can provide. [...] > 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. It might be worth being more explicit here that 32-bit and 64-bit processes see the registry keys slightly differently. More on this below. > 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. (As Nick pointed out, "it is not possible to have valid...". I'd also add "under the rules described above"). Also, Python 3.5 doesn't appear to include the architecture in sys.winver either. >py Python 3.5.1 (v3.5.1:37a07cee5969, Dec 6 2015, 01:54:25) [MSC v.1900 64 bit (AMD64)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import sys >>> sys.winver '3.5' (Unless it adds -32 for 32-bit, and reserves the bare version for 64-bit. I've skimmed the CPython source but can't confirm that). The documentation of sys.winver makes no mention of whether it distinguishes 32- and 64-bit builds. In fact, it states "The value is normally the first three characters of version". If we're relying on sys.winver being unique by version/architecture, the docs need to say so (so that future changes don't accidentally violate that). > To ensure backwards compatibility, applications should treat environments > listed under the following two registry keys as distinct, even when the Tag > matches:: > > HKEY_LOCAL_MACHINE\Software\Python\PythonCore\ > HKEY_LOCAL_MACHINE\Software\Wow6432Node\Python\PythonCore\ > > Environments listed under ``HKEY_CURRENT_USER`` may
Re: [Python-Dev] PEP 514: Python registration in the Windows registry
On 16 July 2016 at 18:59, Guido van Rossum wrote: > Yup! Paul is now officially the BDFL-delegate for PEP 514. OK. I've just been reviewing the PEP and have posted some comments. There's a lot of words(!), but I don't think there's a huge amount of substantive change, mostly it's just confirmation of intent. I'll let Steve ponder that, and if anyone else has any further comments to make, now's the time to speak up. Paul ___ 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 467: Minor API improvements to bytes, bytearray, and memoryview
On 06/07/2016 10:42 PM, Serhiy Storchaka wrote: On 07.06.16 23:28, Ethan Furman wrote: * Add ``bytes.iterbytes``, ``bytearray.iterbytes`` and ``memoryview.iterbytes`` alternative iterators "Byte" is an alias to "octet" (8-bit integer) in modern terminology. Maybe so, but not, to my knowledge, in Python terminology. Iterating bytes and bytearray already produce bytes. No, it produces integers: for b in b'abcid': ... print(b) ... 97 98 99 105 100 -- ~Ethan~ ___ 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
