Re: [Python-Dev] release plan for 2.5 ?
On Sunday 12 February 2006 21:51, Thomas Wouters wrote: Well, in the past, features -- even syntax changes -- have gone in between the last beta and the final release (but reminding Guido might bring him to tears of regret. ;) Features have also gone into what would have been 'bugfix releases' if you looked at the numbering alone (1.5 - 1.5.1 - 1.5.2, for instance.) The past doesn't have a very impressive track record... *cough* Go on. Try slipping a feature into a bugfix release now, see how loudly you can make an Australian swear... See also PEP 006. Do I need to add a bad language caveat in it? ___ 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] release plan for 2.5 ?
On Thursday 23 February 2006 09:19, Guido van Rossum wrote: However the definition of feature vs. bugfix isn't always crystal clear. Some things that went into 2.4 recently felt like small features to me; but others may disagree: - fixing chunk.py to allow chunk size to be 2GB - supporting Unicode filenames in fileinput.py Are these features or bugfixes? Sure, the line isn't so clear sometimes. I consider both of these bugfixes, but others could disagree. True/False, on the other hand, I don't think anyone disagrees about wink/duck This stuff is always open for discussion, of course. Anthony -- Anthony Baxter [EMAIL PROTECTED] It's never too late to have a happy childhood. ___ 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] release plan for 2.5 ?
On Sat, Feb 11, 2006 at 10:38:10PM -0800, Neal Norwitz wrote: On 2/10/06, Georg Brandl [EMAIL PROTECTED] wrote: I am not experienced in releasing, but with the multitude of new things introduced in Python 2.5, could it be a good idea to release an early alpha not long after all (most of?) the desired features are in the trunk? In the past, all new features had to be in before beta 1 IIRC (it could have been beta 2 though). The goal is to get things in sooner, preferably prior to alpha. Well, in the past, features -- even syntax changes -- have gone in between the last beta and the final release (but reminding Guido might bring him to tears of regret. ;) Features have also gone into what would have been 'bugfix releases' if you looked at the numbering alone (1.5 - 1.5.1 - 1.5.2, for instance.) The past doesn't have a very impressive track record... However, beta 1 is a very good ultimate deadline, and it's been stuck by for the last few years, AFAIK. But I concur with: For 2.5, we should strive really hard to get features implemented prior to alpha 1. Some of the changes (AST, ssize_t) are pervasive. AST while localized, ripped the guts out of something every script needs (more or less). ssize_t touches just about everything it seems. that as many features as possible, in particular the broad-touching ones, should be in alpha 1. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] release plan for 2.5 ?
Phillip J. Eby [EMAIL PROTECTED] writes: At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote: PEP 343: The with Statement Didn't Michael Hudson have a patch? PEP 343's Accepted status was reverted to Draft in October, and then changed back to Accepted. I believe the latter change is an error, since you haven't pronounced on the changes. Have you reviewed the __context__ stuff that was added? In any case Michael's patch was pre-AST branch merge, and no longer reflects the current spec. It also never quite reflected the spec at the time, although I forget the detail it didn't support :/ Cheers, mwh -- 81. In computing, turning the obvious into the useful is a living definition of the word frustration. -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html ___ 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] release plan for 2.5 ?
Guido van Rossum wrote: Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. I am not experienced in releasing, but with the multitude of new things introduced in Python 2.5, could it be a good idea to release an early alpha not long after all (most of?) the desired features are in the trunk? That way people would get to testing sooner and the number of non-obvious bugs may be reduced (I'm thinking of the import PEP, the implementation of which is bound to be hairy, or with in its full extent). Georg ___ 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] release plan for 2.5 ?
Guido van Rossum wrote: - setuplib? Wouldn't it make sense to add this to the 2.5 stdlib? If you mean setuptools, I'm a big +1 (if it's production-ready by that time). Together with a whipped up cheese shop we should finally be able to put up something equal to cpan/rubygems. Georg ___ 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] release plan for 2.5 ?
Guido van Rossum wrote: PEP 338 - support -m for modules in packages. I believe Nick Coghlan is close to implementing this. I'm fine with accepting it. I just checked in a new version of PEP 338 that cleans up the approach so that it provides support for any PEP 302 compliant packaging mechanism as well as normal filesystem packages. I've started a new thread for the discussion: PEP 338 - Executing Modules as Scripts Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --- http://www.boredomandlaziness.org ___ 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] release plan for 2.5 ?
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 I think this is very reasonable. Based on Martin's message and if we can get everyone fired up and implementing, it would possible to start in April. I'll update the PEP for starting in May now. We can revise further later. ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. I think PyCon is too early, but 3 alphas is a good idea. I'll add this as well. Probably separated by 3-4 weeks so it doesn't change the schedule much. The exact schedule will still changed based on release manager availability and other stuff that needs to be implemented. PEP 353: Using ssize_t as the index type Neal tells me that this is in progress in a branch, but that the code is not yet flawless (tons of warnings etc.). Martin, can you tell us more? When do you expect this to land? Maybe aggressively merging into the HEAD and then releasing it as alpha would be a good way to shake out the final issues??? I'm tempted to say we should merge now. I know the branch works on 64-bit boxes. I can test on a 32-bit box if Martin hasn't already. There will be a lot of churn fixing problems, but maybe we can get more people involved. n ___ 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] release plan for 2.5 ?
On 2/10/06, Georg Brandl [EMAIL PROTECTED] wrote: I am not experienced in releasing, but with the multitude of new things introduced in Python 2.5, could it be a good idea to release an early alpha not long after all (most of?) the desired features are in the trunk? In the past, all new features had to be in before beta 1 IIRC (it could have been beta 2 though). The goal is to get things in sooner, preferably prior to alpha. For 2.5, we should strive really hard to get features implemented prior to alpha 1. Some of the changes (AST, ssize_t) are pervasive. AST while localized, ripped the guts out of something every script needs (more or less). ssize_t touches just about everything it seems. n ___ 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] release plan for 2.5 ?
On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 2/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote: It looks like we need a Python 2.5 Release Schedule PEP. Very draft: http://www.python.org/peps/pep-0356.html Needs lots of work and release managers. Anthony, Martin, Fred, Sean are all mentioned with TBDs and question marks. Before he went off to a boondoggle^Woff-site at a Mexican resort, Neal made me promise that I'd look at this and try to get the 2.5 release plan going for real. First things first: we need a release manager. Anthony, do you want to do the honors again, or are you ready for retirement? Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. There's a bunch of sections (some very long) towards the end of the PEP of questionable use; Neal just copied these from the 2.4 release schedule (PEP 320): - Ongoing tasks - Carryover features from Python 2.4 - Carryover features from Python 2.3 (!) Can someone go over these and suggest which we should keep, which we should drop? (I may do this later, but I have other priorities below.) Then, the list of features that ought to be in 2.5. Quoting Neal's draft: PEP 308: Conditional Expressions Definitely. Don't we have a volunteer doing this now? PEP 328: Absolute/Relative Imports Yes, please. PEP 343: The with Statement Didn't Michael Hudson have a patch? PEP 352: Required Superclass for Exceptions I believe this is pretty much non-controversial; it's a much weaker version of PEP 348 which was rightfully rejected for being too radical. I've tweaked some text in this PEP and approved it. Now we need to make it happen. It might be quite a tricky thing, since Exception is currently implemented in C as a classic class. If Brett wants to sprint on this at PyCon I'm there to help (Mon/Tue only). Fortunately we have MWH's patch 1104669 as a starting point. PEP 353: Using ssize_t as the index type Neal tells me that this is in progress in a branch, but that the code is not yet flawless (tons of warnings etc.). Martin, can you tell us more? When do you expect this to land? Maybe aggressively merging into the HEAD and then releasing it as alpha would be a good way to shake out the final issues??? Other PEPs I'd like comment on: PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't look like it'll cause any problems. PEP 314 (metadata v1.1): this is marked as completed, but there's a newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its target date. Shouldn't we implement it? (This is a topic that I haven't followed closely.) There's also the question whether 314 should be marked final. Andrew or Richard? PEP 355 (path module): I still haven't reviewed this, because I'm -0 on adding what appears to me duplicate functionality. But if there's a consensus building perhaps it should be allowed to go forward (and then I *will* review it carefully). I found a few more PEPs slated for 2.5 but that haven't seen much action lately: PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? PEP 349 - str() may return unicode. Where is this? I'm not at all sure the PEP is ready. it would probably be a lot of work to make this work everywhere in the C code, not to mention the stdlib .py code. Perhaps this should be targeted for 2.6 instead? The consequences seem potentially huge. PEP 315 - do while. A simple enough syntax proposal, albeit one introducing a new keyword (which I'm fine with). I kind of like it but it doesn't strike me as super important -- if we put this off until Py3k I'd be fine with that too. Opinions? Champions? Ouch, a grep produced tons more. Quick rundown: PEP 246 - adaptation. I'm still as lukewarm as ever; it needs interfaces, promises to cause a paradigm shift, and the global map worries me. PEP 323 - copyable iterators. Seems stalled. Alex, do you care? PEP 332 - byte vectors. Looks incomplete. Put off until 2.6? PEP 337 - logging in the stdlib. What of it? This seems a good idea but potentially disruptive (because backwards incompatible). Also it could be done piecemeal on an opportunistic basis. Any volunteers? PEP 338 - support -m for modules in packages. I believe Nick Coghlan is close to implementing this. I'm fine with accepting it. PEP 344 - exception chaining. There are deep problems with this due to
Re: [Python-Dev] release plan for 2.5 ?
[Guido van Rossum] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? It has at least one anti-champion. I think it is a horrible idea and would like to see it rejected in a way that brings finality. If needed, I can elaborate in a separate thread. PEP 315 - do while. A simple enough syntax proposal, albeit one introducing a new keyword (which I'm fine with). I kind of like it but it doesn't strike me as super important -- if we put this off until Py3k I'd be fine with that too. Opinions? Champions? I helped tweak a few issues with the PEP and got added as a co-author. I didn't push for it because the syntax is a little odd if nothing appears in the while suite: do: val = source.read(1) process(val) while val != lastitem: pass I never found a way to improve this. Dropping the final colon and post-while steps improved the looks but diverged too far away from the rest of the language: do: val = source.read(1) process(val) while val != lastitem So, unless another champion arises, putting this off until Py3k is fine with me. PEP 323 - copyable iterators. Seems stalled. Alex, do you care? I installed the underlying mechanism in support of itertools.tee() in Py2.4. So, if anyone really wants to make xrange() copyable, it is now a trivial task -- likewise for any other iterator that has a potentially copyable state. I've yet to find a use case for it, so I never pushed for the rest of the PEP to be implemented. There's nothing wrong with the idea, but there doesn't seem to be much interest. PEP 344 - exception chaining. There are deep problems with this due to circularities; perhaps we should drop this, or revisit it for Py3k. I wouldn't hold-up Py2.5 for this. My original idea for this was somewhat simpler. Essentially, a high-level function would concatenate extra string information onto the result of an exception raised at a lower level. That strategy was applied to an existing problem for type objects and has met with good success. IOW, there is a simpler alternative on the table, but resolution won't take place until we collectively take interest in it again. At this point, it seems to be low on everyone's priority list (including mine). 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] release plan for 2.5 ?
At 12:21 PM 2/10/2006 -0800, Guido van Rossum wrote: PEP 343: The with Statement Didn't Michael Hudson have a patch? PEP 343's Accepted status was reverted to Draft in October, and then changed back to Accepted. I believe the latter change is an error, since you haven't pronounced on the changes. Have you reviewed the __context__ stuff that was added? In any case Michael's patch was pre-AST branch merge, and no longer reflects the current spec. PEP 332 - byte vectors. Looks incomplete. Put off until 2.6? Wasn't the plan to just make this a builtin version of array.array for bytes, plus a .decode method and maybe a few other tweaks? We presumably won't be able to .encode() to bytes or get bytes from sockets and files until 3.0, but having the type and being able to write it to files and sockets would be nice. I'm not sure about the b syntax, ISTR it was controversial but I don't remember if there was a resolution. PEP 314 (metadata v1.1): this is marked as completed, but there's a newer PEP available: PEP 334 (metadata v1.2). That PEP has 2.5 as its target date. Shouldn't we implement it? (This is a topic that I haven't followed closely.) There's also the question whether 314 should be marked final. Andrew or Richard? I'm concerned that both metadata PEPs push to define syntax for things that have undefined semantics. And worse, to define incompatible syntax in some cases. PEP 345 for example, dictates the use of StrictVersion syntax for the required version of Python and the version of external requirements, but Python's own version numbers don't conform to strict version syntax. ISTM that the metadata standard needs more work, especially since PyPI doesn't actually support using all of the metadata provided by the implemented version of the standard. There's no way to search for requires/provides, for example (which is one reason why I went with distribution names for dependency resolution in setuptools). Also, the specs don't allow for a Maintainer distinct from the package Author, even though the distutils themselves allow this. IMO, 345 needs to go back to the drawing board, and I'm not really thrilled with the currently-useless requires/provides stuff in PEP 314. If we do anything with the package metadata in Python 2.5, I'd like it to be *installing* PKG-INFO files alongside the packages, using a filename of the form distributionname-version-py2.5.someext. Setuptools supports such files currently under the .egg-info extension, but I'd be just as happy with '.pkg-info' if it becomes a Python standard addition to the installation. Having this gives most of the benefits of PEP 262 (database of installed packages), although I wouldn't mind extending the PKG-INFO file format to include some of the PEP 262 additional data. These are probably distutils-sig and/or catalog-sig topics; I just mainly wanted to point out that 314, 245, and 262 need at least some tweaking and possibly rethinking before any push to implementation. ___ 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] release plan for 2.5 ?
On Fri, Feb 10, 2006 at 12:21:26PM -0800, Guido van Rossum wrote: ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. Well, PyCon might be a nice place to finish any PEP patches. I know I'll be available to do such work on the sprint days ;) I don't think that means we'll have a working repository with all 2.5 features right after, though. PEP 308: Conditional Expressions Definitely. Don't we have a volunteer doing this now? There is a volunteer, but he's new at this, so he probably needs a bit of time to work through the intricacies of the AST, the compiler and the eval loop. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] release plan for 2.5 ?
On 2/10/06, Phillip J. Eby [EMAIL PROTECTED] wrote: I'm not following up to anything that Phillip wrote (yet), but his response reminded me of two more issues: - wsgiref, an implementation of PEP 333 (Web Standard Gateway interface). I think this might make a good addition to the standard library. The web-sig has been discussing additional things that might be proposed for addition but I believe there's no consensus -- in any case we ought to be conservative. - setuplib? Wouldn't it make sense to add this to the 2.5 stdlib? -- --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] release plan for 2.5 ?
On Feb 10, 2006, at 3:21 PM, Guido van Rossum wrote: PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? I have no interest in it any longer, and wouldn't shed a tear if it were rejected. One other un-PEP'd thing. I'd like to put email 3.1 in Python 2.5 with the new module naming scheme. The old names will still work, and all the unit tests pass. Do we need a PEP for that? -Barry ___ 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] release plan for 2.5 ?
Guido van Rossum wrote: PEP 328: Absolute/Relative Imports Yes, please. +0 for adding relative imports. -1 for raising errors for in-package relative imports using the current notation in Python 2.6. See: http://mail.python.org/pipermail/python-dev/2004-September/048695.html for a previous discussion. The PEP still doesn't have any mention of the above discussion or later follow-ups. The main argument is that the strategy to make absolute imports mandatory and offer relative imports as work-around breaks the possibility to produce packages that work in e.g. Python 2.4 and 2.6, simply because Python 2.4 doesn't support the needed relative import syntax. The only strategy left would be to use absolute imports throughout, which isn't all that bad, except when it comes to relocating a package or moving a set of misc. modules into a package - which is not all that uncommon in larger projects, e.g. to group third-party top-level modules into a package to prevent cluttering up the top-level namespace or to simply make a clear distinction in your code that you are relying on a third-party module, e.g from thirdparty import tool I don't mind having to deal with a warning for these, but don't want to see this raise an error before Py3k. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Feb 10 2006) Python/Zope Consulting and Support ...http://www.egenix.com/ mxODBC.Zope.Database.Adapter ... http://zope.egenix.com/ mxODBC, mxDateTime, mxTextTools ...http://python.egenix.com/ ::: Try mxODBC.Zope.DA for Windows,Linux,Solaris,FreeBSD for free ! ___ 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] release plan for 2.5 ?
On Fri, Feb 10, 2006 at 11:06:24PM +0100, M.-A. Lemburg wrote: Guido van Rossum wrote: PEP 328: Absolute/Relative Imports Yes, please. +0 for adding relative imports. -1 for raising errors for in-package relative imports using the current notation in Python 2.6. +1/-1 for me. Being able to explicitly demand relative imports is good, breaking things soon bad. I'll happily shoehorn this in at the sprints after PyCon ;) -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] release plan for 2.5 ?
On 2/10/06, Thomas Wouters [EMAIL PROTECTED] wrote: On Fri, Feb 10, 2006 at 11:06:24PM +0100, M.-A. Lemburg wrote: Guido van Rossum wrote: PEP 328: Absolute/Relative Imports Yes, please. +0 for adding relative imports. -1 for raising errors for in-package relative imports using the current notation in Python 2.6. +1/-1 for me. Being able to explicitly demand relative imports is good, breaking things soon bad. I'll happily shoehorn this in at the sprints after PyCon ;) The PEP has the following timeline (my interpretation): 2.4: implement new behavior with from __future__ import absolute_import 2.5: deprecate old-style relative import unless future statement present 2.6: disable old-style relative import, future statement no longer necessary Since it wasn't implemented in 2.4, I think all these should be bumped by one release. Aahz, since you own the PEP, can you do that (and make any other updates that might result)? -- --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] release plan for 2.5 ?
[Barry Warsaw]like to put email 3.1 in Python 2.5 with the new module naming scheme. The old names will still work, and all the unit tests pass. Do we need a PEP for that? +1 ___ 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] release plan for 2.5 ?
On 2/10/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Barry Warsaw]like to put email 3.1 in Python 2.5 with the new module naming scheme. The old names will still work, and all the unit tests pass. Do we need a PEP for that? +1 I don't know if Raymond meant we need a PEP or go ahead with the feature but my own feeling is that this doesn't need a PEP and Barry can Just Do It. -- --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] release plan for 2.5 ?
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: ... Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: October would seem to me to be just about right. I don't see that one month either way should make any big difference, though. ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. If I could have a definitive frozen list of features by the first week of April at the latest, that could make it (as a 2.5 preview) into the 2nd edition of Python in a Nutshell. But since alphas are not feature-frozen, it wouldn't make much of a difference to me, I think. Other PEPs I'd like comment on: PEP 357 (__index__): the patch isn't on SF yet, but otherwise I'm all for this, and I'd like to accept it ASAP to get it in 2.5. It doesn't look like it'll cause any problems. It does look great, and by whatever name I support it most heartily. Do, however, notice that it's yet another specialpurpose adaptation protocol and that such specific restricted solutions to the general problem, with all of their issues, will just keep piling up forever (and need legacy support ditto) until and unless your temperature wrt 246 (or any variation thereof) should change. PEP 355 (path module): I still haven't reviewed this, because I'm -0 on adding what appears to me duplicate functionality. But if there's a I feel definitely -0 towards it too. PEP 315 - do while. A simple enough syntax proposal, albeit one introducing a new keyword (which I'm fine with). I kind of like it but it doesn't strike me as super important -- if we put this off until Py3k I'd be fine with that too. Opinions? Champions? Another -0 from me. I suggest we shelve it for now and revisit in 3k (maybe PEPs in that state, not in any 2.* but revisit for 3.0, need a special status value). PEP 246 - adaptation. I'm still as lukewarm as ever; it needs interfaces, promises to cause a paradigm shift, and the global map worries me. Doesn't _need_ interfaces as a concept -- any unique markers as protocol names would do, even strings, although obviously the stronger the markers the better (classes/types for example would be just perfect). It was written on the assumption of interfaces just because they were being proposed just before it. The key paradigm shift is to offer a way to unify what's already being widely done, in haphazard and dispersed manners. And I'll be quite happy to rewrite it in terms of a more nuanced hierarchy of maps (e.g. builtin / per-module / lexically nested, or whatever) if that's what it takes to warm you to it -- I just think it would be over-engineering it, since in practice the global-on-all-modules map would cover by far most usage (both for blessed protocols that come with Python, and for the use of third party adapting framework A to consume stuff that framework B produces, global is the natural residence; other uses are far less important. PEP 323 - copyable iterators. Seems stalled. Alex, do you care? Sure, I'd like to make this happen, particularly since Raymond appears to have already done the hard part. What would you like to see happening to bless it for 2.5? PEP 332 - byte vectors. Looks incomplete. Put off until 2.6? Ditto -- I'd like at least SOME of it to be in 2.5. What needs to happen for that? Alex ___ 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] release plan for 2.5 ?
On Fri, Feb 10, 2006 at 02:45:54PM -0800, Guido van Rossum wrote: The PEP has the following timeline (my interpretation): 2.4: implement new behavior with from __future__ import absolute_import 2.5: deprecate old-style relative import unless future statement present 2.6: disable old-style relative import, future statement no longer necessary Since it wasn't implemented in 2.4, I think all these should be bumped by one release. Aahz, since you own the PEP, can you do that (and make any other updates that might result)? Bumping is fine (of course), but I'd like a short discussion on the actual disabling before it happens (rather than the disabling happening without anyone noticing until beta2.) There seem to be a lot of users still using 2.3, at the moment, in spite of its age. Hopefully, by the time 2.7 comes out, everyone will have switched to 2.5, but if not, it could still be a major annoyance to conscientious module-writers, like MAL. -- Thomas Wouters [EMAIL PROTECTED] Hi! I'm a .signature virus! copy me into your .signature file to help me spread! ___ 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] release plan for 2.5 ?
On 2/10/06, Guido van Rossum [EMAIL PROTECTED] wrote: On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 2/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote: It looks like we need a Python 2.5 Release Schedule PEP. Very draft: http://www.python.org/peps/pep-0356.html Needs lots of work and release managers. Anthony, Martin, Fred, Sean are all mentioned with TBDs and question marks. Before he went off to a boondoggle^Woff-site at a Mexican resort, Neal made me promise that I'd look at this and try to get the 2.5 release plan going for real. First things first: we need a release manager. Anthony, do you want to do the honors again, or are you ready for retirement? Next, the schedule. Neal's draft of the schedule has us releasing 2.5 in October. That feels late -- nearly two years after 2.4 (which was released on Nov 30, 2004). Do people think it's reasonable to strive for a more aggressive (by a month) schedule, like this: alpha 1: May 2006 alpha 2: June 2006 beta 1: July 2006 beta 2: August 2006 rc 1:September 2006 final: September 2006 ??? Would anyone want to be even more aggressive (e.g. alpha 1 right after PyCon???). We could always do three alphas. I think that schedule is fine, but going alpha after PyCon is too fast with the number of PEPs that need implementing. [SNIP] PEP 352: Required Superclass for Exceptions I believe this is pretty much non-controversial; it's a much weaker version of PEP 348 which was rightfully rejected for being too radical. I've tweaked some text in this PEP and approved it. Now we need to make it happen. It might be quite a tricky thing, since Exception is currently implemented in C as a classic class. If Brett wants to sprint on this at PyCon I'm there to help (Mon/Tue only). Fortunately we have MWH's patch 1104669 as a starting point. I might sprint on it. It's either this or I will work on the AST stuff (the PyObject branch is still not finishd and thus it has not been finalized if that solution or the way it is now will be the final way of implementing the compiler and I would like to see this settled). Either way I take responsibility to make sure the PEP gets implemented so you can take that question off of the schedule PEP. [SNIP] PEP 351 - freeze protocol. I'm personally -1; I don't like the idea of freezing arbitrary mutable data structures. Are there champions who want to argue this? If Barry doesn't even care anymore I say kill it. [SNIP] PEP 315 - do while. A simple enough syntax proposal, albeit one introducing a new keyword (which I'm fine with). I kind of like it but it doesn't strike me as super important -- if we put this off until Py3k I'd be fine with that too. Opinions? Champions? Eh, seems okay but I am not jumping up and down for it. Waiting until Python 3 is fine with me if a discussion is warranted (don't really remember it coming up before). [SNIP] PEP 332 - byte vectors. Looks incomplete. Put off until 2.6? I say put off. This could be discussed at PyCon since this might be an important type to get right. [SNIP] PEP 344 - exception chaining. There are deep problems with this due to circularities; perhaps we should drop this, or revisit it for Py3k. I say revisit issues later. Raymond says he has an idea for chaining just the messages which could be enough help for developers. But either way I don't think this has been hashed out enough to go in as-is. I suspect a simpler solution will work, such as ditching the traceback and only keeping either the text that would have been printed or just the exception instance (and thus also its message). -Brett ___ 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] release plan for 2.5 ?
On Feb 10, 2006, at 5:47 PM, Guido van Rossum wrote: On 2/10/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Barry Warsaw]like to put email 3.1 in Python 2.5 with the new module naming scheme. The old names will still work, and all the unit tests pass. Do we need a PEP for that? +1 I don't know if Raymond meant we need a PEP or go ahead with the feature but my own feeling is that this doesn't need a PEP and Barry can Just Do It. I was going to ask the same thing. :) Cool. So far there have been no objections on the email-sig, so I'll try to move the sandbox to the trunk this weekend. That should give us plenty of time to shake out any nastiness. -Barry ___ 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] release plan for 2.5 ?
Just do it. - Original Message - From: Guido van Rossum [EMAIL PROTECTED] To: Raymond Hettinger [EMAIL PROTECTED] Cc: Barry Warsaw [EMAIL PROTECTED]; python-dev@python.org Sent: Friday, February 10, 2006 5:47 PM Subject: Re: [Python-Dev] release plan for 2.5 ? On 2/10/06, Raymond Hettinger [EMAIL PROTECTED] wrote: [Barry Warsaw]like to put email 3.1 in Python 2.5 with the new module naming scheme. The old names will still work, and all the unit tests pass. Do we need a PEP for that? +1 I don't know if Raymond meant we need a PEP or go ahead with the feature but my own feeling is that this doesn't need a PEP and Barry can Just Do It. -- --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] release plan for 2.5 ?
Guido van Rossum [EMAIL PROTECTED] wrote: PEP 349 - str() may return unicode. Where is this? Does that mean you didn't find and read the PEP or was it written so badly that it answered none of your questions? The PEP is on python.org with all the rest. I set the status to Deferred because it seemed that no one was interested in the change. I'm not at all sure the PEP is ready. it would probably be a lot of work to make this work everywhere in the C code, not to mention the stdlib .py code. Perhaps this should be targeted for 2.6 instead? The consequences seem potentially huge. The backwards compatibility problems *seem* to be relatively minor. I only found one instance of breakage in the standard library. Note that my patch does not change PyObject_Str(); that would break massive amounts of code. Instead, I introduce a new function: PyString_New(). I'm not crazy about the name but I couldn't think of anything better. Neil ___ 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] release plan for 2.5 ?
On 2/10/06, Neil Schemenauer [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: PEP 349 - str() may return unicode. Where is this? Does that mean you didn't find and read the PEP or was it written so badly that it answered none of your questions? The PEP is on python.org with all the rest. I set the status to Deferred because it seemed that no one was interested in the change. Sorry -- it was an awkward way to ask what's the status? You've answered that. I'm not at all sure the PEP is ready. it would probably be a lot of work to make this work everywhere in the C code, not to mention the stdlib .py code. Perhaps this should be targeted for 2.6 instead? The consequences seem potentially huge. The backwards compatibility problems *seem* to be relatively minor. I only found one instance of breakage in the standard library. Note that my patch does not change PyObject_Str(); that would break massive amounts of code. Instead, I introduce a new function: PyString_New(). I'm not crazy about the name but I couldn't think of anything better. So let's think about this more post 2.5. -- --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] release plan for 2.5 ?
On Sat, 11 Feb 2006 05:08:09 + (UTC), Neil Schemenauer [EMAIL PROTECTED] wrote: Guido van Rossum [EMAIL PROTECTED] wrote: PEP 349 - str() may return unicode. Where is this? Does that mean you didn't find and read the PEP or was it written so badly that it answered none of your questions? The PEP is on python.org with all the rest. I set the status to Deferred because it seemed that no one was interested in the change. I'm not at all sure the PEP is ready. it would probably be a lot of work to make this work everywhere in the C code, not to mention the stdlib .py code. Perhaps this should be targeted for 2.6 instead? The consequences seem potentially huge. The backwards compatibility problems *seem* to be relatively minor. I only found one instance of breakage in the standard library. Note that my patch does not change PyObject_Str(); that would break massive amounts of code. Instead, I introduce a new function: PyString_New(). I'm not crazy about the name but I couldn't think of anything better. Should this not be coordinated with PEP 332? Regards, Bengt Richter ___ 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] release plan for 2.5 ?
On Sat, 11 Feb 2006 05:08:09 + (UTC), Neil Schemenauer [EMAIL PROTECTED] The backwards compatibility problems *seem* to be relatively minor. I only found one instance of breakage in the standard library. Note that my patch does not change PyObject_Str(); that would break massive amounts of code. Instead, I introduce a new function: PyString_New(). I'm not crazy about the name but I couldn't think of anything better. On 2/10/06, Bengt Richter [EMAIL PROTECTED] wrote: Should this not be coordinated with PEP 332? Probably.. But that PEP is rather incomplete. Wanna work on fixing that? -- --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] release plan for 2.5 ?
On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote: what's the current release plan for Python 2.5, btw? I cannot find a relevant PEP, and the what's new says late 2005: but I don't think that anyone followed up on this. what's the current status ? Guido and I had a brief discussion about this. IIRC, he was thinking alpha around March and release around summer. I think this is aggressive with all the things still to do. We really need to get the ssize_t branch integrated. There are a bunch of PEPs that have been accepted (or close), but not implemented. I think these include (please correct me, so we can get a good list): http://www.python.org/peps/ SA 308 Conditional Expressions SA 328 Imports: Multi-Line and Absolute/Relative SA 342 Coroutines via Enhanced Generators S 343 The with Statement S 353 Using ssize_t as the index type This one should be marked as final I believe: SA 341 Unifying try-except and try-finally n ___ 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] release plan for 2.5 ?
It looks like we need a Python 2.5 Release Schedule PEP. Jeremy On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote: what's the current release plan for Python 2.5, btw? I cannot find a relevant PEP, and the what's new says late 2005: but I don't think that anyone followed up on this. what's the current status ? Guido and I had a brief discussion about this. IIRC, he was thinking alpha around March and release around summer. I think this is aggressive with all the things still to do. We really need to get the ssize_t branch integrated. There are a bunch of PEPs that have been accepted (or close), but not implemented. I think these include (please correct me, so we can get a good list): http://www.python.org/peps/ SA 308 Conditional Expressions SA 328 Imports: Multi-Line and Absolute/Relative SA 342 Coroutines via Enhanced Generators S 343 The with Statement S 353 Using ssize_t as the index type This one should be marked as final I believe: SA 341 Unifying try-except and try-finally n ___ 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/jeremy%40alum.mit.edu ___ 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] release plan for 2.5 ?
On 2/7/06, Neal Norwitz [EMAIL PROTECTED] wrote: On 2/7/06, Fredrik Lundh [EMAIL PROTECTED] wrote: what's the current release plan for Python 2.5, btw? I cannot find a relevant PEP, and the what's new says late 2005: but I don't think that anyone followed up on this. what's the current status ? Guido and I had a brief discussion about this. IIRC, he was thinking alpha around March and release around summer. I think this is aggressive with all the things still to do. We really need to get the ssize_t branch integrated. There are a bunch of PEPs that have been accepted (or close), but not implemented. I think these include (please correct me, so we can get a good list): http://www.python.org/peps/ SA 308 Conditional Expressions SA 328 Imports: Multi-Line and Absolute/Relative SA 342 Coroutines via Enhanced Generators S 343 The with Statement S 353 Using ssize_t as the index type This one should be marked as final I believe: SA 341 Unifying try-except and try-finally Supposedly Guido is close on pronouncing on PEP 352 (Required Superclass for Exceptions), or so he said last time that thread came about. -Brett ___ 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] release plan for 2.5 ?
On 2/7/06, Jeremy Hylton [EMAIL PROTECTED] wrote: It looks like we need a Python 2.5 Release Schedule PEP. Very draft: http://www.python.org/peps/pep-0356.html Needs lots of work and release managers. Anthony, Martin, Fred, Sean are all mentioned with TBDs and question marks. n ___ 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
