Re: [Python-Dev] [Python-3000] Proposed revised schedule
Guido van Rossum schrieb: >>> Perhaps it's time to separate the 2.6 and 3.0 release schedules? I >>> don't care if the next version of OSX contains 3.0 or not -- but I do >>> care about it having 2.6. >> >> I'm not really sure what good that would do us unless we wanted to >> bring 3.0 back to the beta phase and continue to work on some larger >> issues with it. I also suspect doing two separate, but close together >> final releases would be more stressful than having them in lock and >> step. > > Well, from the number of release blockers it sounds like another 3.0 > beta is the right thing. For 2.6 however I believe we're much closer > to the finish line -- there aren't all those bytes/str issues to clean > up, for example! And apparently the benefit of releasing on schedule > is that we will be included in OSX. That's a much bigger deal for 2.6 > than for 3.0 (I doubt that Apple would add two versions anyway). Even if I can't contribute very much at the moment, I'm still +1 to that. I doubt Python would get nice publicity if we released a 3.0 but had to tell everyone, "but don't really use it yet, it may still contain any number of showstoppers." >> Just my pocket change, though. I'm suspecting this is much more than $0.02 :D Georg -- Thus spake the Lord: Thou shalt indent with four spaces. No more, no less. Four shall be the number of spaces thou shalt indent, and the number of thy indenting shall be four. Eight shalt thou not indent, nor either indent thou two, excepting that thou then proceed to four. Tabs are right out. ___ 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-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_excepti
On 2008-09-09 02:49, brett.cannon wrote: > Author: brett.cannon > Date: Tue Sep 9 02:49:16 2008 > New Revision: 66321 > > Log: > warnings.catch_warnings() now returns a list or None instead of the custom > WarningsRecorder object. This makes the API simpler to use as no special > object > must be learned. > > Closes issue 3781. > Review by Benjamin Peterson. This sounds a lot like a feature. Why was it added just before RC1 ? > Modified: >python/trunk/Doc/library/warnings.rst >python/trunk/Lib/asynchat.py >python/trunk/Lib/bsddb/test/test_early_close.py >python/trunk/Lib/mimetools.py >python/trunk/Lib/test/test___all__.py >python/trunk/Lib/test/test_exceptions.py >python/trunk/Lib/test/test_hmac.py >python/trunk/Lib/test/test_import.py >python/trunk/Lib/test/test_macostools.py >python/trunk/Lib/test/test_pep352.py >python/trunk/Lib/test/test_py3kwarn.py >python/trunk/Lib/test/test_random.py >python/trunk/Lib/test/test_re.py >python/trunk/Lib/test/test_struct.py >python/trunk/Lib/test/test_structmembers.py >python/trunk/Lib/test/test_sundry.py >python/trunk/Lib/test/test_support.py >python/trunk/Lib/test/test_symtable.py >python/trunk/Lib/test/test_urllib.py >python/trunk/Lib/test/test_urllibnet.py >python/trunk/Lib/test/test_userstring.py >python/trunk/Lib/test/test_warnings.py >python/trunk/Lib/warnings.py >python/trunk/Misc/NEWS -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Source (#1, Sep 09 2008) >>> 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,MacOSX 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 ___ 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-3000] Proposed revised schedule
Guido van Rossum wrote: > Sure, we lose the ability to add last-minute -3 warnings. But I think > that's a pretty minor issue (and those warnings have a tendency to > subtly break things occasionally, so we shouldn't do them last-minute > anyway). Hey, if we catch all the things that need -3 warnings now, what are we meant to add in 2.7? :) +1 for a 2.6 rc and another 3.0 beta. 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] [Python-3000] Proposed revised schedule
[EMAIL PROTECTED] wrote: > Raymond> With the extra time, it would be worthwhile to add dbm.sqlite > Raymond> to 3.0 to compensate for the loss of bsddb so that shelves > Raymond> won't become useless on Windows builds. > > My vote is to separate 2.6 and 3.0 then come back together for 2.7 and 3.1. > I'm a bit less sure about adding dbm.sqlite. Unless Josiah's version is > substantially faster and more robust I think my version needs to cook a bit > longer. I'm just not comfortable enough with SQLite to pronounce my version > fit enough. I only intended it as a proof-of-concept, and it's clear it has > some shortcomings. Given that the *API* is fixed though, it is probably better to have the module present in 3.0 and bring it back to the main line in 2.7. If any absolute clangers from a performance/stability point of view get past Raymond (and everyone else with an interest in this) then they can be addressed in 3.0.1 in a few months time. Whereas if we leave the module out entirely, then 3.0 users are completely out of luck until 3.1 (or have to download and possibly build pybsddb). 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] [Python-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_excepti
M.-A. Lemburg wrote: > On 2008-09-09 02:49, brett.cannon wrote: >> Author: brett.cannon >> Date: Tue Sep 9 02:49:16 2008 >> New Revision: 66321 >> >> Log: >> warnings.catch_warnings() now returns a list or None instead of the custom >> WarningsRecorder object. This makes the API simpler to use as no special >> object >> must be learned. >> >> Closes issue 3781. >> Review by Benjamin Peterson. > > This sounds a lot like a feature. > > Why was it added just before RC1 ? It's also a bug that was introduced by the late API changes made to WarningsRecorder in r66135 (when WarningsRecorder was moved from test.test_support to warnings to make it officially supported for use outside the Python test suite, the API was also changed). Instead of changing the API *again* could we please get the API reverted back to the way it was for the two months prior to r66135 and only change the location from test_support to warnings? (obviously, the use of @contextmanager should still be removed since we don't particularly want warnings to depend on contextlib). Regards, 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] [Python-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_excepti
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 9, 2008, at 6:31 AM, Nick Coghlan wrote: It's also a bug that was introduced by the late API changes made to WarningsRecorder in r66135 (when WarningsRecorder was moved from test.test_support to warnings to make it officially supported for use outside the Python test suite, the API was also changed). Instead of changing the API *again* could we please get the API reverted back to the way it was for the two months prior to r66135 and only change the location from test_support to warnings? (obviously, the use of @contextmanager should still be removed since we don't particularly want warnings to depend on contextlib). As I commented in the bug, if this function is added to warnings I think it will be increasingly used as a way for code to suppress warnings. If that's the behavior we want to allow, then I think making every warning but the last inaccessible is a bug. If that's not a behavior we want to encourage then naming this function 'catch_warnings' and putting it in the warnings module sends the wrong message. Better to stick it in unittest if test_support is unacceptable. Or at least name it something that doesn't scream "use me in a way I don't intend!". - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZrfHEjvBPtnXfVAQI6DgP8DyNKZyR846u1Qpgbr4X3wOM1J6EcqSlW 74WGUoU80MDWH5wvagAl7Er90oEh0QhX4ogX8UgF8iLSOC7jwa4CgpZsd9a5V8WB 8M0ia/G457vjGYg8XsaD5Dqvuv6NgMcW/2KJCJK3cuzEafan5C+I6n6lKQMAGOu0 j/9/PtIOKmI= =btg/ -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed revised schedule
On Sep 8, 2008, at 1:13 PM, "Guido van Rossum" <[EMAIL PROTECTED]> wrote: On Mon, Sep 8, 2008 at 6:23 AM, Barry Warsaw <[EMAIL PROTECTED]> wrote: I don't think there's any way we're going to make our October 1st goal. We have 8 open release critical bugs, and 18 deferred blockers. We do not have a beta3 Windows installer and I don't have high hopes for rectifying all of these problems in the next day or two. I propose that we push the entire schedule back two weeks. This means that the planned rc2 on 17-September becomes our rc1. The planned final release for 01-October becomes our rc2, and we release the finals on 15- October. - -Barry Perhaps it's time to separate the 2.6 and 3.0 release schedules? I don't care if the next version of OSX contains 3.0 or not -- but I do care about it having 2.6. Given that 2.6 is going to be more widely adopted and used by both the community and OS distributors, I'm +1 on splitting the releases as well. -Jesse ___ 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-3000] Proposed revised schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 8, 2008, at 1:13 PM, Guido van Rossum wrote: Perhaps it's time to separate the 2.6 and 3.0 release schedules? I don't care if the next version of OSX contains 3.0 or not -- but I do care about it having 2.6. I've talked with my contact at MajorOS Vendor (tm) and, as much as he can say, he would be fine with this. They're having problems getting 3rd party modules to build against 3.0 anyway, but if we can release a very solid 2.6 by the 1-Oct deadline, I would support splitting the releases. I really don't like doing this, but if we can get 2.6 out on time, and 3.0 doesn't lag too far behind, I'm okay with it. We'll have to abbreviate the release schedule though, so everyone should concentrate on fixing the 2.6 showstoppers. I think we need to get 2.6rc1 out this week, followed by 2.6rc2 next Wednesday as planned and 2.6final on 1-October. I've shuffled the tracker to reduce all 3.0-only bugs to deferred blocker, and to increase all 2.6 deferred blockers to release blockers. There are 11 open blocker issues for 2.6: 3629 Python won't compile a regex that compiles with 2.5.2 and 30b2 3640 test_cpickle crash on AMD64 Windows build 3777 long(4.2) now returns an int 3781 warnings.catch_warnings fails gracelessly when recording warnings but... 2876 Write UserDict fixer for 2to3 2350 'exceptions' import fixer 3642 Objects/obmalloc.c:529: warning: comparison is always false due... 3617 Add MS EULA to the list of third-party licenses in the Windows... 3657 pickle can pickle the wrong function 1868 threading.local doesn't free attrs when assigning thread exits 3809 test_logging leaving a 'test.blah' file behind If we can close them by Wednesday or Thursday, and the 2.6 bots stay green, I will cut the 2.6rc1 release this week and the 2.6rc2 and final on schedule. If you're on board with this, please do what you can to resolve these open issues. As always, I'm on irc if you need to discuss anything. Cheers, - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZ3V3EjvBPtnXfVAQKLbAP6A9b0WBB0H/ONZbKie2TazK/qYLthYnZQ iIpfJ2UboOA7dJ/ueXIsD413oI8GTbUOsUlJOWbSzAfJ6oBuPHrjr4IFRCZhchKG lwViDaK/7aWgIusGFpt6y/SgwJBU531wb7o3Lx/P6rLx5Wh5Nr+tvhngt0WkSMSj WtCsy3mmgmQ= =3HdI -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed revised schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 8, 2008, at 7:25 PM, Guido van Rossum wrote: Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway). The MajorOS Vendor (tm) may be willing to ship a 3.0 beta if it's far enough along, though not as the primary Python version. They clearly want 2.6 for that. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZ4cXEjvBPtnXfVAQL4ygP/fLILvf3NhvmN3R2T7htGm08xt/bOBYGt +BDrV4rapS4j3jo2Cx+McEdjJZCdq9x7BIaTN+4ITwq02LEY5fmhp6NkhzE1dlnq qdgBq8x/Z4AnsxfydtqYrPhrzLWPpdEZElgll5FB6Dj6XIA7cB8tuds2cE7+OXJI Guom1Y0k6Ao= =u4FB -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed revised schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 8, 2008, at 10:07 PM, Raymond Hettinger wrote: [Guido van Rossum] Well, from the number of release blockers it sounds like another 3.0 beta is the right thing. For 2.6 however I believe we're much closer to the finish line -- there aren't all those bytes/str issues to clean up, for example! And apparently the benefit of releasing on schedule is that we will be included in OSX. That's a much bigger deal for 2.6 than for 3.0 (I doubt that Apple would add two versions anyway). With the extra time, it would be worthwhile to add dbm.sqlite to 3.0 to compensate for the loss of bsddb so that shelves won't become useless on Windows builds. That seems risky to me. First, it's a new feature. Second, it will be largely untested code. I would much rather see dbm.sqlite released as a separate package for possible integration into the core for 3.1. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZ40XEjvBPtnXfVAQK2WQP/e3N2rYD2rbsoynEnXvAjzF8lPoPRFDvl hbjERsbB93uSoBPHaTdjtXnW+InC0W4GC5ogHF9wARbzYTJaxx09WmjihX+PvgsW JhXwLpG3gtyclfqSAF8MWZHc4UnKnyUt5UgYBlZrzT0z7FhWmelUPl8QhS8/2n9L oT3qX8eLabI= =Zu70 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed revised schedule
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Sep 9, 2008, at 3:22 AM, Georg Brandl wrote: Even if I can't contribute very much at the moment, I'm still +1 to that. I doubt Python would get nice publicity if we released a 3.0 but had to tell everyone, "but don't really use it yet, it may still contain any number of showstoppers." I completely agree. We should not release anything that's not ready. Assuming that we all agree that 2.6 is much closer to being ready, that gives us two options: delay 2.6 to coincide with 3.0 or split the releases. The latter seems like the wisest choice to meet our goals. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSMZ5L3EjvBPtnXfVAQJwSQP/U7FFFI8ao5Xesf6F3QFIUMYFeISrlhof 9ynkQXAskUMelAfayGMSd2nD2+buXA7gyBWplAAEF2rtLhZ3N0+zeh/2HnqcY0b9 EtUM5shAIMlb2948IMoXlxSMplH5auBHMLYFnuPAIH9ERXsGVfyihLnUarAfzmT+ XrWfjrU62TA= =CUR4 -END PGP SIGNATURE- ___ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-3000] Proposed revised schedule
Barry> 3777 long(4.2) now returns an int Looks like Amaury has already taken care of this one. 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-checkins] r66321 - in python/trunk: Doc/library/warnings.rst Lib/asynchat.py Lib/bsddb/test/test_early_close.py Lib/mimetools.py Lib/test/test___all__.py Lib/test/test_excepti
Barry Warsaw wrote: > On Sep 9, 2008, at 6:31 AM, Nick Coghlan wrote: > >> It's also a bug that was introduced by the late API changes made to >> WarningsRecorder in r66135 (when WarningsRecorder was moved from >> test.test_support to warnings to make it officially supported for use >> outside the Python test suite, the API was also changed). > >> Instead of changing the API *again* could we please get the API reverted >> back to the way it was for the two months prior to r66135 and only >> change the location from test_support to warnings? (obviously, the use >> of @contextmanager should still be removed since we don't particularly >> want warnings to depend on contextlib). > > As I commented in the bug, if this function is added to warnings I think > it will be increasingly used as a way for code to suppress warnings. If > that's the behavior we want to allow, then I think making every warning > but the last inaccessible is a bug. > > If that's not a behavior we want to encourage then naming this function > 'catch_warnings' and putting it in the warnings module sends the wrong > message. Better to stick it in unittest if test_support is > unacceptable. Or at least name it something that doesn't scream "use me > in a way I don't intend!". The last version of test_support.catch_warnings() actually did make all warnings caught available via the w.warnings attribute. The API and implementation changes in the move from test_support to the warnings module didn't actually add any new features - they just changed the w.warnings[idx] spelling to w[idx], moved from caching an explicit list of attributes on the WarningRecorder to a __getattr__ based lookup on the last warning and from a generator-based context manager to a custom class with __enter__ and __exit__ methods. The last was actually a good idea due to interpreter startup implications, but the first two changes were unnecessary (and the attribute handling change is actually what led to issue3781). Regardless, my preference at this point is for us to revert back to only providing this feature through the regression test suite, since that implementation at least worked properly, and reconsider the matter of proving a more public version through the warnings module for 2.7/3.1. Yes, it will make life a little more difficult for the twisted folks if they can't rely on our test support module being present for whatever reason, but they do have the option of including their own version of catch_warnings() as a fallback if the regression test suite can't be found. 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] [Python-3000] Proposed revised schedule
Barry Warsaw wrote: > On Sep 8, 2008, at 7:25 PM, Guido van Rossum wrote: > >> Well, from the number of release blockers it sounds like another 3.0 >> beta is the right thing. For 2.6 however I believe we're much closer >> to the finish line -- there aren't all those bytes/str issues to clean >> up, for example! And apparently the benefit of releasing on schedule >> is that we will be included in OSX. That's a much bigger deal for 2.6 >> than for 3.0 (I doubt that Apple would add two versions anyway). > > The MajorOS Vendor (tm) may be willing to ship a 3.0 beta if it's far > enough along, though not as the primary Python version. They clearly > want 2.6 for that. Given that the sum total of actual Python 3.0 programs is currently pretty close to zero, I don't really see any reason for *any* OS vendor (even Linux distros) to be including a 3.0 interpreter in their base install at this point in time. I personally expect it to stay in the "optional extras" category until some time next year. Pessimists-have-more-opportunities-to-be-pleasantly-surprised'ly, Nick. ___ 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/ncoghlan%40gmail.com -- 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] [Python-3000] Proposed revised schedule
Barry Warsaw wrote: > 3781 warnings.catch_warnings fails gracelessly when recording warnings I just assigned this one to myself - I'll have a patch up for review shortly (the patch will revert back to having this be a regression test suite only feature). Cheers, Nick. ___ 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/ncoghlan%40gmail.com -- 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
[Python-Dev] new ssl module is incompatible with servers that drop privileges
I've been trying out the new ssl module, and I love it so far, except for the way it accepts private keys and certificates. It accept them only as paths to their location on the file system, which I believe means that a server can only support SSL if it has read permission to its private key file when client connections arrive. This is a problem for servers that bind to their socket and drop privileges as soon as they start up, a practice that is both common and recommended in the unix world. IMHO, this severely limits the new ssl module's utility, and discourages good security practices. Wouldn't it be better if we could specify keys and certificates as bytes or file-like objects? This would solve the security issue, give applications more flexibility in key management, and might also improve performance slightly (by avoiding file system operations at accept() time). Perhaps there's a workaround that I haven't noticed yet? A quick look at the source code didn't reveal any obvious way to specify keys other than as paths in the file system. http://bugs.python.org/issue3823 ___ 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] new ssl module is incompatible with servers that drop privileges
> It accept them only as > paths to their location on the file system, which I believe means that a > server can only support SSL if it has read permission to its private key > file when client connections arrive. This is a problem for servers that > bind to their socket and drop privileges as soon as they start up, a > practice that is both common and recommended in the unix world. Ah, excellent point. > IMHO, this severely limits the new ssl module's utility, and discourages > good security practices. Please file a bug report. A bug report with a patch and tests would be even better :-). Assign it to me. > Wouldn't it be better if we could specify keys and certificates as bytes > or file-like objects? This would solve the security issue, give > applications more flexibility in key management, and might also improve > performance slightly (by avoiding file system operations at accept() > time). I like it! Bill ___ 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] new ssl module is incompatible with servers that drop privileges
On Tue, September 9, 2008 12:49 pm, Bill Janssen wrote: >> IMHO, this severely limits the new ssl module's utility, and discourages >> good security practices. > > Please file a bug report. A bug report with a patch and tests would > be even better :-). Assign it to me. I filed one, but the bug tracker doesn't seem to offer a way to assign it to you. I'll add you to the nosy list. http://bugs.python.org/issue3823 I'm pretty swamped right now, so I don't think I can learn the code well enough to make a patch in the few weeks before python 2.6 is released. (How nice it would be if the debut of this very useful module was free of this problem!) If I find some unexpected free time, I'll take a crack at 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] ?spurious? Timeout in BSDDB under MS Windows
On Mon, Sep 8, 2008 at 3:24 AM, Trent Nelson <[EMAIL PROTECTED]> wrote: > On Fri, Sep 05, 2008 at 05:55:13PM +0200, Jesus Cea wrote: >> Trent, are you available to look at the ?spurious? timeout failures in >> bsddb replication code in the Windows buildbot?. >> >> Ten seconds timeout should be plenty enough. I can't debug any MS >> Windows issue myself; this is a Microsoft-free environment. > >I think I added in 10 seconds 'cause the tests kept failing when it >was at 2 seconds ;-) > >I remember digging around the code a bit when I bumped bsddb to 4.7 >on Windows to try and figure out what was going on. As far as I >could tell it wasn't anything obvious caused by the Python code; is >it possible this could be an issue with the underlying bsddb code? Are the buildbot(s) running under vmware? 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
