Re: [Python-Dev] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On Sat, May 23, 2015 at 1:34 AM, Berker Peksağ wrote: > > On Sat, May 23, 2015 at 12:53 AM, Chris Barker wrote: > > On Fri, May 22, 2015 at 2:33 PM, Larry Hastings wrote: > >> > >> On 05/22/2015 02:29 PM, Chris Barker wrote: > >> > >> Is it too late to get the isclose() code (PEP 485) into 3.5? > > > > ... > >> > >> Hopefully you can find a core dev familiar enough with the issues > >> involved that they can (quickly!) guide it through the process of getting > >> it > >> checked in. > > > > Ping! Anyone willing to sponsor this? > > ... > > * The C implementation should be in Modules/mathmodule.c > * Tests should be in Lib/test/test_math.py > * Documentation should be in Doc/library/math.rst > * Add an entry to Doc/whatsnew/3.5.rst > * If I remember correctly, we don't need the Python implementation and its > tests I'll happily review the patch once it's on the bug tracker as Berker described. - Tal Einat ___ 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] [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
On 23 May 2015 at 19:29, Tal Einat wrote: > On Sat, May 23, 2015 at 1:34 AM, Berker Peksağ > wrote: >> >> On Sat, May 23, 2015 at 12:53 AM, Chris Barker wrote: >> > On Fri, May 22, 2015 at 2:33 PM, Larry Hastings wrote: >> >> >> >> On 05/22/2015 02:29 PM, Chris Barker wrote: >> >> >> >> Is it too late to get the isclose() code (PEP 485) into 3.5? >> > >> > ... >> >> >> >> Hopefully you can find a core dev familiar enough with the issues >> >> involved that they can (quickly!) guide it through the process of getting >> >> it >> >> checked in. >> > >> > Ping! Anyone willing to sponsor this? >> >> ... >> >> * The C implementation should be in Modules/mathmodule.c >> * Tests should be in Lib/test/test_math.py >> * Documentation should be in Doc/library/math.rst >> * Add an entry to Doc/whatsnew/3.5.rst >> * If I remember correctly, we don't need the Python implementation and its >> tests > > I'll happily review the patch once it's on the bug tracker as Berker > described. I filed http://bugs.python.org/issue24270 to track this, but there's a fair bit of work to be done to integrate the changes into the existing math module's code, tests and documentation. And correct, there's no need for a pure Python implementation - Guido rejected the idea of a pure Python fallback for the math module a while back (http://bugs.python.org/issue23595) Regards, 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 484 (Type Hints) announcement
Would you mind updating the "typing" package on PyPI now to contain something useful? Thanks. 22.05.2015, 23:51, Mark Shannon kirjoitti: Hello all, I am pleased to announce that I am accepting PEP 484 (Type Hints). Given the proximity of the beta release I thought I would get this announcement out now, even though there are some (very) minor details to iron out. (If you want to know the details, it's all at https://github.com/ambv/typehinting) I hope that PEP 484 will be a benefit to all users of Python. I think the proposed annotation semantics and accompanying module are technically sound and I hope that they are socially acceptable to the Python community. I have long been aware that as well as a powerful, sophisticated and "production quality" language, Python is also used by many casual programmers, and as a language to introduce children to programming. I also realise that this PEP does not look like it will be any help to the part-time programmer or beginner. However, I am convinced that it will enable significant improvements to IDEs (hopefully including IDLE), static checkers and other tools. These tools will then help us all, beginners included. This PEP has been a huge amount of work, involving a lot of people. So thank you to everyone involved. If I were to list names I would inevitably miss someone out. You know who you are. Finally, if you are worried that this will make Python ugly and turn it into some sort of inferior Java, then I share you concerns, but I would like to remind you of another potential ugliness; operator overloading. C++, Perl and Haskell have operator overloading and it gets abused something rotten to produce "concise" (a.k.a. line noise) code. Python also has operator overloading and it is used sensibly, as it should be. Why? It's a cultural issue; readability matters. Python is your language, please use type-hints responsibly :) Cheers, Mark. ___ 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/alex.gronholm%40nextday.fi ___ 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] Can we clean up the buildbots please?
Larry Hastings writes: >> Is MSVS 2015 the only supported compiler for Python 3.5 on Windows? >> What's the other buildbot using MSVS 2015? For a while I think the only buildbot was my 8.1 slave, but I believe at this point Jeremy may also have it on his 7 slave. The latest on my 7 slave is still 2010 (which is still working, sans recent test failures). > I'll answer my own question here. According to PCbuild/readme.txt: > >This script will use the env.bat script to detect one of Visual >Studio 2015, 2013, 2012, or 2010, any of which may be used to build >Python, though only Visual Studio 2015 is officially supported. > > I'll admit I'm puzzled by the wisdom of using unsupported compilers on > buildbots. I guess it's a historical thing. But I gently suggest > that we should either upgrade those buildbots to a supported compiler > or remove them entirely. Definitely we should remove unsupported the > two unsupported platforms from the buildbots--that's just crazy. To be fair, VS 2015 hasn't been officially released yet. It only recently (as in a few weeks ago) reached RC stage. Given the size of installing it, and earlier uncertainty about upgrading during the pre-release cycle, plus some early issues with the build process, for my part I've opted to hold off with my older slaves until it hits release status, using only the 8.1 slave until then. (Arguably the current RC is supposed to be at most a minor update away from full release, so we're probably close) Along the way it was concluded that XP just wasn't worth making work for the 3.5+ development, but the slave was still valuable for the 2.7 branch, so would be left around for now for that purpose. It is a bit misleading to still be trying to build the 3.x branch on it but I suspect eliminating the branch from that slave is just an oversight, or nobody with the proper access has had time yet. -- David ___ 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
[Python-Dev] Fwd: Re: [python-committers] Reminder: Python 3.5 beta 1 will be tagged tomorrow
Whoops, didn't send my reply to both lists. Forwarded, below. Forwarded Message Subject: Re: [python-committers] [Python-Dev] Reminder: Python 3.5 beta 1 will be tagged tomorrow Date: Sat, 23 May 2015 12:23:09 -0700 From: Larry Hastings To: python-committ...@python.org On 05/23/2015 06:25 AM, Nick Coghlan wrote: I filedhttp://bugs.python.org/issue24270 to track this, but there's a fair bit of work to be done to integrate the changes into the existing math module's code, tests and documentation. I'm willing to consider a feature freeze exception for this, as long as * it doesn't make invasive changes (it looks like it will literally add one new entry point, which is acceptable) * it's cleaned up in the way the core devs are proposing (integrate it into the math module, including tests and documentation) * it's done before beta 2 Somebody, please take that as an encouragement to get this cleaned up and ready for checkin. //arry/ p.s. Would it make sense to add a form of isclose to unittest? ___ 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] [Python-checkins] peps: PEP 489: The PEP is accepted.
Are you also going to check the code in or is someone else doing it? On Fri, May 22, 2015, 17:47 eric.snow wrote: > https://hg.python.org/peps/rev/1fbc23a1078c > changeset: 5874:1fbc23a1078c > user:Eric Snow > date:Fri May 22 15:45:38 2015 -0600 > summary: > PEP 489: The PEP is accepted. > > files: > pep-0489.txt | 11 --- > 1 files changed, 8 insertions(+), 3 deletions(-) > > > diff --git a/pep-0489.txt b/pep-0489.txt > --- a/pep-0489.txt > +++ b/pep-0489.txt > @@ -7,13 +7,13 @@ > Nick Coghlan > BDFL-Delegate: Eric Snow > Discussions-To: import-...@python.org > -Status: Draft > +Status: Final > Type: Standards Track > Content-Type: text/x-rst > Created: 11-Aug-2013 > Python-Version: 3.5 > -Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015 > -Resolution: > +Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015, 7-May-2015, > 18-May-2015 > +Resolution: > https://mail.python.org/pipermail/python-dev/2015-May/140108.html > > > Abstract > @@ -730,8 +730,13 @@ > > * PyModuleDef_Slot > > +Other changes: > + > PyModuleDef.m_reload changes to PyModuleDef.m_slots. > > +``BuiltinImporter`` and ``ExtensionFileLoader`` will now implement > +``create_module`` and ``exec_module``. > + > The internal ``_imp`` module will have backwards incompatible changes: > ``create_builtin``, ``create_dynamic``, and ``exec_dynamic`` will be > added; > ``init_builtin``, ``load_dynamic`` will be removed. > > -- > Repository URL: https://hg.python.org/peps > ___ > Python-checkins mailing list > python-check...@python.org > https://mail.python.org/mailman/listinfo/python-checkins > ___ 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
[Python-Dev] 3.5 doc warnings
35\Doc\whatsnew\3.5.rst:686: ERROR: Unknown interpreted text role "module". 35\Doc\library\typing.rst:: WARNING: document isn't included in any toctree from building html docs just now -- Terry Jan Reedy ___ 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] [Python-checkins] peps: PEP 489: The PEP is accepted.
On Sat, May 23, 2015 at 2:22 PM, Brett Cannon wrote: > Are you also going to check the code in or is someone else doing it? Nick already did: http://bugs.python.org/issue24268 https://hg.python.org/cpython/rev/e729b946cc03 :) -eric > > > On Fri, May 22, 2015, 17:47 eric.snow wrote: >> >> https://hg.python.org/peps/rev/1fbc23a1078c >> changeset: 5874:1fbc23a1078c >> user:Eric Snow >> date:Fri May 22 15:45:38 2015 -0600 >> summary: >> PEP 489: The PEP is accepted. >> >> files: >> pep-0489.txt | 11 --- >> 1 files changed, 8 insertions(+), 3 deletions(-) >> >> >> diff --git a/pep-0489.txt b/pep-0489.txt >> --- a/pep-0489.txt >> +++ b/pep-0489.txt >> @@ -7,13 +7,13 @@ >> Nick Coghlan >> BDFL-Delegate: Eric Snow >> Discussions-To: import-...@python.org >> -Status: Draft >> +Status: Final >> Type: Standards Track >> Content-Type: text/x-rst >> Created: 11-Aug-2013 >> Python-Version: 3.5 >> -Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015 >> -Resolution: >> +Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015, 7-May-2015, >> 18-May-2015 >> +Resolution: >> https://mail.python.org/pipermail/python-dev/2015-May/140108.html >> >> >> Abstract >> @@ -730,8 +730,13 @@ >> >> * PyModuleDef_Slot >> >> +Other changes: >> + >> PyModuleDef.m_reload changes to PyModuleDef.m_slots. >> >> +``BuiltinImporter`` and ``ExtensionFileLoader`` will now implement >> +``create_module`` and ``exec_module``. >> + >> The internal ``_imp`` module will have backwards incompatible changes: >> ``create_builtin``, ``create_dynamic``, and ``exec_dynamic`` will be >> added; >> ``init_builtin``, ``load_dynamic`` will be removed. >> >> -- >> Repository URL: https://hg.python.org/peps >> ___ >> Python-checkins mailing list >> python-check...@python.org >> https://mail.python.org/mailman/listinfo/python-checkins > > > ___ > 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/ericsnowcurrently%40gmail.com > ___ 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] 3.5 doc warnings
On Sat, May 23, 2015 at 11:24 PM, Terry Reedy wrote: > 35\Doc\whatsnew\3.5.rst:686: ERROR: Unknown interpreted text role "module". > > 35\Doc\library\typing.rst:: WARNING: document isn't included in any toctree > > from building html docs just now Fixed in https://hg.python.org/cpython/rev/ec1e187173f7 --Berker ___ 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] [Python-checkins] peps: PEP 489: The PEP is accepted.
Ah thanks. I just kept an eye out for your name. :) On Sat, May 23, 2015, 16:32 Eric Snow wrote: > On Sat, May 23, 2015 at 2:22 PM, Brett Cannon wrote: > > Are you also going to check the code in or is someone else doing it? > > Nick already did: > > http://bugs.python.org/issue24268 > https://hg.python.org/cpython/rev/e729b946cc03 > > :) > > -eric > > > > > > > On Fri, May 22, 2015, 17:47 eric.snow > wrote: > >> > >> https://hg.python.org/peps/rev/1fbc23a1078c > >> changeset: 5874:1fbc23a1078c > >> user:Eric Snow > >> date:Fri May 22 15:45:38 2015 -0600 > >> summary: > >> PEP 489: The PEP is accepted. > >> > >> files: > >> pep-0489.txt | 11 --- > >> 1 files changed, 8 insertions(+), 3 deletions(-) > >> > >> > >> diff --git a/pep-0489.txt b/pep-0489.txt > >> --- a/pep-0489.txt > >> +++ b/pep-0489.txt > >> @@ -7,13 +7,13 @@ > >> Nick Coghlan > >> BDFL-Delegate: Eric Snow > >> Discussions-To: import-...@python.org > >> -Status: Draft > >> +Status: Final > >> Type: Standards Track > >> Content-Type: text/x-rst > >> Created: 11-Aug-2013 > >> Python-Version: 3.5 > >> -Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015 > >> -Resolution: > >> +Post-History: 23-Aug-2013, 20-Feb-2015, 16-Apr-2015, 7-May-2015, > >> 18-May-2015 > >> +Resolution: > >> https://mail.python.org/pipermail/python-dev/2015-May/140108.html > >> > >> > >> Abstract > >> @@ -730,8 +730,13 @@ > >> > >> * PyModuleDef_Slot > >> > >> +Other changes: > >> + > >> PyModuleDef.m_reload changes to PyModuleDef.m_slots. > >> > >> +``BuiltinImporter`` and ``ExtensionFileLoader`` will now implement > >> +``create_module`` and ``exec_module``. > >> + > >> The internal ``_imp`` module will have backwards incompatible changes: > >> ``create_builtin``, ``create_dynamic``, and ``exec_dynamic`` will be > >> added; > >> ``init_builtin``, ``load_dynamic`` will be removed. > >> > >> -- > >> Repository URL: https://hg.python.org/peps > >> ___ > >> Python-checkins mailing list > >> python-check...@python.org > >> https://mail.python.org/mailman/listinfo/python-checkins > > > > > > ___ > > 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/ericsnowcurrently%40gmail.com > > > ___ 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
[Python-Dev] [RELEASE] Python 2.7.10
The next bugfix release of the Python 2.7.x series, Python 2.7.10, has been released. The only interesting change since the release candidate is a fix for a regression in cookie parsing. Downloads are available at: https://www.python.org/downloads/release/python-2710/ Report bugs at: https://bugs.python.org Enjoy your 2 digit versions, Benjamin (on behalf of 2.7.10's contributors) ___ 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] devguide: Updated dev guide to reflect the new workflow we're trying for 3.5.
In article <5560b054@udel.edu>, Terry Reedy wrote: > I somehow did not understand this last part before. Rather I thought > the need for pull requests would be highly restricted (and not affect me > ;-). 3.5 bugfixes (and idlelib patches, unclassified), especially those > applied to 3.4, should automatically be in the next 3.5 release. I > cannot imagine a reason not to so so. Otherwise, we could end up with > the awful anomaly that a bugfix (or Idle change) could be in 3.4.4 (the > final maintenance version that comes out after 3.5.0) but not in 3.5.0 > itself. The need for "pull requests" *is* highly restricted. Note that the "pull request" proposal appears in the Release Candidate section and only applies after 3.5.0rc1 is finalized. During the Beta phase that we're entering now, bugfixes should be checked into the new 3.5 branch and they will be released first in 3.5.0b2 or 3.5.0b3. After rc1, bugfixes checked into the 3.5 branch will be released first in 3.5.1 unless they are deemed release critical for 3.5.0 in which case the pull request would be needed. The goal is to have zero release critical fixes after rc1; usually there are very few. -- Ned Deily, n...@acm.org ___ 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
[Python-Dev] Preserving the definition order of class namespaces.
tl;dr Are there any objections to making making the default cls.__prepare__ return OrderedDict instead of dict (and preserve that order in a list on the class)? A couple years ago [1][2] I proposed making class definition namespaces use OrderedDict by default. Said Guido [3]: I'm fine with doing this by default for a class namespace; the type of cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to have 100,000 entries. It turns out making cls.__dict__ an OrderedDict isn't reasonably tractable (due to the concrete API v. subclasses), but really that isn't what I was looking for anyway. Regardless, since it's been a while I just want to run the proposal by the group again. I'm hopeful about landing my C implementation of OrderedDict [4] in the next few days. Also, I have a patch up [5] that implements using OrderedDict for class definitions. So mostly I just want to double check that I'm still good to go. Just to be clear on what I'm proposing specifically, I've summed it up below. -eric - Currently if you want to preserve the order of a class definition you have to use a metaclass with a __prepare__ method (see PEP 3115). However, as that PEP points out [6], the common case for __prepare__ is to use OrderedDict. I'm proposing that we return OrderedDict() by default from __prepare__. Considering the common case, we should also expose that definition order on the class afterward since otherwise the extra information from the class definition namespace is discarded (type.__new__ copies it into a dict which is then used for cls.__dict__). So the key changes are: * use OrderedDict by default for class definition namespace (e.g. from type.__prepare__) * expose that definition order as cls.__definition_order__ (a list) (Note that I will not be changing the actual type of cls.__dict__ (i.e. tp_dict) which will remain a dict.) The effect of the change would be that the following are basically equivalent (relative to the the definition namespace): class Meta(type): @classmethod. def __prepare__(meta, *args, **kwargs): return OrderedDict() class SpamOld(metaclass=Meta): a = 1 b = 2 c = 3 __definition_order__ = list(locals()) class SpamNew: a = 1 b = 2 c = 3 assert SpamOld.__definition__order == SpamNew.__definition_order__ The key differences are: * for SpamNew you don't need to use a metaclass [7][8] * for SpamNew you don't need to rely on the behavior of locals() * for SpamNew the class definition isn't cluttered with extra boilerplate for __definition_order__ * class decorators that care about definition order [9] don't have to require that classes like SpamNew manually preserve that order somehow The patch for the change is pretty minimal. [5] Also, Nick Coghlan recently expressed that he favored using OrderedDict by default over the alternative presented by PEP 422/487. [10] [1] https://mail.python.org/pipermail/python-ideas/2013-February/019690.html [2] https://mail.python.org/pipermail/python-dev/2013-June/127103.html [3] Guido: https://mail.python.org/pipermail/python-ideas/2013-February/019704.html [4] http://bugs.python.org/issue16991 [5] http://bugs.python.org/issue24254 [6] see the "Alternate Proposals" section of https://www.python.org/dev/peps/pep-3115/ [7] PEPs 422 and 487 relatedly focus on the benefits of reducing the need to use metaclasses [8] https://mail.python.org/pipermail/python-ideas/2013-February/019706.html [9] see "Key points" on https://mail.python.org/pipermail/python-dev/2013-February/124439.html [10] Nick: https://mail.python.org/pipermail/python-ideas/2015-March/032254.html ___ 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] Preserving the definition order of class namespaces.
On 24 May 2015 at 11:15, Eric Snow wrote: > tl;dr Are there any objections to making making the default > cls.__prepare__ return OrderedDict instead of dict (and preserve that > order in a list on the class)? > > A couple years ago [1][2] I proposed making class definition > namespaces use OrderedDict by default. Said Guido [3]: > > I'm fine with doing this by default for a class namespace; the type of > cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to > have 100,000 entries. > > It turns out making cls.__dict__ an OrderedDict isn't reasonably > tractable (due to the concrete API v. subclasses), but really that > isn't what I was looking for anyway. > > Regardless, since it's been a while I just want to run the proposal by > the group again. I'm hopeful about landing my C implementation of > OrderedDict [4] in the next few days. Also, I have a patch up [5] > that implements using OrderedDict for class definitions. So mostly I > just want to double check that I'm still good to go. While it isn't controversial (since you already have the +1 from Guido), it's worth writing up the change as a PEP for 3.6 anyway, since that then provides clearer guidance to alternate implementations that they're going to need to change the way their class namespace evaluation works for 3.6. Let's not repeat the zip archive and directory execution mistake that 3.5's PEP 441 aimed to resolve :) PEP 487 could then be updated to reference that PEP as part of the rationale for dropping the "easy namespace customisation" aspect of the proposal. 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] Preserving the definition order of class namespaces.
On 24 May 2015 at 12:04, Nick Coghlan wrote: > On 24 May 2015 at 11:15, Eric Snow wrote: >> tl;dr Are there any objections to making making the default >> cls.__prepare__ return OrderedDict instead of dict (and preserve that >> order in a list on the class)? >> >> A couple years ago [1][2] I proposed making class definition >> namespaces use OrderedDict by default. Said Guido [3]: >> >> I'm fine with doing this by default for a class namespace; the type of >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to >> have 100,000 entries. >> >> It turns out making cls.__dict__ an OrderedDict isn't reasonably >> tractable (due to the concrete API v. subclasses), but really that >> isn't what I was looking for anyway. >> >> Regardless, since it's been a while I just want to run the proposal by >> the group again. I'm hopeful about landing my C implementation of >> OrderedDict [4] in the next few days. Also, I have a patch up [5] >> that implements using OrderedDict for class definitions. So mostly I >> just want to double check that I'm still good to go. > > While it isn't controversial (since you already have the +1 from > Guido), it's worth writing up the change as a PEP for 3.6 anyway, > since that then provides clearer guidance to alternate implementations > that they're going to need to change the way their class namespace > evaluation works for 3.6. Eric clarified for me that Larry was considering granting a feature freeze exemption to defer landing this to beta 2 while Eric tracked down a segfault bug in the current patch that provides a C implementation of OrderedDict. That sounds like a nicer approach than what I did for PEP 489 (where I checked in an initial version that I knew still had a refleak bug in it), so +1 from me for going down that path. A top level section in the What's New would cover my concerns regarding making sure folks are suitably aware of the change (as I believe leaving it out of the original 2.6 What's New document was the real problem with making people aware of the addition of zip archive and directory execution support). Regards, 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] Preserving the definition order of class namespaces.
On 05/23/2015 07:38 PM, Nick Coghlan wrote: Eric clarified for me that Larry was considering granting a feature freeze exemption to defer landing this to beta 2 while Eric tracked down a segfault bug in the current patch that provides a C implementation of OrderedDict. Yeah, I'm willing to grant the feature freeze exception, assuming he can find general approval from the community (and assuming he still has Guido's blessing). I just wanted a little more sunlight on the topic, rather than rushing to check it in. //arry/ ___ 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] Preserving the definition order of class namespaces.
How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan wrote: > On 24 May 2015 at 12:04, Nick Coghlan wrote: > > On 24 May 2015 at 11:15, Eric Snow wrote: > >> tl;dr Are there any objections to making making the default > >> cls.__prepare__ return OrderedDict instead of dict (and preserve that > >> order in a list on the class)? > >> > >> A couple years ago [1][2] I proposed making class definition > >> namespaces use OrderedDict by default. Said Guido [3]: > >> > >> I'm fine with doing this by default for a class namespace; the type > of > >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely > to > >> have 100,000 entries. > >> > >> It turns out making cls.__dict__ an OrderedDict isn't reasonably > >> tractable (due to the concrete API v. subclasses), but really that > >> isn't what I was looking for anyway. > >> > >> Regardless, since it's been a while I just want to run the proposal by > >> the group again. I'm hopeful about landing my C implementation of > >> OrderedDict [4] in the next few days. Also, I have a patch up [5] > >> that implements using OrderedDict for class definitions. So mostly I > >> just want to double check that I'm still good to go. > > > > While it isn't controversial (since you already have the +1 from > > Guido), it's worth writing up the change as a PEP for 3.6 anyway, > > since that then provides clearer guidance to alternate implementations > > that they're going to need to change the way their class namespace > > evaluation works for 3.6. > > Eric clarified for me that Larry was considering granting a feature > freeze exemption to defer landing this to beta 2 while Eric tracked > down a segfault bug in the current patch that provides a C > implementation of OrderedDict. That sounds like a nicer approach than > what I did for PEP 489 (where I checked in an initial version that I > knew still had a refleak bug in it), so +1 from me for going down that > path. > > A top level section in the What's New would cover my concerns > regarding making sure folks are suitably aware of the change (as I > believe leaving it out of the original 2.6 What's New document was the > real problem with making people aware of the addition of zip archive > and directory execution support). > > Regards, > 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/guido%40python.org > -- --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] Preserving the definition order of class namespaces.
On 05/23/2015 09:46 PM, Guido van Rossum wrote: How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) In his patch, type_new tests to see if the dict passed in is an ordered dict (PyODict_Check). __definition_order__ is only created and populated if it passes the test. http://bugs.python.org/file39446/odict-class-definition-namespace.diff //arry/ ___ 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] Preserving the definition order of class namespaces.
But isn't that also a problem? It would make the existence of that member a bit unpredictable. On Saturday, May 23, 2015, Larry Hastings wrote: > > > On 05/23/2015 09:46 PM, Guido van Rossum wrote: > > How will __definition_order__ be set in the case where __prepare__ doesn't > return an OrderedDict? Or where a custom metaclass's __new__ calls its > superclass's __new__ with a plain dict? (I just wrote some code that does > that. :-) > > > In his patch, type_new tests to see if the dict passed in is an ordered > dict (PyODict_Check). __definition_order__ is only created and populated > if it passes the test. > > http://bugs.python.org/file39446/odict-class-definition-namespace.diff > > > */arry* > -- --Guido van Rossum (on iPad) ___ 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] Preserving the definition order of class namespaces.
On May 23, 2015 10:47 PM, "Guido van Rossum" wrote: > > How will __definition_order__ be set in the case where __prepare__ doesn't return an OrderedDict? Or where a custom metaclass's __new__ calls its superclass's __new__ with a plain dict? (I just wrote some code that does that. :-) I was planning on setting it to None if the order is not available. At the moment that's just a check for OrderedDict. -eric > > On Sat, May 23, 2015 at 7:38 PM, Nick Coghlan wrote: >> >> On 24 May 2015 at 12:04, Nick Coghlan wrote: >> > On 24 May 2015 at 11:15, Eric Snow wrote: >> >> tl;dr Are there any objections to making making the default >> >> cls.__prepare__ return OrderedDict instead of dict (and preserve that >> >> order in a list on the class)? >> >> >> >> A couple years ago [1][2] I proposed making class definition >> >> namespaces use OrderedDict by default. Said Guido [3]: >> >> >> >> I'm fine with doing this by default for a class namespace; the type of >> >> cls.__dict__ is already a non-dict (it's a proxy) and it's unlikely to >> >> have 100,000 entries. >> >> >> >> It turns out making cls.__dict__ an OrderedDict isn't reasonably >> >> tractable (due to the concrete API v. subclasses), but really that >> >> isn't what I was looking for anyway. >> >> >> >> Regardless, since it's been a while I just want to run the proposal by >> >> the group again. I'm hopeful about landing my C implementation of >> >> OrderedDict [4] in the next few days. Also, I have a patch up [5] >> >> that implements using OrderedDict for class definitions. So mostly I >> >> just want to double check that I'm still good to go. >> > >> > While it isn't controversial (since you already have the +1 from >> > Guido), it's worth writing up the change as a PEP for 3.6 anyway, >> > since that then provides clearer guidance to alternate implementations >> > that they're going to need to change the way their class namespace >> > evaluation works for 3.6. >> >> Eric clarified for me that Larry was considering granting a feature >> freeze exemption to defer landing this to beta 2 while Eric tracked >> down a segfault bug in the current patch that provides a C >> implementation of OrderedDict. That sounds like a nicer approach than >> what I did for PEP 489 (where I checked in an initial version that I >> knew still had a refleak bug in it), so +1 from me for going down that >> path. >> >> A top level section in the What's New would cover my concerns >> regarding making sure folks are suitably aware of the change (as I >> believe leaving it out of the original 2.6 What's New document was the >> real problem with making people aware of the addition of zip archive >> and directory execution support). >> >> Regards, >> 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/guido%40python.org > > > > > -- > --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
