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

On 13 September 2016 at 10:28, Brett Cannon wrote: > >> I'd like to add one more documented constraint - that dict literals >> maintain definition order (so long as the dict is not further modified). >> This allows defining a dict literal and then passing it as **kwargs. >> > >

Re: [Python-Dev] Python 3.6 what's new

On Sep 12, 2016, at 19:57, Benjamin Peterson wrote: > Thank you. Ditto! Many thanks, Yury! -- Ned Deily n...@python.org -- [] ___ Python-Dev mailing list Python-Dev@python.org

[Python-Dev] 3.6.0 Beta Phase Development

Wow! What a busy and productive couple of weeks it has been leading up to 3.6.0b1 and feature code freeze! Congratulations and thanks to all of you who've contributed to the amazing number of PEPs, features, bug fixes, and doc changes that have gone into 3.6.0b1! Now that feature development

Re: [Python-Dev] Python 3.6 what's new

Thank you. On Mon, Sep 12, 2016, at 16:21, Yury Selivanov wrote: > Hi, > > Elvis and I authored What's New in Python 3.5. We'd like to volunteer > to do the same for 3.6. If there are no objections, we can make the > first editing pass in a couple of weeks. > > Yury >

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

On 10 September 2016 at 03:17, Guido van Rossum wrote: > I've been asked about this. Here's my opinion on the letter of the law in > 3.6: > > - keyword args are ordered > - the namespace passed to a metaclass is ordered by definition order > - ditto for the class __dict__ > > A

Re: [Python-Dev] Python 3.6 what's new

No objection! On Mon, Sep 12, 2016 at 4:21 PM, Yury Selivanov wrote: > Hi, > > Elvis and I authored What's New in Python 3.5. We'd like to volunteer to do > the same for 3.6. If there are no objections, we can make the first editing > pass in a couple of weeks. > >

[Python-Dev] [RELEASE] Python 3.6.0b1 is now available

On behalf of the Python development community and the Python 3.6 release team, I'm happy to announce the availability of Python 3.6.0b1. 3.6.0b1 is the first of four planned beta releases of Python 3.6, the next major release of Python, and marks the end of the feature development phase for 3.6.

[Python-Dev] Python 3.6 what's new

Hi, Elvis and I authored What's New in Python 3.5. We'd like to volunteer to do the same for 3.6. If there are no objections, we can make the first editing pass in a couple of weeks. Yury ___ Python-Dev mailing list Python-Dev@python.org

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

On Mon, Sep 12, 2016 at 4:46 PM, Ethan Furman wrote: > Does anyone have a short explanation of the interaction between hash > randomization and this new always ordered dict? Why doesn't one make the > other useless? Before 3.6, dict iteration was based on the hash table,

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

On Mon, Sep 12, 2016 at 3:57 PM Brett Cannon wrote: > On Mon, 12 Sep 2016 at 15:46 Ethan Furman wrote: > > On 09/12/2016 09:27 AM, Gregory P. Smith wrote: > > > For the regular dict (non kwargs or namespace __dict__) use case I would > actually like to /see

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

On Mon, 12 Sep 2016 at 15:46 Ethan Furman wrote: > On 09/12/2016 09:27 AM, Gregory P. Smith wrote: > > > For the regular dict (non kwargs or namespace __dict__) use case I would > actually like to /see disorder preserved during iteration/. > > > > If we don't, we will

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

On 09/12/2016 09:27 AM, Gregory P. Smith wrote: For the regular dict (non kwargs or namespace __dict__) use case I would actually like to /see disorder preserved during iteration/. If we don't, we will eventually to find ourselves in a similar state we were in pre hash-randomization: Does

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

On Mon, Sep 12, 2016 at 9:51 AM Chris Angelico wrote: > On Tue, Sep 13, 2016 at 2:27 AM, Gregory P. Smith wrote: > > Disorder for this purpose need not be a random shuffle (overkill). It > just > > needs to be regularly inconsistent. A simple thing to do on

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

On Mon, Sep 12, 2016 at 10:25 AM INADA Naoki wrote: > > So fundamental question is: Is it to so bad thing that some people > write code depending on CPython and PyPy implementation? > Yes. See below. I think cross-interpreter libraries can use OrederedDict correctly >

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

> From what I understood, Python 3.6 dict got two *different* changes: > > * modify the dict structure to use two tables instead of only one: an > "index" table (the hash table) and a second key/value table > * tune the dict implementation to only append to the key/value table > > The second

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

[Guido] > Wouldn't attempting to reuse DUMMY entries be expensive? You'd have to > search forward in the array. Just keeping a count of DUMMY entries and > compacting when there are too many seems better somehow. I haven't looked at the code, but presumably one of the members of a DUMMY key/value

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

On Tue, Sep 13, 2016 at 1:35 AM, Guido van Rossum wrote: > Couldn't we use the order in the actual hash table (which IIUC now > contains just indexes into the ordered vector of key/value/hash > structs)? That would probably simulate the pre-3.6 order quite > effectively. Maybe,

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

2016-09-12 18:35 GMT+02:00 Guido van Rossum : > Couldn't we use the order in the actual hash table (which IIUC now > contains just indexes into the ordered vector of key/value/hash > structs)? That would probably simulate the pre-3.6 order quite > effectively. >From what I

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

