Re: [Python-Dev] no remaining issues blocking 2.5 release
Did you still want this addressed? Anthony and I made some comments on the bug/patch, but nothing has been updated. I was waiting because I got unassigned from the bug, so I thought the maintainer was stepping up. I'll commit a fix for it today. Thanks for pinging me, -- Gustavo Niemeyer http://niemeyer.net ___ 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] no remaining issues blocking 2.5 release
Gustavo, Did you still want this addressed? Anthony and I made some comments on the bug/patch, but nothing has been updated. n -- On 8/15/06, Gustavo Niemeyer [EMAIL PROTECTED] wrote: If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. I'd like to see problem #1531862 fixed. The bug is clear and the fix should be trivial. I can commit a fix tonight, if the subprocess module author/maintainer is unavailable to check it out. -- Gustavo Niemeyer http://niemeyer.net ___ 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] no remaining issues blocking 2.5 release
On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote:
It would be nice if someone could bytecompile Lib using
Tools/compiler/compile.py and then run the test suite. I'd do it
myself but can't spare the time at the moment (I started but ran
into what seems to be a gcc bug along the way).
Has this been done before?
# This code causes python to segfault
def foo(S):
all(x 42 for x in S)
# around Python/ceval.c 2167: x = (*v-ob_type-tp_iternext)(v);
# tp_iternext is NULL
I added the changes below to Lib/compiler/pycodegen.py which are
clearly wrong. It just crashes in a diff place. I think the changes
to genxpr inner may be close to correct. The changes to _makeClosure
and visitGenExpr are clearly wrong. I was just wondering how far it
would go. There are a bunch of differences. Some are the bytecode
optimizations or different ordering, but others are things dealing
with co_names, co_varnames.
Hopefully someone has time to look into this. Otherwise, it will have
to wait for 2.5.1
n
--
Index: Lib/compiler/pycodegen.py
===
--- Lib/compiler/pycodegen.py (revision 51305)
+++ Lib/compiler/pycodegen.py (working copy)
@@ -628,9 +628,9 @@
self.newBlock()
self.emit('POP_TOP')
-def _makeClosure(self, gen, args):
+def _makeClosure(self, gen, args, gen_outer=False):
frees = gen.scope.get_free_vars()
-if frees:
+if frees and not gen_outer:
for name in frees:
self.emit('LOAD_CLOSURE', name)
self.emit('BUILD_TUPLE', len(frees))
@@ -646,7 +646,7 @@
walk(node.code, gen)
gen.finish()
self.set_lineno(node)
-self._makeClosure(gen, 0)
+self._makeClosure(gen, 0, True)
# precomputation of outmost iterable
self.visit(node.code.quals[0].iter)
self.emit('GET_ITER')
@@ -655,6 +655,11 @@
def visitGenExprInner(self, node):
self.set_lineno(node)
# setup list
+after = self.newBlock()
+start = self.newBlock()
+self.setups.push((LOOP, start))
+self.emit('SETUP_LOOP', after)
+self.nextBlock(start)
stack = []
for i, for_ in zip(range(len(node.quals)), node.quals):
@@ -676,8 +681,12 @@
self.startBlock(cont)
self.emit('POP_TOP')
self.nextBlock(skip_one)
+self.emit('POP_TOP')
self.emit('JUMP_ABSOLUTE', start)
self.startBlock(anchor)
+self.emit('POP_BLOCK')
+self.setups.pop()
+self.nextBlock(after)
self.emit('LOAD_CONST', None)
def visitGenExprFor(self, node):
___
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] no remaining issues blocking 2.5 release
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote: It would be nice if the key IDLE changes could make it to the What's New in Python X.X. If Andrew is interested, I could draft something for him. Sure! I can try to look through the IDLE NEWS file, but you'd certainly have a better idea of which changes are most significant to IDLE users. (You can commit your changes to whatsnew25.tex, module Anthony's trunk freeze in 12 hours or so, or just write plain text and let me add the LaTeX markup.) --amk ___ 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] no remaining issues blocking 2.5 release
Neal Norwitz [EMAIL PROTECTED] wrote: On 8/15/06, Neil Schemenauer [EMAIL PROTECTED] wrote: It would be nice if someone could bytecompile Lib using Tools/compiler/compile.py and then run the test suite. Has this been done before? Obviously not. :-) # This code causes python to segfault def foo(S): all(x 42 for x in S) Hmm, it seems to work for me. The bytecode generated by Lib/compiler is the same as the normal compiler. Do you have a full test case? 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] no remaining issues blocking 2.5 release
A.M. Kuchling [EMAIL PROTECTED] writes:
On Tue, Aug 15, 2006 at 10:44:40PM -0400, Kurt B. Kaiser wrote:
It would be nice if the key IDLE changes could make it to the What's New
in Python X.X. If Andrew is interested, I could draft something for him.
Sure! I can try to look through the IDLE NEWS file, but you'd
certainly have a better idea of which changes are most significant to
IDLE users.
(You can commit your changes to whatsnew25.tex, module Anthony's trunk
freeze in 12 hours or so, or just write plain text and let me add the
LaTeX markup.)
%=
\subsection{The IDLE Integrated Development Environment}
Calltips have been greatly improved and a class attribute listbox
provides completions.
When the Shell cursor is on a previous command, Enter retrieves
that command. But instead of replacing the input line, the previous
command is appended, preserving indentation. If there is an active
selection, the selection will be appended to the input line.
IDLE does a tabnanny and syntax check before every F5/Run.
A number of changes were made to improve Mac OSX compatibility.
The advanced keybinding dialog was enabled, allowing multiple
complex key combinations to be bound to a given IDLE event.
A number of improvements were made to the colorizer.
The 'with' statement is now a Code Context block opener.
IDLE honors the new quit() and exit() functions.
Keybindings were added for del-word-left and del-word-right.
%
--
KBK
___
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] no remaining issues blocking 2.5 release
Neal Norwitz schrieb: I just updated the PEP to remove all references to issues blocking release of 2.5. I don't know of any. I haven't heard of any issues with the fixes that have been checked in. If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. What is the policy for documentation changes? Am I allowed to check in changes/additions to the ctypes docs without release manager permission after the release candidate is out? I'l always make sure that the html docs can be built. Thanks, Thomas ___ 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] no remaining issues blocking 2.5 release
Guido van Rossum wrote: On 8/15/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: The distutils version number should be changed back to a static string literal. It's currently setup to get its version number from the Python version running it which pretty much defeats the whole purpose of having a version number and makes using the SVN distutils package with other Python versions problematic. I am sympathetic to this case. Is there any advantage to the *users* of distutils of the dynamic version number? If it's only done for the benefit of the release managers (with whose plight I also sympathesize) FWIW, I've already volunteered to do the version bumping to take that burden off the release managers. I think it must be rolled back, at least as long as distutils is officially listed as a package that needs to support older versions of Python, which pretty much implies that it's okay to extract it from the 2.5 release and distribute it separately for use with older Python versions. Well, that's another point we should discuss after 2.5 is out the door: distutils was delisted from PEP 291 (without public discussion). I find it important to maintain distutils compatibility with a few Python versions back. Even if I can't volunteer to maintain distutils, like Martin suggested, due to lack of time, I don't really see the requirement to use the latest and greatest Python features in distutils, so preserving compatibility with the commonly used Python versions wouldn't hurt. It makes the life of Python extension writers a tad easier and Python users benefit as a result of being able to download pre-built binaries without being forced to upgrade (this is esp. true for Python users on Windows). Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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] no remaining issues blocking 2.5 release
Guido van Rossum schrieb: I am sympathetic to this case. Is there any advantage to the *users* of distutils of the dynamic version number? This series of commits was triggered by a user who wondered why Python 2.4.3 ships with distutils 2.4.1, yet Python 2.5bsomething ships with the older 2.4.0; he requested that the newer release of distutils should be included in Python 2.5. So the advantage to the user is that the distutils version numbers become less confusing, and more correct (as long as the packaged distutils is used). If it's only done for the benefit of the release managers (with whose plight I also sympathesize) In principle, the release manager shouldn't be the one updating the distutils release number. Instead, whoever modifies distutils needs to decide whether this change is a bug fix (subminor change) or feature change (minor number changes). I think it must be rolled back, at least as long as distutils is officially listed as a package that needs to support older versions of Python, which pretty much implies that it's okay to extract it from the 2.5 release and distribute it separately for use with older Python versions. See, it isn't listed as such anymore, not since AMK removed it from PEP 291. That said, I'm not terribly opposed to it being changed back (*) - but *I* won't change it back (having it changed already twice in two days). I just wish I could then delegate all bug reports distutils doesn't work with older Python releases to MAL. As far as I'm concerned, this isn't a distutils feature anymore. Regards, Martin (*) where back means 2.5.0, not 2.4.0. ___ 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] no remaining issues blocking 2.5 release
M.-A. Lemburg schrieb: I find it important to maintain distutils compatibility with a few Python versions back. Even if I can't volunteer to maintain distutils, like Martin suggested, due to lack of time, I don't really see the requirement to use the latest and greatest Python features in distutils, so preserving compatibility with the commonly used Python versions wouldn't hurt. Actually, it would. bdist_msi uses extension modules which are only available in 2.5. Keeping support for the compiler-recognizing code in msvccompiler also hurts. It's either an official feature, with somebody maintaining it, or people should expect to break it anytime. 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] no remaining issues blocking 2.5 release
Martin v. Löwis wrote: Guido van Rossum schrieb: I think it must be rolled back, at least as long as distutils is officially listed as a package that needs to support older versions of Python, which pretty much implies that it's okay to extract it from the 2.5 release and distribute it separately for use with older Python versions. See, it isn't listed as such anymore, not since AMK removed it from PEP 291. That said, I'm not terribly opposed to it being changed back (*) - but *I* won't change it back (having it changed already twice in two days). I just wish I could then delegate all bug reports distutils doesn't work with older Python releases to MAL. As far as I'm concerned, this isn't a distutils feature anymore. How many of those are there ? We're running SVN distutils regularly for Python 2.4 and use the one that shipped with Python 2.3 (the last to support 1.5.2) for all versions between 1.5.2 and 2.3. We haven't hit any bugs related to distutils not being compatible to those Python versions anymore. The few I found over the years, I corrected directly in the repository. I just checked: SVN distutils (at least the parts that we use) still works with Python 2.2. It no longer works with Python 2.1 due to the use of True and probably a few other things. Regards, Martin (*) where back means 2.5.0, not 2.4.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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] no remaining issues blocking 2.5 release
Marc-Andre, I think the release managers might let you change this back if you volunteered, not to maintain all of distutils (I wouldn't wish that on my worst enemies :-) but at least to keep the version number up to date and to do the occasional work to keep it backwards compatible in the way you want it. I think it's fine of the new distutils contains new features that won't work with older Pythons, as long as the old features still work (and have perhaps updated functionality in some other way). How exactly to reconcile this with the black/white notion of PPE 291 I don't know; it seems a compromise is in order. --Guido On 8/15/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: Guido van Rossum schrieb: I think it must be rolled back, at least as long as distutils is officially listed as a package that needs to support older versions of Python, which pretty much implies that it's okay to extract it from the 2.5 release and distribute it separately for use with older Python versions. See, it isn't listed as such anymore, not since AMK removed it from PEP 291. That said, I'm not terribly opposed to it being changed back (*) - but *I* won't change it back (having it changed already twice in two days). I just wish I could then delegate all bug reports distutils doesn't work with older Python releases to MAL. As far as I'm concerned, this isn't a distutils feature anymore. How many of those are there ? We're running SVN distutils regularly for Python 2.4 and use the one that shipped with Python 2.3 (the last to support 1.5.2) for all versions between 1.5.2 and 2.3. We haven't hit any bugs related to distutils not being compatible to those Python versions anymore. The few I found over the years, I corrected directly in the repository. I just checked: SVN distutils (at least the parts that we use) still works with Python 2.2. It no longer works with Python 2.1 due to the use of True and probably a few other things. Regards, Martin (*) where back means 2.5.0, not 2.4.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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 ! -- --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] no remaining issues blocking 2.5 release
Martin v. Löwis wrote: M.-A. Lemburg schrieb: I find it important to maintain distutils compatibility with a few Python versions back. Even if I can't volunteer to maintain distutils, like Martin suggested, due to lack of time, I don't really see the requirement to use the latest and greatest Python features in distutils, so preserving compatibility with the commonly used Python versions wouldn't hurt. Actually, it would. bdist_msi uses extension modules which are only available in 2.5. bdist_msi is only a small part of distutils. While it would be great to have that distribution format for 2.3 and 2.4 as well, I don't think it's vital. It's simply a feature that is only available when using Python 2.5. Keeping support for the compiler-recognizing code in msvccompiler also hurts. I guess that's something to tell Microsoft ;-) However, I don't see that as argument for dropping the distutils support for Python versions prior to 2.5. It's either an official feature, with somebody maintaining it, or people should expect to break it anytime. I'll let you know when things break - is that good enough ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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] no remaining issues blocking 2.5 release
Guido van Rossum wrote: Marc-Andre, I think the release managers might let you change this back if you volunteered, not to maintain all of distutils (I wouldn't wish that on my worst enemies :-) but at least to keep the version number up to date and to do the occasional work to keep it backwards compatible in the way you want it. I guess it's Anthony's turn then... the patch is there and tested, just waiting in its shell window to get checked in ;-) I'll add a distutils checkin message filter to keep me informed of any changes to distutils. I think it's fine of the new distutils contains new features that won't work with older Pythons, as long as the old features still work (and have perhaps updated functionality in some other way). How exactly to reconcile this with the black/white notion of PPE 291 I don't know; it seems a compromise is in order. +1 --Guido On 8/15/06, M.-A. Lemburg [EMAIL PROTECTED] wrote: Martin v. Löwis wrote: Guido van Rossum schrieb: I think it must be rolled back, at least as long as distutils is officially listed as a package that needs to support older versions of Python, which pretty much implies that it's okay to extract it from the 2.5 release and distribute it separately for use with older Python versions. See, it isn't listed as such anymore, not since AMK removed it from PEP 291. That said, I'm not terribly opposed to it being changed back (*) - but *I* won't change it back (having it changed already twice in two days). I just wish I could then delegate all bug reports distutils doesn't work with older Python releases to MAL. As far as I'm concerned, this isn't a distutils feature anymore. How many of those are there ? We're running SVN distutils regularly for Python 2.4 and use the one that shipped with Python 2.3 (the last to support 1.5.2) for all versions between 1.5.2 and 2.3. We haven't hit any bugs related to distutils not being compatible to those Python versions anymore. The few I found over the years, I corrected directly in the repository. I just checked: SVN distutils (at least the parts that we use) still works with Python 2.2. It no longer works with Python 2.1 due to the use of True and probably a few other things. Regards, Martin (*) where back means 2.5.0, not 2.4.0. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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 ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 15 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] no remaining issues blocking 2.5 release
If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. I'd like to see problem #1531862 fixed. The bug is clear and the fix should be trivial. I can commit a fix tonight, if the subprocess module author/maintainer is unavailable to check it out. -- Gustavo Niemeyer http://niemeyer.net ___ 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] no remaining issues blocking 2.5 release
M.-A. Lemburg schrieb: It's either an official feature, with somebody maintaining it, or people should expect to break it anytime. I'll let you know when things break - is that good enough ? That can't be an official policy; you seem to define breaks as breaks in my (your) personal usage of distutils. While this is fine as an end-user point of view, it isn't useful as a maintenance guideline. In case you don't see what I mean: I said that something is already broken (bdist_msi), where broken means doesn't work, and you said it's only a small part. So if it's fine that only small parts break, I wonder where this gets us over time. For another example, you found that 2.1 compatibility is now broken (due to usage of True and False). When distutils was still listed in PEP 291, 2.1 compatibility was mentioned as a goal. Now, it doesn't seem to bother you very much that 2.1 compatibility is gone. 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] no remaining issues blocking 2.5 release
Martin v. Löwis wrote: M.-A. Lemburg schrieb: It's either an official feature, with somebody maintaining it, or people should expect to break it anytime. I'll let you know when things break - is that good enough ? That can't be an official policy; you seem to define breaks as breaks in my (your) personal usage of distutils. While this is fine as an end-user point of view, it isn't useful as a maintenance guideline. It's all I can offer. We do use quite a few distutils features and also extend it in various ways, so I suppose that our build system covers quite a bit of what distutils has to offer. Think of it as a test-bot that runs a real-life test on the distutils code. In case you don't see what I mean: I said that something is already broken (bdist_msi), where broken means doesn't work, and you said it's only a small part. So if it's fine that only small parts break, I wonder where this gets us over time. distutils is composed of many components. bdist_msi is one of them. Because it's new it can hardly break distutils in any way because it's a feature that didn't exist in the distutils version shipped with Python prior to 2.5. As a result, that distribution format cannot be used with older Python versions, but the rest of distutils continues to work as usual. I wouldn't call that breakage of distutils. It's just a feature that has external requirements, much like you can't run bdist_rpm without having the RPM tool installed. In general, if you have to rely on new features in Python such as extension modules which are not available in older Python versions, then that's fine - but again, if not really necessary, I'd rather see an approach being used that also works with older Python versions. What I do consider breakage, is if you use Python 2.5 features just to beef up some part of distutils core code. For another example, you found that 2.1 compatibility is now broken (due to usage of True and False). When distutils was still listed in PEP 291, 2.1 compatibility was mentioned as a goal. Now, it doesn't seem to bother you very much that 2.1 compatibility is gone. Actually, it does bother me, but I understand that not many people use Python 2.1 anymore, so don't insist keeping that version requirement. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Aug 16 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] no remaining issues blocking 2.5 release
Neal Norwitz [EMAIL PROTECTED] wrote: I don't know of any. I haven't heard of any issues with the fixes that have been checked in. It would be nice if someone could bytecompile Lib using Tools/compiler/compile.py and then run the test suite. I'd do it myself but can't spare the time at the moment (I started but ran into what seems to be a gcc bug along the way). 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] no remaining issues blocking 2.5 release
I really don't care any more about this. My initial concern (and why I requested the change) was that there are no more official separate distutils releases. I don't see how keeping a bunch of version numbers in the stdlib that just track the main version number is a sane use of developer time - particularly when it's only being used for someone's private releases. If you're cutting releases out of the stdlib, it seems to me that the maintenance load should be on you (where 'you' is 'anyone doing something like this', not MAL specifically wink) I'd also like to see idle's separate version number go away and have it start using the Python version number - maybe as of 2.6? This would then also mean we could pull idle's separate NEWS file into the master NEWS file. Right now, the release notes on the webpage miss all IDLE release notes, since it's just the main NEWS file. Since it's provoked so many complaints, change it back if you want. I won't be bothering to check that it's correct from now on, nor will I be updating it. Any user complaints will be ignored, and an incorrect version number will not be considered a reason for a bugfix release. Anthony ___ 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] no remaining issues blocking 2.5 release
On Tuesday 15 August 2006 22:57, Thomas Heller wrote: What is the policy for documentation changes? Am I allowed to check in changes/additions to the ctypes docs without release manager permission after the release candidate is out? I'l always make sure that the html docs can be built. So long as you don't break anything, doc changes are fine. Remember that post RC1 you'll need to checkin to both release25-maint and trunk. 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] no remaining issues blocking 2.5 release
Anthony Baxter [EMAIL PROTECTED] writes: I'd also like to see idle's separate version number go away and have it start using the Python version number - maybe as of 2.6? +1 When we merged IDLEfork the consensus was to keep the versioning separate. But it seems confusing and is extra work for the release managers. This would then also mean we could pull idle's separate NEWS file into the master NEWS file. Right now, the release notes on the webpage miss all IDLE release notes, since it's just the main NEWS file. -1 Right now IDLE has a button in the About IDLE dialog which accesses the IDLE NEWS.txt file, and another which accesses Python's NEWS. IDLE users may not want to grovel through all the Python changes to find out what changed in the IDE. It would be nice if the key IDLE changes could make it to the What's New in Python X.X. If Andrew is interested, I could draft something for him. -- KBK ___ 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] no remaining issues blocking 2.5 release
I just updated the PEP to remove all references to issues blocking release of 2.5. I don't know of any. I haven't heard of any issues with the fixes that have been checked in. If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. 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] no remaining issues blocking 2.5 release
On Tuesday 15 August 2006 14:31, Neal Norwitz wrote: I just updated the PEP to remove all references to issues blocking release of 2.5. I don't know of any. I haven't heard of any issues with the fixes that have been checked in. If you have issues, respond ASAP! The release candidate is planned to be cut this Thursday/Friday. There are only a few more days before code freeze. A branch will be made when the release candidate is cut. More information here: I plan to branch release25-maint on Thursday morning, as the first step in the release process for 2.5c1. This will be done after the repository is updated to identify itself as '2.5c1'. Once this is done, I plan on doing all further 2.5 releases from the release25-maint branch. I will no longer care about the trunk's stability :-) 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
