Re: [Python-Dev] Fuzzing bugs: most bugs are closed
Guido van Rossum wrote: The underscore at the beginning of _sre clearly indicates that the module is not recommended for direct consumption, IMO. Even the functions that don't themselves start with an underscore... I've written a re-code verifier for the Google App Engine ... which means that a protection against "evil _sre bytecode" was needed :-) Thanks Google and Guido to release this validator. Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Any PEP about 2.6 -> 3000 code transition?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Jul 21, 2008, at 2:16 PM, Brett Cannon wrote: But waiting until all the betas have gone out totally defeats the purpose of the betas! It has already been stated that new code changes that are even remotely shaky or anything not small needs a code review at this point since we only have one beta left. Barry can correct me if I am wrong, but dropping a major rewrite of bsddb into 3.0 between b3 and rc1 is not acceptable. I wouldn't be surprised if all code after b3 requires a code review since at that point we should just be squashing bugs, not rewriting code. And if you are migrating all of bsddb3 at once then that is going to be a massive code review that should be happening in prep for rc1. I agree. Our last beta is scheduled for this wednesday and if we have any hope of hitting our Oct 1 target, we really can't afford to slip. I'll just state that I'm going to be even more conservative about what gets in after b3. I'd say that if you expect it to go in to Python 2.6 or 3.0, you better get it in now. I really hate feeling like I am coming off as a jerk harping on this, Jesus, as I don't want to discourage your contributions to pybsddb, but it just doesn't feel reasonable to me to be doing this so late in the release cycle. Let's however try to find a way to let Jesus and others continue to work on important tools like bsddb even if it can't make it into the final releases. Perhaps we can move this stuff to the sandbox and setuptools-ify it. - -Barry -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (Darwin) iQCVAwUBSJ8nIXEjvBPtnXfVAQKLKAP/dH9TkMUhNxWDn6hAwVWe/Jjen9/hEPAL ExYEMK1qxI8b2FYjphjG7+dA/xFh+tzOdymyjJuBMy69TJMdWF1uh614Dfl0NYNA 7IsHCZlRZWVARPv0ZG8DZR3scBDPmHjxkBpzzyXH/yqJ/SaN5cdoOuYcMZUsIilN 2gr0MNvfe4I= =Rkk4 -END PGP SIGNATURE- ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Dealing with mimetools usage in the stdlib
On Sat, Aug 9, 2008 at 11:52 PM, Adam Olsen <[EMAIL PROTECTED]> wrote: > On Sat, Aug 9, 2008 at 11:41 PM, Brett Cannon <[EMAIL PROTECTED]> wrote: >> On my quest to remove warnings raised in 2.6 when Python is run with >> -3, the issue of dealing with mimetools has come up in terms of >> backwards-compatibility. For instance, in BaseHTTPServer, the headers >> attribute on BaseHTTPRequestHandler is an instance of >> mimetools.Message. But in 3.0 it is an instance of >> http.client.HTTPMessage. >> >> So my question is, should 2.6 be changed to match 3.0, or should >> deprecation warnings for mimetools (and possibly other modules) just >> be silenced so as to not risk breaking backwards-compatibility? > > Just silence them. The warnings are an aid for finding bugs, not an > excuse to create more bugs. > The problem I just realized with silencing them, though, is that the warning only occurs once at initial import, so if you silence the import in BaseHTTPServer but then import mimetools directly later on the DeprecationWarning won't come up from the later import. It's an unfortunate side-effect of caching imported modules in sys.modules. The only way around it is to either delete the module out of sys.modules so that subsequent imports will reload the module, or to come up with some modification to import that does some check for a __deprecated__ flag or something and raises the proper deprecation with the specified message before returning the module (which I really don't see happening this late in the development cycle, but still might be a good idea to think through for 2.7/3.1):: import sys if sys.py3kwarning: __deprecated__ = "the mimetools module has been removed in Python 3.0" # Rest of module's code -Brett ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
