On Fri, Aug 26, 2011 at 8:47 PM, Steven D'Aprano <steve at pearwood.info>wrote: > Antoine Pitrou wrote: > >> On Fri, 26 Aug 2011 17:25:56 -0700 >> Dan Stromberg <drsalists at gmail.com> wrote: >> > If you add regex as "import regex", and the new regex module doesn't work > >> out, regex might be harder to get rid of. from __future__ import is an >>> established way of trying something for a while to see if it's going to >>> work. >>> >> >> That's an interesting idea. This way, integrating the new module would >> be a less risky move, since if it gives us too many problems, we could >> back out our decision in the next feature release. >> > > I'm not sure that's correct. If there are differences in either the > interface or the behaviour between the new regex and re, then reverting will > be a pain regardless of whether you have: > > from __future__ import re > re.compile(...) > > or > > import regex > regex.compile(...) > > > Either way, if the new regex library goes away, code will break, and fixing > it may not be easy. You're talking technically, which is important, but wasn't what I was suggesting would be helped. Politically, and from a marketing standpoint, it's easier to withdraw a feature you've given with a "Play with this, see if it works for you" warning. Have then been any __future__ features that were added provisionally? > I can't either, but ISTR hearing that from __future__ import was started with such an intent. Irrespective, it's hard to import something from "future" without at least suspecting that you're on the bleeding edge. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mail.python.org/pipermail/python-dev/attachments/20110826/b49ab872/attachment-0001.html>
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4