Some of the functions we have are really intended to be used *only* by the interpreter itself. For those it would be cool to have them in private headers (AFAIK we already do this, see dict-common.h for instance). Other than that, I think that using the underscore convention is fine. Yury

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

On Tue, Sep 13, 2016 at 2:27 AM, Gregory P. Smith wrote: > Disorder for this purpose need not be a random shuffle (overkill). It just > needs to be regularly inconsistent. A simple thing to do on top of 3.6's new > dict implementation would be to pick a random starting point

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

Couldn't we use the order in the actual hash table (which IIUC now contains just indexes into the ordered vector of key/value/hash structs)? That would probably simulate the pre-3.6 order quite effectively. But we'd have to add a new API to reveal the order (in effect just what Nick wanted). How

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

For the regular dict (non kwargs or namespace __dict__) use case I would actually like to *see disorder preserved during iteration*. If we don't, we will eventually to find ourselves in a similar state we were in pre hash-randomization: (1) Over time, code will come to depend on the order for no

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

2016-09-12 13:50 GMT+02:00 Antoine Pitrou : > Besides, I don't think it has been proven that the compact-and-ordered > dict implementation is actually *faster* than the legacy one. Python 3.6 dict is slower than Python 3.5 dict, at least for a simple lookup:

Re: [Python-Dev] Let's make the SSL module sane

On Sat, 10 Sep 2016 20:23:13 +0200 Christian Heimes wrote: > > It's a bit too clever and tricky for my taste. I prefer 'explicit is > better than implicit' for trust anchors. My main concern are secure > default settings. A SSLContext should be secure w/o further settings

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

On Sun, 11 Sep 2016 04:37:58 -0400 Victor Stinner wrote: > > For Python 3.7, I propose that we move all these private functions in > separated header files, maybe Include/private/ or Include/core/, and > not export them as part of the "regular API". -1 from me. There

Re: [Python-Dev] Let's make the SSL module sane

On Sat, 10 Sep 2016 16:22:57 +0200 Christian Heimes wrote: > > For 3.6 I like to make the SSL more sane and more secure by default. > Yes, I'm a bit late but all my proposals are implemented, documented, > partly tested and existing tests are passing. I don't have time

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

On Fri, 9 Sep 2016 14:01:08 -0500 David Mertz wrote: > It seems unlikely, but not inconceivable, that someday in the future > someone will implement a dictionary that is faster than current versions > but at the cost of losing inherent ordering. I agree with this. Since

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

On 2016-09-12 12:29, Ivan Levkivskyi wrote: > On 12 September 2016 at 12:24, Christian Heimes > wrote: > > The code looks suspicious. Can you please > provide a patch that makes it more obvious, e.g. either by using if / > else if /

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

On 12 September 2016 at 12:24, Christian Heimes wrote: > The code looks suspicious. Can you please > provide a patch that makes it more obvious, e.g. either by using if / > else if / else or a comment? Sure, I will open an issue with a patch and will add you to nosy

Re: [Python-Dev] [Python-checkins] cpython: Use HTTP in testPythonOrg

I just noticed a failure on a recent Windows build: http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11620/steps/test/logs/stdio "urllib.error.URLError: " So I guess that the change is to restrict the unit test on parsing the robot failed and not test the SSL module. Am I

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

On 2016-09-12 11:46, Ivan Levkivskyi wrote: > Christian, > > When I wrote this, my intention was like: cur & DEF_LOCAL is a "more > serious" error, so that if both errors are made in the same statement: > def f(): > x: int = 5 > global x > > "SyntaxError: global after assignment" will be

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

Christian, When I wrote this, my intention was like: cur & DEF_LOCAL is a "more serious" error, so that if both errors are made in the same statement: def f(): x: int = 5 global x "SyntaxError: global after assignment" will be reported. The same logic applies to nonlocal. -- Ivan On

Re: [Python-Dev] cpython: Issue #27999: Make "global after use" a SyntaxError, and ditto for nonlocal.

On 2016-09-09 18:53, guido.van.rossum wrote: > https://hg.python.org/cpython/rev/804b71d43c85 > changeset: 103415:804b71d43c85 > user:Guido van Rossum > date:Fri Sep 09 09:36:26 2016 -0700 > summary: > Issue #27999: Make "global after use" a SyntaxError, and

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

On 12.09.16 11:41, Victor Stinner wrote: 2016-09-12 8:23 GMT+02:00 Benjamin Peterson : That seems like a good idea in abstract. However, the boundaries will have to be delineated. Many functions beginning _Py are effectively part of the public API even for "well-behaved"

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

2016-09-12 8:23 GMT+02:00 Benjamin Peterson : > That seems like a good idea in abstract. However, the boundaries will > have to be delineated. Many functions beginning _Py are effectively part > of the public API even for "well-behaved" 3rd-party extensions Oh ok, that's also

Re: [Python-Dev] Python 3.7: remove all private C functions from the Python C API?

That seems like a good idea in abstract. However, the boundaries will have to be delineated. Many functions beginning _Py are effectively part of the public API even for "well-behaved" 3rd-party extensions because they are used by magic macros. For example, _Py_Dealloc is used by Py_DECREF.