Re: [Python-Dev] draft 3.1 release schedule
Raymond Hettinger python at rcn.com writes: You might also want to collect a list of serious changes that you want in this release; I'm making minor updates to the decimal module to match the 1.68 version of the spec. What about decimal-in-C, by the way? Is anyone still working on it? Regards Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Benjamin Peterson wrote: You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Please add auto-numbered replacement fields in str.format() strings http://bugs.python.org/issue5237 Guido wrote today Please go ahead and finish this. I'm glad this is going in! Eric Smith says he should have a final patch ready by the end of PyCon or so. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/9 Terry Reedy tjre...@udel.edu: Benjamin Peterson wrote: You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Please add auto-numbered replacement fields in str.format() strings http://bugs.python.org/issue5237 Done. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. Skip ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; Bob Ippolito has a good sized patch to update the json module and improve its performance. http://bugs.python.org/issue4136 Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/9 Raymond Hettinger pyt...@rcn.com: You might also want to collect a list of serious changes that you want in this release; Bob Ippolito has a good sized patch to update the json module and improve its performance. http://bugs.python.org/issue4136 ...and it's already on the PEP. :) -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/9 s...@pobox.com: You might also want to collect a list of serious changes that you want in this release; http://bugs.python.org/issue4847 Not yet fixed. Needs: * Decision about the correct fix (I think it will involve an API change). * Test case and a patch. * Probably small documentation changes as well. I'm wiped out this evening. I'll try to look into it, but I suspect it might require a bit more time than I have in the next day or two. That seems important, but quite serious enough to warrant inclusion in the PEP. (and not a feature) If you'd like it to block the release, you can set the priority to release blocker. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; I'm making minor updates to the decimal module to match the 1.68 version of the spec. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
I'm making minor updates to the decimal module to match the 1.68 version of the spec. Looks like most was already done. Just needs some doc fixes. Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Martin v. Löwis writes: From time to time, people ask what they can do push a change into Python that they really think is important. I once offered that people who want a patch in Python really badly should review 10 other patches in return, up to the point where they make a recommendation about the fate of the patches. I was then talked into accepting just 5 such patches. I have since withdrawn this offer, because I'm really sad to hear that. I considered that one of the really nice features of Python as a project (even though it was of course your individual initiative). a) I was the only one making that offer in public, and IIRC others did, but you were the only one to do so repeatedly and as a timely response to reports that the patch queue was going untended. b) I was sometimes not really able to respond in a timely manner when the offer was invoked, because of overload. Well, that happens. An alternative to withdrawing entirely, would be increasing the price (eg, to ten patches as you originally suggested). Or specifying windows in your calendar when the offer is open. Eg, avoid doubling up on release times when you need make time to build installers etc. ... but of course just before release is when people will get antsy about their lost patches. I hope that somebody will pick up the slack here, because review is really important to the workflow, and getting more people involved in reviewing at some level is more important (because it's less glamorous in itself) than attracting coders. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Well, that happens. An alternative to withdrawing entirely, would be increasing the price (eg, to ten patches as you originally suggested). Or specifying windows in your calendar when the offer is open. Eg, avoid doubling up on release times when you need make time to build installers etc. ... but of course just before release is when people will get antsy about their lost patches. I hope that somebody will pick up the slack here, because review is really important to the workflow, and getting more people involved in reviewing at some level is more important (because it's less glamorous in itself) than attracting coders. It's funny ... I would have thought that one of the most attractive aspects of offering patches for inclusion was not just getting feature X into the language, but the opportunity to have your code reviewed by the best of the best, or similarly to review the code of others and really think about its strengths and weaknesses. I would have said that participating in a project at that level would basically be the best opportunity for ongoing learning and development available. I guess I'm saying that I'm surprised people aren't a bit more appreciative of the opportunity to review code. I mean, I wouldn't think that Python was just work for anyone who has the passion to commit back to the core project. I don't think I would even be on this list or attempting to put together my first (and almost inconseqentially small) patch if it weren't for the fact that I see it as a huge opportunity. It's certainly not an attempt to 'push' anything into the language. Obviously that's what you found though -- people who weren't really understanding of how the language gets put together. I can imagine having held that view in the past myself, also. I can to some extent understand the perspective of feeling you have some fantastic idea which you'd love to get implemented; yet the people who can make it happen are too concerned with their own issues to take the time to roll in your changes. Would you object to my blogging on the topic in line with the comments that I have just made? I almost feel silly making that kind of suggestion after having only been here a short time -- I feel a bit boorish! -- but having run The Python Papers and also no longer being a 'green' developer at work, I feel as though I do have something to contribute on the topic even if it is somewhat immaturely conceived. Regards, -Tennessee ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Tennessee Leeuwenburg writes: I hope that somebody will pick up the slack here, because review is really important to the workflow, and getting more people involved in reviewing at some level is more important (because it's less glamorous in itself) than attracting coders. I would have said that participating in a project at that level would basically be the best opportunity for ongoing learning and development available. It is, and IMO Python is an excellent example of that. Please don't get me wrong -- the core developers do a lot of reviewing. It's just not as visible, or as clearly available to non-core participants, as Martin's 1-for-5 offer was. Many, perhaps most, contributions are one-offs by people to whom Python is a tool, not their community. They have little time, and as far as they know, less expertise to participate in the review process. Martin's offer was an open invitation, in terms that any contributor can appreciate, even if they don't take advantage of it right away. I admire that style. Would you object to my blogging on the topic in line with the comments that I have just made? It's not my place to say yes or no, to you or on behalf of the community. A suggestion, though. View the contribution visualization video based on the commit log (the URL was posted here a while back, but I don't seem to have it offhand), which shows what a vibrant community this is in a very graphic way. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
I hope that somebody will pick up the slack here, because review is really important to the workflow, and getting more people involved in reviewing at some level is more important (because it's less glamorous in itself) than attracting coders. Ok, then let me phrase it this way: if somebody else makes the offer, I'll continue to support it (so to share the load between us two). Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
I guess I'm saying that I'm surprised people aren't a bit more appreciative of the opportunity to review code. Not sure what people you are referring to here which aren't appreciative of the opportunity to review code. Committers? Non-committers? I don't think I would even be on this list or attempting to put together my first (and almost inconseqentially small) patch if it weren't for the fact that I see it as a huge opportunity. It's certainly not an attempt to 'push' anything into the language. And this attitude I like best from contributors. Many people contribute because they want to help, and don't expect anything in return. However, many other people contribute because it solves a problem that they have (scratch your own itch). They keep having the problem even after they fixed it, in a sense, because they now have to reapply the patch over and over again - for each Python release, and possibly for each machine they deploy to (and for some, they can't change the installed Python). Those people are eager to see their patch integrated, preferably into the version that is already installed on their machines (which requires the time machine :-) Would you object to my blogging on the topic in line with the comments that I have just made? Go ahead! I really can't say much about blogging - I don't write blogs, nor read them. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Stephen J. Turnbull wrote: A suggestion, though. View the contribution visualization video based on the commit log (the URL was posted here a while back, but I don't seem to have it offhand), which shows what a vibrant community this is in a very graphic way. There's one here: http://www.vimeo.com/1093745 That one runs up until just after the switch to subversion (as indicated by the big influx of new names at the end, which is largely an artifact of usernames changing from shortened forms to full names). Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
On Mon, Mar 2, 2009 at 4:22 PM, Martin v. Löwis mar...@v.loewis.dewrote: Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. Just to put this into perspective: I personally don't see that as a very important problem. I didn't know IDLESTARTUP existed, and I use PYTHONSTARTUP only for the command line (to setup readline and history). I think there are many more open issues that are *way* more important. Martin, No disrespect intended but I don't see how this puts things into perspective. I'm writing to you from the annual computer science education conference (SIGCSE) where Python is clearly gaining ground as an important language for teaching computer science. It seems logical to me that the committers are high powered Python users who don't think much about Python being used in education. I'm just as frustrated as Mitchell about a patch for displaying ranges and dict_keys/values objects in a more user friendly way. I submitted this patch during the 3.0 alpha phase and it is still sitting around. For me this is a serious problem, but I can understand how it seems pretty minor to others, who are not teaching new programmers. So what is the solution? The obvious solution is for one of us, that is someone who uses Python as an education tool, to become a committer. This seems problematic to me. Although I'm willing to be a committer, and I'm confident I have the development skills necessary to be a committer I don't have the time to develop the resume of patches needed to earn that privilege. It would be nice if we could find some solution to this. Brad This is not to say that the patch should not applied - I haven't even looked at it. It's just a warning that, if no other committer feels this is as important as you fell it is, it may not be committed reviewed and committed before 3.1. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/bmiller%40luther.edu -- Brad Miller Assistant Professor, Computer Science Luther College ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
On Thu, Mar 5, 2009 at 10:53 AM, Brad Miller millb...@luther.edu wrote: On Mon, Mar 2, 2009 at 4:22 PM, Martin v. Löwis mar...@v.loewis.de wrote: Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. Just to put this into perspective: I personally don't see that as a very important problem. I didn't know IDLESTARTUP existed, and I use PYTHONSTARTUP only for the command line (to setup readline and history). I think there are many more open issues that are *way* more important. Martin, No disrespect intended but I don't see how this puts things into perspective. I'm writing to you from the annual computer science education conference (SIGCSE) where Python is clearly gaining ground as an important language for teaching computer science. It seems logical to me that the committers are high powered Python users who don't think much about Python being used in education. I'm just as frustrated as Mitchell about a patch for displaying ranges and dict_keys/values objects in a more user friendly way. I submitted this patch during the 3.0 alpha phase and it is still sitting around. For me this is a serious problem, but I can understand how it seems pretty minor to others, who are not teaching new programmers. So what is the solution? The obvious solution is for one of us, that is someone who uses Python as an education tool, to become a committer. This seems problematic to me. Although I'm willing to be a committer, and I'm confident I have the development skills necessary to be a committer I don't have the time to develop the resume of patches needed to earn that privilege. It would be nice if we could find some solution to this. Or... IDLE could be taken out from Python. Tkinter is following the same path too, sadly. My hope is that by removing IDLE from Python it would bring new developers that are not necessary python developers (by this I mean developers of python itself). I changed IDLE quite a bit last year, but I'm not sure if anyone cared enough to look at it (added tabs, ttk support, themes, window relayout, and some other things), and I don't think continuing with it in the stdlib is bringing any benefits. I have commit access, and although I have been inactive for two or three weeks (maybe a bit more) now, I have submitted plenty of fixes for tkinter which are mostly reviewed by Martin, and only, Martin -- when he has time to review or when the fix hits some level of important enough to be looked at. I could just commit these fixes, but some people would hate me then because I didn't let anyone review, so I don't really think adding more new committers will bring the benefits you are expecting. A different problem also present in both tkinter and IDLE is the lack of tests. Brad This is not to say that the patch should not applied - I haven't even looked at it. It's just a warning that, if no other committer feels this is as important as you fell it is, it may not be committed reviewed and committed before 3.1. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/bmiller%40luther.edu -- Brad Miller Assistant Professor, Computer Science Luther College ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/ggpolo%40gmail.com -- -- Guilherme H. Polo Goncalves ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
So what is the solution? In the specific case, I don't know. I recall that somebody offered to pick up the change. I really didn't mean to suggest that the patch will remain unnoticed - it was just a warning that it *might* remain unnoticed. The more general issue is that of patches being unreviewed for a long time, whether they have educational background or some other background (say, cross-compilation, HP-UX support, etc). From time to time, people ask what they can do push a change into Python that they really think is important. I once offered that people who want a patch in Python really badly should review 10 other patches in return, up to the point where they make a recommendation about the fate of the patches. I was then talked into accepting just 5 such patches. I have since withdrawn this offer, because a) I was the only one making that offer in public, and b) I was sometimes not really able to respond in a timely manner when the offer was invoked, because of overload. So, for the more general issue, I don't have a solution, either. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Hi, Benjamin Peterson wrote: 3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27 Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, offer tests, docs, patches and/or reviews as needed and ask-pretty-please-for-inclusion' :) Would early post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. FWIW, further tracker cleanup should happen sometime next week, let me know if you need any tracker janitorvelopment done :) Regards, Daniel [1] Current list: http://bugs.python.org/issue1097797 http://bugs.python.org/issue3244 http://bugs.python.org/issue736428 http://bugs.python.org/issue1175686 http://bugs.python.org/issue4733 [2] Examples: http://bugs.python.org/issue4953 http://bugs.python.org/issue1074333 ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Mitchell L Model wrote: Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. [...] I would really like to see them in 3.1. The patch is already there; someone just has to do whatever gets done with patches to validate it and check it in. It's not a lot of code changes. Mitchell, thanks for the reports and patches you've been contributing. FWIW, I plan to follow up on these specific issues (and 5276) before 3.1a2, mostly to add tests and a +1 for integration. Regards, Daniel ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/3 Daniel (ajax) Diniz aja...@gmail.com: Benjamin, I'd like to nominate a couple (minor) RFEs[1] and bug fixes[2] for 3.1. By 'nominate' I mean 'group related issues together, offer tests, docs, patches and/or reviews as needed and ask-pretty-please-for-inclusion' :) Would early post-3.1a1 versus pre-3.1a1 make a difference in likelihood of proposed changes going in? I can try to come up with a detailed list before March 5, but I'd rather present it next week, after taking a look at all remaining open issues. Assuming you find reviews/committers for those patches, it's all good until the first beta. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. I would really like to see them in 3.1. The patch is already there; someone just has to do whatever gets done with patches to validate it and check it in. It's not a lot of code changes. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Would whoever is responsible for IDLE please take a look at the patches I submitted for Python 2 3 [tracker IDs 5233 and 5234 respectively]. These change the behavior of IDLE so that IDLESTARTUP or PYTHONSTARTUP files are executed with each restart. This allows loading frequently used packages, personal utilities, etc. automatically at each restart. I consider this a very important problem in IDLE, especially when using it to teach. Just to put this into perspective: I personally don't see that as a very important problem. I didn't know IDLESTARTUP existed, and I use PYTHONSTARTUP only for the command line (to setup readline and history). I think there are many more open issues that are *way* more important. This is not to say that the patch should not applied - I haven't even looked at it. It's just a warning that, if no other committer feels this is as important as you fell it is, it may not be committed reviewed and committed before 3.1. Regards, Martin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/2/27 Benjamin Peterson benja...@python.org: 2009/2/27 Nick Coghlan ncogh...@gmail.com schrieb: I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251 If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev. Ok. I've added it. Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?) Paul. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Paul Moore wrote: 2009/2/27 Benjamin Peterson benja...@python.org: 2009/2/27 Nick Coghlan ncogh...@gmail.com schrieb: I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251 If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev. Ok. I've added it. Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?) As much as I'd like to get a simple generic implementation into functools, the lack of support for ABCs still bothers me (despite my last post about that on the tracker item). I'd be a -0 on it going in as is, but if someone can figure out a clever way of supporting ABCs without completing killing the invocation speed for generics, that would go up to a +1. (The current difficulty of this may actually reflect a more significant limitation on the available metadata for ABCs in PEP 3119: it is easy to ask is this specific type an example of this ABC?, but difficult to ask which ABCs is this type as example of?. For actual inheritance, the __mro__ attribute means that both questions are easy to answer, but I'm not aware of any corresponding way of answering the latter question for ABCs) Cheers, Nick. P.S. I just unassigned myself from that tracker item - I'm going to have my hands full working on the proposed change to the with statement. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/3/1 Paul Moore p.f.mo...@gmail.com: Is it worth getting simplegeneric exposed in 3.1 (http://bugs.python.org/issue5135)? If it's going to be in 2.7, I'd like to see it hit 3.1. The patch is against trunk (for 2.7) at the moment, I'm not sure what the process would be for forward-porting it (do I generate a new patch against the py3k branch, or should it be applied to trunk and merged in?) Patches to the trunk are fine. As for the actual feature, I don't think it should hold up releases. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Benjamin, You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ I think you could add update json package to reflect the current simplejson version (see http://bugs.python.org/issue4136). cheers Antoine. ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ I think you could add update json package to reflect the current simplejson version (see http://bugs.python.org/issue4136). Also, I'm expecting that ordered dictionaries will be ready: http://www.python.org/dev/peps/pep-0372/ Raymond ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Benjamin Peterson wrote: 2009/2/27 Raymond Hettinger pyt...@rcn.com: You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ I think you could add update json package to reflect the current simplejson version (see http://bugs.python.org/issue4136). Also, I'm expecting that ordered dictionaries will be ready: http://www.python.org/dev/peps/pep-0372/ Thanks. I've added these items to the PEP. I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251 If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia --- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
2009/2/27 Nick Coghlan ncogh...@gmail.com schrieb: I should have a PEP (and implementation) ready for alpha 2 to address the current discrepancy between contextlib.nested and actual nested with statements: http://bugs.python.org/issue5251 If you do add a reference to that bug report to the release PEP, mark fixing it as a maybe though - with the associated PEP not even written yet, I obviously still have some work to do to get the semantic change approved by Guido and the rest of python-dev. Ok. I've added it. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
Benjamin Peterson schrieb: On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum gu...@python.org wrote... Something like this? 3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27 That sounds reasonable. I will try to enforce a fairly strict stability policy during the beta and RCs. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Is the intention to release 2.7 and 3.1 in parallel? I suspect, comparing this to http://www.python.org/dev/peps/pep-0373/ that there is some name mangling in pep-0375? Regards, Gregor ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
On Tue, Feb 17, 2009 at 7:55 AM, Gregor Lingl gregor.li...@aon.at wrote: I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ Is the intention to release 2.7 and 3.1 in parallel? No. I suspect, comparing this to http://www.python.org/dev/peps/pep-0373/ that there is some name mangling in pep-0375? It seems I left 2.7 in the prose a few times. I've fixed that now. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Feb 17, 2009, at 8:55 AM, Gregor Lingl wrote: Is the intention to release 2.7 and 3.1 in parallel? I don't think we should this time. We want to get 3.1 out sooner than the typical 18 month development cycle, and I think we should concentrate on making that a great release without worrying about also trying to get 2.7 out. :Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSZrJ7HEjvBPtnXfVAQJEKAP/fQ/SWqCNYmPQreBdN4Y7BKC4+K0f9Kk6 7DuVEyjd/BI9luqLxeGgZFdm9cwBXNkrSQ0Vw9wGx5rjGWRxPhAzWPh3tSEUQzFb wpQCqGkwktb7dxub4f+aeYBWJ802jrapfDXY48iRuGopCstm4IevjkZCesnMwrf7 fpOX6VDx5IQ= =y5N7 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson benja...@python.org wrote: Here's a very tentative 3.1 release schedule. Thanks! Glad you're taking your new role of release manager seriously and are starting to plan ahead. 3.1a1 March 7 (Saturday) 3.1a2 April 11 (Saturday) 3.1b1 May 2 (Saturday) 3.1b2 May 23 (Saturday) 3.1rc1 June 13 (Saturday) 3.1rc2 June 27 (Saturday) And final release on...? I'm interested in your feedback with regards to the amount of time in beta and RC phase. Do you think we need that much time? Otherwise, we could move the final release back sometime in mid June. It's a bit hard to compare this to other release schedules because it's coming much sooner after 3.0. I would guess this means that not as much has changed, and so the schedule could conceivably more compressed. If you want to take beta seriously as a time of consolidation where no new features should be added and no API changes should take place, you might consider dropping one beta, since in practice it is often hard to keep developers from wanting to change stuff anyways. You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. -- --Guido van Rossum (home page: http://www.python.org/~guido/) ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] draft 3.1 release schedule
On Sun, Feb 15, 2009 at 10:59 AM, Guido van Rossum gu...@python.org wrote: On Sat, Feb 14, 2009 at 12:29 PM, Benjamin Peterson benja...@python.org wrote: 3.1a1 March 7 (Saturday) 3.1a2 April 11 (Saturday) 3.1b1 May 2 (Saturday) 3.1b2 May 23 (Saturday) 3.1rc1 June 13 (Saturday) 3.1rc2 June 27 (Saturday) And final release on...? Oops! Forgot about that one. :) July 4th. I'm interested in your feedback with regards to the amount of time in beta and RC phase. Do you think we need that much time? Otherwise, we could move the final release back sometime in mid June. It's a bit hard to compare this to other release schedules because it's coming much sooner after 3.0. I would guess this means that not as much has changed, and so the schedule could conceivably more compressed. If you want to take beta seriously as a time of consolidation where no new features should be added and no API changes should take place, you might consider dropping one beta, since in practice it is often hard to keep developers from wanting to change stuff anyways. Something like this? 3.1a1 March 7 3.1a2 April 4 3.1b1 May 2 3.1rc1 May 30 3.1rc2 June 13 3.1 Final June 27 That sounds reasonable. I will try to enforce a fairly strict stability policy during the beta and RCs. You might also want to collect a list of serious changes that you want in this release; I know I/O in C is on the list (and without it I wouldn't consider it worth releasing) but there may be others. The developers of such features ought to be on board with delivering their code before the first beta. I've started a list on the release PEP [1]. [1] http://www.python.org/dev/peps/pep-0375/ -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] draft 3.1 release schedule
Here's a very tentative 3.1 release schedule. 3.1a1 March 7 (Saturday) 3.1a2 April 11 (Saturday) 3.1b1 May 2 (Saturday) 3.1b2 May 23 (Saturday) 3.1rc1 June 13 (Saturday) 3.1rc2 June 27 (Saturday) I'm interested in your feedback with regards to the amount of time in beta and RC phase. Do you think we need that much time? Otherwise, we could move the final release back sometime in mid June. -- Regards, Benjamin ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
