[Python-ideas] Add from __experimental__ import bla [was: Should we move to replace re with regex?]

[Matt Joiner]

This feature reminds me of "staging" in the Linux kernel.

I often hear complaints that Python's bringing too many features on
board, trying to explain __experimental__, {major, minor, patch} does
not seem desirable. Then there's the consideration that any and all
stuff floating around in __experimental__ will be overly encouraged,
because honestly how many modules won't end up making the cut?

Why can't a special tag/section be added in PyPi to indicate that a
module is being considered for inclusion in future versions of Python,
after all, we're all friends here. This might also give the
oppurtunity to showcase some of the newer packaging infrastructure,
and how easy it makes it to install third party modules. (Disclaimer:
I haven't looked at the new one and I detest the old one.)

-1 for adding yet more clutter

Also -1 for renaming re: Some people call regex, regexp, you'll only
be offending their sensibilities and adding to the confusion.
Furthermore, a lot of Python's competitors have builtin regex support,
such as =~ in Perl and bash. The terser the syntax for regex, the more
at home and less cluttered it will appear to those users. I recommend
that if a new regex module is created, that the name regex be used
then, and the old be left alone.

On Tue, Aug 30, 2011 at 1:03 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Tue, Aug 30, 2011 at 11:22 AM, Bruce Leban <bruce at leapyear.org> wrote:
>> Unlike __future__ the API is unstable and therefore code that works with
>> today's __experimental__ may fail tomorrow. If the API changes in an
>> incompatible way, we would probably prefer that the import fail rather than
>> succeed with random results. Therefore, I would propose a mechanism to
>> support this, perhaps something like
>>
>> from __experimental__ import regex {2,3,4} as re
>
> I'd advise against trying to overengineer this. If we decide to go
> down the path of breaking imports, then we'd probably just do it via
> naming conventions (e.g. give all experimental modules a suffix based
> on the Python version where they were first included).
>
> However, if you're concerned about subtle breakage due to backwards
> incompatibilities, then that's a good sign that depending on
> explicitly experimental modules is a *bad idea*.
>
> Adding a package specifically for candidate standard library modules
> with APIs that aren't yet locked in would be easy and low impact.
> Messing with the compiler or interpreter to provide additional
> features would be much higher impact, and consequently a much harder
> sell.
>
> However, you've highlighted the major problem with the idea: just
> because we *say* that the package is experimental and APIs may change
> without (programmatic) warning, doesn't mean people will pay
> attention. There are also a whole host of serialisation problems that
> arise when dealing with relocated modules, which could cause issues
> with the eventual migration to the "real" module location.
>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>