Keeping it third-party means many people will be reluctant to add it as a dependency to any code they put out.
I'd spin this as a good thing: the code is, after all, experimental.
Devin
On Sat, Aug 27, 2011 at 11:37 PM, Guido van Rossum
On Sat, Aug 27, 2011 at 7:50 PM, Mike Graham
wrote: On Sat, Aug 27, 2011 at 3:57 PM, Dj Gilcrease
wrote: In the thread about replacing re with regex someone mentioned adding to __future__ which isnt a great idea as future APIs are already solidified, they just live there to give developer time to adapt their code. The idea of a __experimental__ area is good for any pep's or stliib additions that are somewhat controversial (API isnt agreed on, code may take a while to integrate properly, developer wants some time to hash out any edge case bugs or API clarifications that may come up in large scale testing, etc).
__experimental__ should emit a warning on import that says anything in here may change or be removed at any time and should not be used in stable code.
__experimental__ features should behave the same as __future__ in that they can add new keywords or semantics to the existing language
__experimental__ features can move directly to the stlib or builtins if they do not add new keywords and/or are backwards compatible with the feature they are replacing. Otherwise they move into __future__ for how ever many releases are deemed reasonable time for developers to adapt their code.
If something's still experimental, why ship it as stdlib? Why not just keep it third party until integration? No reason to tempt people to do anything that needs a warning. If they want some software, they can install it.
Putting it in the stdlib labeled as experimental would send a signal that it's slated for stdlib inclusion (in this case to replace the re module) and makes it available to everyone with the right Python version. Keeping it third-party means many people will be reluctant to add it as a dependency to any code they put out.
That said, I'm not all that keen on my __experimental__ idea. The point of __future__ was that it would be recognized by the parser as it was parsing the file, so it could then modify its parsing tables on the fly. That's not needed for an experimental module. Telling people to use "import regex as re" is probably good enough, as we go that route. But personally, I'd much rather see either the existing re module upgraded, or the regex module replace the re module as of Python 3.3. Either of those sounds like a better solution for users of Python 3.3. But I realize it's more work for the core developers.
-- --Guido van Rossum (python.org/~guido) _______________________________________________ Python-ideas mailing list Python-ideas@python.org http://mail.python.org/mailman/listinfo/python-ideas