Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 9 September 2016 at 15:34, Benjamin Peterson wrote: > On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote: > > On 9 September 2016 at 07:45, Chris Angelico wrote: > > > > > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner < > victor.stin...@gmail.com> > > >

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On 9 September 2016 at 07:45, Chris Angelico wrote: > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner > wrote: > > A nice "side effect" of compact dict is that the dictionary now > > preserves the insertion order. It means that keyword arguments can

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Thu, Sep 8, 2016, at 22:33, Tim Delaney wrote: > On 9 September 2016 at 07:45, Chris Angelico wrote: > > > On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner > > wrote: > > > A nice "side effect" of compact dict is that the dictionary now > > >

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

Thank you for all core devs! I'll polish the implementation until 3.6b2. On Fri, Sep 9, 2016 at 6:42 AM, Guido van Rossum wrote: > It's in! Congrats, and thanks for your great work! See longer post by Victor. > > On Sun, Aug 28, 2016 at 12:16 AM, INADA Naoki

[Python-Dev] IMPORTANT: 3.6.0b1 and feature code cutoff 2016-09-12 12:00 UTC

Happy end of summer (northern hemisphere) or winter (southern)! Along with the changing of the seasons, the time has come to finish feature development for Python 3.6. As previously announced, this coming Monday marks the end of the alpha phase of the release cycle and the beginning of the

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Fri, Sep 9, 2016 at 6:22 AM, Victor Stinner wrote: > A nice "side effect" of compact dict is that the dictionary now > preserves the insertion order. It means that keyword arguments can now > be iterated by their creation order: > This is pretty sweet! Of course,

Re: [Python-Dev] Review request: issue 27350, compact ordered dict

It's in! Congrats, and thanks for your great work! See longer post by Victor. On Sun, Aug 28, 2016 at 12:16 AM, INADA Naoki wrote: > On Sun, Aug 28, 2016 at 2:05 PM, Guido van Rossum wrote: >> Hopefully some core dev(s) can work on this during the core

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Thu, Sep 8, 2016 at 1:36 PM, Guido van Rossum wrote: > IIUC there's one small thing we might still want to change somewhere > after 3.6b1 but before 3.6rc1: the order is not preserved when you > delete some keys and then add some other keys. Apparently PyPy has > come up with

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

2016-09-08 13:36 GMT-07:00 Guido van Rossum : > IIUC there's one small thing we might still want to change somewhere > after 3.6b1 but before 3.6rc1: the order is not preserved when you > delete some keys and then add some other keys. Apparently PyPy has > come up with a clever

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 16:01, Chris Barker wrote: > Is there a "long" in there anywhere in the integer implementation? The python 2 long type is the python 3 int type. The python 2 int type is gone. > I don't have py3 running on win64 anywhere right now, but in win64 py2, > that would give you:

Re: [Python-Dev] (some) C99 added to PEP 7

Can you guys get a room? There is absolutely no reason that all of python-dev needs to hear this. On Thu, Sep 8, 2016 at 1:35 PM, Steve Dower wrote: > On 08Sep2016 1301, Chris Barker wrote: >> >> On Thu, Sep 8, 2016 at 9:39 AM, Random832 >

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

Thanks Victor for the review and commit, and thanks Naoki for your truly amazing implementation work!! I've also accepted Eric's PEP 468. IIUC there's one small thing we might still want to change somewhere after 3.6b1 but before 3.6rc1: the order is not preserved when you delete some keys and

Re: [Python-Dev] (some) C99 added to PEP 7

On 08Sep2016 1301, Chris Barker wrote: On Thu, Sep 8, 2016 at 9:39 AM, Random832 > wrote: You're talking about changing Py_ssize_t, right? wouldn't that be the pointer size? Is there a "long" in there anywhere in the integer

Re: [Python-Dev] PEP 468 ready for pronouncement.

Thanks Eric! The synergy between this PEP and the compact dict is amazing BTW. Clearly its time has come. Therefore: PEP 468 is now accepted. You may as well call it Final, since all we need to do now is update the docs. Congrats!! --Guido On Thu, Sep 8, 2016 at 1:20 PM, Eric Snow

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

Please no. Let's not add unrelated new functionality in with this already large change with not entirely understood consequences. On Thu, Sep 8, 2016 at 1:05 PM, Chris Barker wrote: > On Thu, Sep 8, 2016 at 10:35 AM, Random832 wrote: >> >> >> It

[Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

Hi, I pushed INADA Naoki's implementation of the "compact dict". The hash table now stores indices pointing to a new second table which contains keys and values: it adds one new level of indirection. The table of indices is "compact": use 1, 2, 4 or 8 bytes per indice depending on the size of the

[Python-Dev] PEP 468 ready for pronouncement.

see: https://github.com/python/peps/blob/master/pep-0468.txt With the introduction of the compact dict implementation for CPython 3.6, PEP 468 becomes no more than a change to the language reference. I've adjusted the PEP to specify use of an ordered mapping rather than exactly OrderedDict.

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, Sep 8, 2016 at 1:14 PM, Guido van Rossum wrote: > Please no. Let's not add unrelated new functionality in with this > already large change with not entirely understood consequences. > Fair enough -- this is clearly a really raw API so far. -CHB > > On Thu, Sep 8,

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, Sep 8, 2016 at 10:35 AM, Random832 wrote: > > It means that the so-called "bash" on windows 10 is actually a full > Ubuntu system (running on, AIUI, a simulation of Linux kernel system > calls), which will presumably also have its own python installation and > use

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016 at 9:39 AM, Random832 wrote: > You're talking about changing Py_ssize_t, right? > wouldn't that be the pointer size? Is there a "long" in there anywhere in the integer implementation? My example is this: on OS-X, py3.5: import numpy as np In [9]:

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, Sep 8, 2016, at 13:10, Guido van Rossum wrote: > On Thu, Sep 8, 2016 at 9:57 AM, Brett Cannon wrote: > > Bash on Windows is just Linux, so it isn't affected by any of this. > > I don't know what that sentence means. It means that the so-called "bash" on windows 10 is

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, Sep 8, 2016 at 9:57 AM, Brett Cannon wrote: > > > On Thu, 8 Sep 2016 at 09:06 Chris Barker wrote: >> >> On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum >> wrote: >>> >>> And apart from Python, few shell commands that work on

Re: [Python-Dev] (some) C99 added to PEP 7

On Fri, Sep 9, 2016 at 2:39 AM, Random832 wrote: > On Thu, Sep 8, 2016, at 12:30, Chris Barker wrote: >> That's why I said "based on" -- under the hood, a C type is used, and >> IIUC, that type has been "long" for ages. And a long on Windows 64 >> (with the MS compiler

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Thu, 8 Sep 2016 at 09:06 Chris Barker wrote: > On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum > wrote: > >> And apart from Python, few shell commands that work on >> Unix make much sense on Windows, > > > Does the (optional) addition of bash to

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 12:30, Chris Barker wrote: > That's why I said "based on" -- under the hood, a C type is used, and > IIUC, that type has been "long" for ages. And a long on Windows 64 > (with the MS compiler anyway) is 32 bit, and a long on *nix (with the > gnu compilers, at least) is 64

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016 at 9:17 AM, Benjamin Peterson wrote: > > Does this mean that we might be able to have the built-in integer be > > based > > on int64_t now? so Windows64 and *nix64 will be the same? > > The builtin integer type (in Python 3) is variable length. > indeed

Re: [Python-Dev] (some) C99 added to PEP 7

On Thu, Sep 8, 2016, at 09:09, Chris Barker wrote: > > > - Standard integer types in and > > > > > > Yes, I will clarify we require the fixed-width types. > > > Does this mean that we might be able to have the built-in integer be > based > on int64_t now? so Windows64 and *nix64

Re: [Python-Dev] (some) C99 added to PEP 7

> > - Standard integer types in and > > Yes, I will clarify we require the fixed-width types. Does this mean that we might be able to have the built-in integer be based on int64_t now? so Windows64 and *nix64 will be the same? - CHB -- Christopher Barker, Ph.D. Oceanographer

Re: [Python-Dev] PEP 529: Change Windows filesystem encoding to UTF-8

On Wed, Sep 7, 2016 at 10:37 AM, Guido van Rossum wrote: > And apart from Python, few shell commands that work on > Unix make much sense on Windows, Does the (optional) addition of bash to Windows 10 have any impact on this? It'll be something that Windows developers can't

Re: [Python-Dev] hg push segfault

On Thu, Sep 8, 2016, at 02:10, Christian Heimes wrote: > Hi, > > About 10 minutes ago I got a couple of remote segfaults from > hg.python.org. They occurred during push and pull operations: > > $ hg push > pushing to ssh://h...@hg.python.org/cpython > remote: bash: line 1: 25019 Segmentation

Re: [Python-Dev] cpython (3.5): supress coroutine warning when an exception is pending (#27968)

On Thu, Sep 8, 2016, at 04:09, Christian Heimes wrote: > On 2016-09-07 17:47, benjamin.peterson wrote: > > https://hg.python.org/cpython/rev/234f758449f8 > > changeset: 103223:234f758449f8 > > branch: 3.5 > > parent: 103213:7537ca1c2aaf > > user:Benjamin Peterson

Re: [Python-Dev] cpython (3.5): supress coroutine warning when an exception is pending (#27968)

On 2016-09-07 17:47, benjamin.peterson wrote: > https://hg.python.org/cpython/rev/234f758449f8 > changeset: 103223:234f758449f8 > branch: 3.5 > parent: 103213:7537ca1c2aaf > user:Benjamin Peterson > date:Wed Sep 07 08:46:59 2016 -0700 > summary: >

[Python-Dev] hg push segfault

Hi, About 10 minutes ago I got a couple of remote segfaults from hg.python.org. They occurred during push and pull operations: $ hg push pushing to ssh://h...@hg.python.org/cpython remote: bash: line 1: 25019 Segmentation fault HGPUSHER=christian.heimes /srv/hg/bin/hg-ssh /srv/hg/repos/* abort: