Re: [Python-Dev] PEP about sys.implementation and implementation specific user site directory
M.-A. Lemburg wrote: >> sys.userdirsuffix >> - >> >> sys.userdirsuffix is an implementation and platform specific string that >> is used to construct the path for the user site directory as explained >> in PEP 370. The string contains the implementation name as well as the >> version number of Python. > > Don't we already have this information available as site.getuserbase()/ > site.getusersitepackages() ? No, the new attribute is intended to allow a VM implementation to customise the way site.py calculates the user directories so that CPython, Jython, IronPython, etc, don't have to share the same directory. CPython will stick with the directory as named in PEP 370 (since we already released a version with that behaviour), but the other implementations will be able to choose a name that doesn't conflict with it. 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] PEP about sys.implementation and implementation specific user site directory
Nick Coghlan wrote: > M.-A. Lemburg wrote: >>> sys.userdirsuffix >>> - >>> >>> sys.userdirsuffix is an implementation and platform specific string that >>> is used to construct the path for the user site directory as explained >>> in PEP 370. The string contains the implementation name as well as the >>> version number of Python. >> >> Don't we already have this information available as site.getuserbase()/ >> site.getusersitepackages() ? > > No, the new attribute is intended to allow a VM implementation to > customise the way site.py calculates the user directories so that > CPython, Jython, IronPython, etc, don't have to share the same directory. > > CPython will stick with the directory as named in PEP 370 (since we > already released a version with that behaviour), but the other > implementations will be able to choose a name that doesn't conflict with it. Ah, so it's intended to provide information to site.getuserbase()/ site.getusersitepackages() ? Still, since that path name component is used in other contexts as well, wouldn't it be better to have all those contexts use the name ?! Python has always used the (lib|include)/pythonX.Y/ path naming scheme on Unix, but it's not codified anywhere. A sys attribute or a set of such attributes would be good way to do so. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] Python 2.6.4rc1
On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote: On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote: I want us to be very careful about 2.6.4. This isn't a normal bug fix release, it's specifically there to remove the brown paper bag of 2.6.3 from our heads. So let's be conservative and fix this one in 2.6.5. Can we get the readline patch reviewed as well. It was applied to trunk already: http://svn.python.org/view?view=rev&revision=74970 It's marked for backport to 2.6 as "needs review": http://bugs.python.org/issue6877 It fixes a BusError crash that was just swiped under a rug by disabling the build in setup.py. :-) I'm disinclined to approve this for 2.6.4 since it is not a regression in 2.6.3. It seems fine to me for 2.6.5 though. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] On track for Python 2.6.4 final this Sunday?
Are we on track to release 2.6.4 final this Sunday or do we need another rc? Yesterday, Tarek committed another setuptools related fix and said that he was going to run a bunch of build tests locally. Tarek, how did that go? Please note that issue 7064 is still open as a release blocker. Can we close that (again) now? http://bugs.python.org/issue7064 I am still being very conservative about what goes in 2.6.4. Only regressions introduced in 2.6.3 are being accepted. There's plenty of time after that for patches to go in for 2.6.5. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] Python 2.6.4rc1
On Oct 13, 2009, at 8:23 AM, Barry Warsaw wrote: On Oct 8, 2009, at 8:45 AM, Zvezdan Petkovic wrote: On Oct 7, 2009, at 2:09 PM, Barry Warsaw wrote: I want us to be very careful about 2.6.4. This isn't a normal bug fix release, it's specifically there to remove the brown paper bag of 2.6.3 from our heads. So let's be conservative and fix this one in 2.6.5. Can we get the readline patch reviewed as well. It was applied to trunk already: http://svn.python.org/view?view=rev&revision=74970 It's marked for backport to 2.6 as "needs review": http://bugs.python.org/issue6877 It fixes a BusError crash that was just swiped under a rug by disabling the build in setup.py. :-) I'm disinclined to approve this for 2.6.4 since it is not a regression in 2.6.3. It seems fine to me for 2.6.5 though. Excellent. That's exactly what I meant. I quoted the part of the previous message where you proposed to review another patch for 2.6.5. I guess it was not very clear that I'm proposing to review this for 2.6.5 as well. Well, at least we're on the same page now it seems. :-) Thanks, Zvezdan ___ 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] Python 2.6.4rc1
On Oct 13, 2009, at 8:31 AM, Zvezdan Petkovic wrote: Excellent. That's exactly what I meant. I quoted the part of the previous message where you proposed to review another patch for 2.6.5. I guess it was not very clear that I'm proposing to review this for 2.6.5 as well. Well, at least we're on the same page now it seems. :-) :) -Barry PGP.sig Description: This is a digitally signed message part ___ 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] On track for Python 2.6.4 final this Sunday?
Barry Warsaw wrote: > Are we on track to release 2.6.4 final this Sunday or do we need another > rc? > > Yesterday, Tarek committed another setuptools related fix and said that > he was going to run a bunch of build tests locally. Tarek, how did that > go? > > Please note that issue 7064 is still open as a release blocker. Can we > close that (again) now? > > http://bugs.python.org/issue7064 > > I am still being very conservative about what goes in 2.6.4. Only > regressions introduced in 2.6.3 are being accepted. There's plenty of > time after that for patches to go in for 2.6.5. It would be nice to get this issue resolved out for 2.6.4: http://bugs.python.org/issue4120 The problem is that extensions built with 2.6.x will not work when used with a User-only installation of Python on machines that don't already have the MS VC90 CRT DLLs installed system-wide. There's a patch available that appears to work, but someone with more manifest-Windows-DLL-fu than me will need to have a look at it. One possible approach would be to use the patch in 2.6.4 and then continue digging deeper until 2.6.5 is released. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
> It would be nice to get this issue resolved out for 2.6.4: > > http://bugs.python.org/issue4120 > > The problem is that extensions built with 2.6.x will not work > when used with a User-only installation of Python on machines that > don't already have the MS VC90 CRT DLLs installed system-wide. As this bug already exists in 2.6.2, I don't think the change is eligible for 2.6.4. In addition, I want to review it, which I won't be able to until Sunday. > One possible approach would be to use the patch in 2.6.4 and then > continue digging deeper until 2.6.5 is released. This also speaks against the patch. Anything being changed in this area ideally should be the final state of affairs for the rest of 2.6.x. 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] On track for Python 2.6.4 final this Sunday?
At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: Are we on track to release 2.6.4 final this Sunday or do we need another rc? Yesterday, Tarek committed another setuptools related fix and said that he was going to run a bunch of build tests locally. Tarek, how did that go? FWIW, that change won't work to fix the problem on Windows if a package's setup.py is written with cross-platform paths (i.e., the usual case). Also, for the record, it's not really a setuptools-related fix; it's just attempting to fix collateral damage caused by the attempt to fix the problems caused by the original API change... which affected all build_ext customizations relying on the docstring of the changed method, not just the one in setuptools. ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
"Martin v. Löwis" wrote: > >> It would be nice to get this issue resolved out for 2.6.4: >> >> http://bugs.python.org/issue4120 >> >> The problem is that extensions built with 2.6.x will not work >> when used with a User-only installation of Python on machines that >> don't already have the MS VC90 CRT DLLs installed system-wide. > > As this bug already exists in 2.6.2, I don't think the change is > eligible for 2.6.4. > > In addition, I want to review it, which I won't be able to until > Sunday. Then I'd suggest to wait another week with 2.6.4 to give you a chance to look at the patch. >> One possible approach would be to use the patch in 2.6.4 and then >> continue digging deeper until 2.6.5 is released. > > This also speaks against the patch. Anything being changed in this area > ideally should be the final state of affairs for the rest of 2.6.x. Of course, but we don't live in an ideal world, otherwise we would have noticed before releasing 2.6 :-) I guess the problem is that developer typically already have the MS VC90 CRT DLLs installed system-wide, so they simply don't notice. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote: > At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: >> >> Are we on track to release 2.6.4 final this Sunday or do we need >> another rc? >> >> Yesterday, Tarek committed another setuptools related fix and said >> that he was going to run a bunch of build tests locally. Tarek, how >> did that go? > I still need to do some more tests, I didn't have time to try the various projects under win32. It's planned to night. The tests are consisting of compiling and insatling a dozain of projects on linux and win32 (and bith when possible) > FWIW, that change won't work to fix the problem on Windows if a package's > setup.py is written with cross-platform paths (i.e., the usual case). > > Also, for the record, it's not really a setuptools-related fix; it's just > attempting to fix collateral damage caused by the attempt to fix the > problems caused by the original API change... which affected all build_ext > customizations relying on the docstring of the changed method, not just the > one in setuptools. Yes the doctest was pretty fuzzy about what is an extension name. It's will be improved in 2.7. The current code is doing os.path.join()'s to join the Extension name with the build path, leading to the collateral damage you are mentioning. To fix the problem, the API has to be as permissive as it was before. I have already three or four tests to fix that problem in test_build_ext. If you can take a look at them and think of any other test that would be missing, that would be appreciated. Another pair of eye is never enough. Tarek ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
>> As this bug already exists in 2.6.2, I don't think the change is >> eligible for 2.6.4. >> >> In addition, I want to review it, which I won't be able to until >> Sunday. > > Then I'd suggest to wait another week with 2.6.4 to give you a > chance to look at the patch. That won't make the change more eligible. > Of course, but we don't live in an ideal world, otherwise we would > have noticed before releasing 2.6 :-) Oh, I did notice. I had been cautioning for years that switching to a newer VS version (2005 or later) would cause severe problems. We are still trying to recover from the switch to VS 2008. That said, staying with VS 2003 really hadn't been an option, either. It's just said that Microsoft has created a new DLL hell in their attempt to fix the old one, and that they fail to admit it (assuming that everybody should be using .NET, anyway). 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Tue, Oct 13, 2009 at 5:30 PM, P.J. Eby wrote: > > One identical to test_build_ext_path_with_os_sep, but that explicitly uses a > '/' (rather than os.sep) will identify the problem I'm referring to, when > run on Windows. > > It's common practice to use /-separated paths in setup scripts, regardless > of platform. So, your current fix (converting os.sep to '.') will work on > Linux, Mac, etc., but fail on Windows when run with the same setup.py, since > os.sep is a backslash there. Ok I will have a look at this tonite. Thanks. Notice that this changed I made to fix another bug opened a can of worms because Extension is not enough/clearly documented in this regards. The goal for 2.7/3.2 is to come up with one single way to define extensions, and I will probably just add deprecation warnings for the other forms. > > (Just as a side note, if when you split off issue 7115 you'd said what the > new issue number was in 7064, or copied me to the nosy-list on the new > issue, I'd have been able to review this change and comment on it yesterday > instead of today, and I'd have done it in the bug tracker rather than via > Python-Dev.) Sorry about that, I'll add a note on #7064. ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
At 05:16 PM 10/13/2009 +0200, Tarek Ziadé wrote: Yes the doctest was pretty fuzzy about what is an extension name. It's will be improved in 2.7. The current code is doing os.path.join()'s to join the Extension name with the build path, leading to the collateral damage you are mentioning. To fix the problem, the API has to be as permissive as it was before. I have already three or four tests to fix that problem in test_build_ext. If you can take a look at them and think of any other test that would be missing, that would be appreciated. Another pair of eye is never enough. One identical to test_build_ext_path_with_os_sep, but that explicitly uses a '/' (rather than os.sep) will identify the problem I'm referring to, when run on Windows. It's common practice to use /-separated paths in setup scripts, regardless of platform. So, your current fix (converting os.sep to '.') will work on Linux, Mac, etc., but fail on Windows when run with the same setup.py, since os.sep is a backslash there. (Just as a side note, if when you split off issue 7115 you'd said what the new issue number was in 7064, or copied me to the nosy-list on the new issue, I'd have been able to review this change and comment on it yesterday instead of today, and I'd have done it in the bug tracker rather than via Python-Dev.) ___ 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] On track for Python 2.6.4 final this Sunday?
P.J. Eby wrote: > At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: >> Are we on track to release 2.6.4 final this Sunday or do we need >> another rc? >> >> Yesterday, Tarek committed another setuptools related fix and said >> that he was going to run a bunch of build tests locally. Tarek, how >> did that go? > > FWIW, that change won't work to fix the problem on Windows if a > package's setup.py is written with cross-platform paths (i.e., the usual > case). > > Also, for the record, it's not really a setuptools-related fix; it's > just attempting to fix collateral damage caused by the attempt to fix > the problems caused by the original API change... which affected all > build_ext customizations relying on the docstring of the changed method, > not just the one in setuptools. Just to clarify a bit what all the fuzz is about: The API in question (build_ext.get_ext_filename()) was not changed at all. The doc-string also doesn't refer to *the* extension currently being built, but to just to some arbitrary extension: def get_ext_filename (self, ext_name): r"""Convert the name of an extension (eg. "foo.bar") into the name Convert the name of an extension (eg. "foo.bar") into the name of the file from which it will be loaded (eg. "foo/bar.so", or "foo\bar.pyd").""" What did change is the way this method is used by other methods in build_ext: the method is no longer being called with the full dotted name, but only with the last component. Now, setuptools and pywin32 both override the method, with the understanding that this method is the one and only way to convert the extensions (full) dotted name into a file name. Up until the change (which was needed to get inplace installations working), that assumption was true. However, neither the doc-string nor the implementation of the method ever implied this. distutils occasionally makes such assumptions necessary since there's no clean OO-way to override the functionality. That's not ideal, but works most of the time. However, authors of distutils add-ons cannot really expect such hacks to survive forever. Rather than relying on these, it's better to get distutils fixed to provide the necessary OO-hooks to properly implement the modified functionality. FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be able to get rid off the few remaining hacks ! -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
"Martin v. Löwis" wrote: > >>> As this bug already exists in 2.6.2, I don't think the change is >>> eligible for 2.6.4. >>> >>> In addition, I want to review it, which I won't be able to until >>> Sunday. >> >> Then I'd suggest to wait another week with 2.6.4 to give you a >> chance to look at the patch. > > That won't make the change more eligible. No, but chances increase :-) >> Of course, but we don't live in an ideal world, otherwise we would >> have noticed before releasing 2.6 :-) > > Oh, I did notice. I had been cautioning for years that switching to > a newer VS version (2005 or later) would cause severe problems. We > are still trying to recover from the switch to VS 2008. That said, > staying with VS 2003 really hadn't been an option, either. It's > just said that Microsoft has created a new DLL hell in their attempt > to fix the old one, and that they fail to admit it (assuming that > everybody should be using .NET, anyway). Well, hopefully we can work out those problems and then stay with VS 2008 a bit. MS is already working on VS 2010: http://www.microsoft.com/visualstudio/en-us/products/2010/default.mspx List of C/C++ changes: http://msdn.microsoft.com/en-us/library/dd465215(VS.100).aspx Not sure what this means: """ The libraries deployment model is no longer based on the fusion mechanism, and manifests are no longer used. Instead, the name of each dynamic link library contains its version number. """ Perhaps they finally realized that adding version number to DLLs is better than trying to match manifests. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] On track for Python 2.6.4 final this Sunday?
At 05:42 PM 10/13/2009 +0200, M.-A. Lemburg wrote: FWIW, I've had to change and tweak our mxSetup.py many many times to get it to work again with new distutils releases and I expect this to occur even more often now that distutils is finally being maintained again - and that's good, since I'll be able to get rid off the few remaining hacks ! Thanks for the nice (and neutral) explanation, for those not up to speed on the details. Of course, had the change been made in 2.7 rather than 2.6.3, there wouldn't have been a problem here. People understand that new major versions sometimes mean that existing packages will need to adapt and cope. Under normal circumstances, however, a dot release shouldn't break packages that worked with previous dot releases. (At least, that's the common expectation.) Now, I do have to admit that I'm still ignorant of what bug this was trying to fix in the first place. You say it "was needed to get inplace installations working", but I don't know what that means, since AFAIK inplace extension builds (build_ext -i) have been working since before the first versions of setuptools appeared in 2003. So, if there was a bug in build_ext that wasn't *introduced* in 2.6, it seems like 2.6.3 would be an odd place to fix that bug. This isn't intended as a criticism of anybody, mind you; I'm just saying that I still don't understand why the change was made in 2.6.3 in the first place, and it would be kind of nice to know. These kinds of situations can be useful for illustrating and improving Python policy, if the root causes and reasoning are understood by everyone. ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote: Then I'd suggest to wait another week with 2.6.4 to give you a chance to look at the patch. That's not a good option, IMO. We have a known broken 2.6.3 out there and we owe it to our users to correct our mistake and given them the release they should have gotten in the first place. We don't need to wait too long for 2.6.5 though. A few months would be appropriate. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote: I still need to do some more tests, I didn't have time to try the various projects under win32. It's planned to night. The tests are consisting of compiling and insatling a dozain of projects on linux and win32 (and bith when possible) Great thanks, let us know how it goes. If there's any question at all about the fixes that have gone in since rc1, we should spin an rc2. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 12:57 PM, Barry Warsaw wrote: On Oct 13, 2009, at 11:16 AM, Tarek Ziadé wrote: I still need to do some more tests, I didn't have time to try the various projects under win32. It's planned to night. The tests are consisting of compiling and insatling a dozain of projects on linux and win32 (and bith when possible) Great thanks, let us know how it goes. If there's any question at all about the fixes that have gone in since rc1, we should spin an rc2. Just curious, how big a server does the linux portion of the test require memory-wise? Would, e.g. an Ubuntu 9.0x with 256MB do the job? I ask because those types of servers are available for short-run jobs for pennines per hour and I would be willing to work on the code to fire-up, load them with the test suite, do the run, and shut them down. I happen to have a bunch of code lying around for doing such things... S ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
Barry Warsaw wrote: > On Oct 13, 2009, at 11:01 AM, M.-A. Lemburg wrote: > >> Then I'd suggest to wait another week with 2.6.4 to give you a >> chance to look at the patch. > > That's not a good option, IMO. We have a known broken 2.6.3 out there > and we owe it to our users to correct our mistake and given them the > release they should have gotten in the first place. > > We don't need to wait too long for 2.6.5 though. A few months would be > appropriate. Would it be reasonable to shorten that period, if the fix for the mentioned problem gets ready for prime time earlier ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote: Would it be reasonable to shorten that period, if the fix for the mentioned problem gets ready for prime time earlier ? I think there are many 2.6.x bugs queued up for after 2.6.4 is released. I'm not at all opposed to setting a date approximately 1 month from now for the first 2.6.5 rc. That should give people plenty of time to get their top fixes in. i-like-timed-releases-ly y'rs, -Barry PGP.sig Description: This is a digitally signed message part ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
>> We don't need to wait too long for 2.6.5 though. A few months would be >> appropriate. MAL> Would it be reasonable to shorten that period, if the fix for the MAL> mentioned problem gets ready for prime time earlier ? I think it would be worthwhile to prioritize all outstanding bugs which have been mentioned in the context of 2.6.[345] and run a bug day with the top priority being to fix those bugs. If that task is completed, then move onto other stuff. Once those primary bugs are tackled schedule a 2.6.5 release. 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Tue, 13 Oct 2009 at 12:57, Barry Warsaw wrote: On Oct 13, 2009, at 11:16 AM, Tarek Ziad? wrote: I still need to do some more tests, I didn't have time to try the various projects under win32. It's planned to night. The tests are consisting of compiling and insatling a dozain of projects on linux and win32 (and bith when possible) Great thanks, let us know how it goes. If there's any question at all about the fixes that have gone in since rc1, we should spin an rc2. I always thought that the idea of a release candidate was that if there were any fixes _at all_ that there would be a new rc. Only when no bugs needing fixed are found does the rc turn into the actual release. But I understand that this is an idealized rc/release policy :) --David (RDM)___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 1:41 PM, R. David Murray wrote: I always thought that the idea of a release candidate was that if there were any fixes _at all_ that there would be a new rc. Only when no bugs needing fixed are found does the rc turn into the actual release. But I understand that this is an idealized rc/release policy :) I'll invoke the Umbrella Rule now. If we don't do one we'll wish we had. If we do, we won't have needed it. -Barry PGP.sig Description: This is a digitally signed message part ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
Barry Warsaw wrote: > On Oct 13, 2009, at 1:07 PM, M.-A. Lemburg wrote: > >> Would it be reasonable to shorten that period, if the fix for the >> mentioned problem gets ready for prime time earlier ? > > I think there are many 2.6.x bugs queued up for after 2.6.4 is > released. I'm not at all opposed to setting a date approximately 1 > month from now for the first 2.6.5 rc. That should give people plenty > of time to get their top fixes in. > > i-like-timed-releases-ly y'rs, Agreed. Adding some pressure that way helps :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Oct 13 2009) >>> 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 our new mxODBC.Connect Python Database Interface for free ! eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 http://www.egenix.com/company/contact/ ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Tue, Oct 13, 2009 at 10:45 AM, Barry Warsaw wrote:
> On Oct 13, 2009, at 1:41 PM, R. David Murray wrote:
>
>> I always thought that the idea of a release candidate was that if there
>> were any fixes _at all_ that there would be a new rc. Only when no
>> bugs needing fixed are found does the rc turn into the actual release.
>> But I understand that this is an idealized rc/release policy :)
>
> I'll invoke the Umbrella Rule now. If we don't do one we'll wish we had.
> If we do, we won't have needed it.
Traceback (most recent call last):
File "umbrella_rules.py", line 6, in
UmbrellaRule()
File "unbrella_rules.py", line 4, in UmbrellaRule
raise
DuplicateRuleName('http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/')
DuplicateRuleName:
http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/
--
--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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 2:00 PM, Guido van Rossum wrote:
Traceback (most recent call last):
File "umbrella_rules.py", line 6, in
UmbrellaRule()
File "unbrella_rules.py", line 4, in UmbrellaRule
raise
DuplicateRuleName('http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/')
DuplicateRuleName:
http://whatplanetisthis.com/2008/02/the-umbrella-rule-and-sharing-rules-in-general/
MisinformedMeteorologistRule (probably more PC than stupid weatherman
rule :)
-Barry
PGP.sig
Description: This is a digitally signed message part
___
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] [python-committers] On track for Python 2.6.4 final this Sunday?
> I always thought that the idea of a release candidate was that if there > were any fixes _at all_ that there would be a new rc. Only when no > bugs needing fixed are found does the rc turn into the actual release. This was also my understanding; that's the point of calling it "candidate". Since the code base of 2.6.4rc1 was not released as-is, we would need to consider another candidate. But then, Barry doesn't like release candidates in the first place. 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Tue, Oct 13, 2009 at 5:16 PM, Tarek Ziadé wrote: > On Tue, Oct 13, 2009 at 4:52 PM, P.J. Eby wrote: >> At 08:27 AM 10/13/2009 -0400, Barry Warsaw wrote: >>> >>> Are we on track to release 2.6.4 final this Sunday or do we need >>> another rc? >>> >>> Yesterday, Tarek committed another setuptools related fix and said >>> that he was going to run a bunch of build tests locally. Tarek, how >>> did that go? >> > > I still need to do some more tests, I didn't have time to try the > various projects under win32. > It's planned to night. > > The tests are consisting of compiling and insatling a dozain of > projects on linux and win32 (and bith when possible) Barry, I'll continue my win32 smoke tests tomorrow, it's not over. So far, so good. windows XP (vmware) - VC9 - running setup.py build+install - zope.interface 3.5.2 + setuptools 0.6c9 - Twisted-8.2.0 + setuptools 0.6c9 - pythonwin32-314 +plain distutils: works but I had a failure on 'mc.exe' on one extension which is unrelated obviously. pywin32 builds fine otherwise. Still investigating. on this one Tarek ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: I always thought that the idea of a release candidate was that if there were any fixes _at all_ that there would be a new rc. Only when no bugs needing fixed are found does the rc turn into the actual release. This was also my understanding; that's the point of calling it "candidate". Since the code base of 2.6.4rc1 was not released as-is, we would need to consider another candidate. But then, Barry doesn't like release candidates in the first place. No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry PGP.sig Description: This is a digitally signed message part ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
> So, we can either make Sunday's release rc2 and do the final release one > week later, or I can try to get an rc2 out in the next day or two, with > a final release mid-next week. > > Thoughts? I won't be able to produce Windows binaries until Saturday. Now sure how that would fit into the "within the next day or two" plan. 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] [python-committers] On track for Python 2.6.4 final this Sunday?
I strongly urge another release candidate. But then, I am not doing the work, so take that advice for what it is... On Oct 14, 2009 10:18 AM, "Barry Warsaw" wrote: On Oct 13, 2009, at 6:10 PM, Martin v. Löwis wrote: >> I always thought that the idea of a release ... No, but let's do one anyway! So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? -Barry ___ python-committers mailing list python-committ...@python.org http://mail.python.org/mailman/listinfo/python-committers ___ 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] [python-committers] On track for Python 2.6.4 final this Sunday?
On Oct 13, 2009, at 10:15 PM, Martin v. Löwis wrote: So, we can either make Sunday's release rc2 and do the final release one week later, or I can try to get an rc2 out in the next day or two, with a final release mid-next week. Thoughts? I won't be able to produce Windows binaries until Saturday. Now sure how that would fit into the "within the next day or two" plan. That seems to argue for doing rc2 on Sunday the 18th. If I tag the release some time Saturday, you could have the binaries by Sunday right? Then we'll take one more week and release the final on the 25th. -Barry PGP.sig Description: This is a digitally signed message part ___ 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
