[Python-ideas] stdlib upgrades

[Ron Adam]

On 06/07/2010 09:37 AM, Bruce Frederiksen wrote:
> Or perhaps:
>
>    from experimental import new_module
>
> This is kind of a guarantee that the interface will change; since at
> some point, if new_module is "calcified", this will have to be changed
> to just:
>
>    import new_module
>
> For experimental language features, maybe:
>
>    from __experimental__ import new_feature
>
> This makes it clear that new_feature may change (perhaps even not be
> adapted?), vs the from __future__ semantics.
>
> Is it too complicated to try to differentiate between the decision of
> whether some capability will be provided or not, vs ironing out the API
> for that capability?
>
> For example,
>
>    from experimental import new_capability
>
> means that there is no commitment for new_capability at all -- it may
> simply be dropped entirely.  The danger of using this is that
> new_capability may simply disappear completely with no replacement.
>
> While,
>
>    from proposed import new_capability
>
> represents a commitment that new_capability will be provided at some
> point, but the API will likely change.  Here the danger of using it is
> that you will likely have to change your program to conform to a new API.
>
> A capability might start as "experimental", and if the value of it is
> demonstrated, move to "proposed" to work out the details before
> mainstreaming it.
>
> -Bruce

I was thinking of something a bit more limited in scope.  ie... only those 
modules already accepted for inclusion in a future release.  But you have 
the concept I was thinking of correct.

However experimental and proposed libraries is quite a lot more.  I think 
the svn sandbox directory sort of serves that purpose now although it isn't 
organized in any way that makes it easy for someone to tell what is what as 
far as being experimental, proposed, accepted and under active development, 
or something that is just lying around for future or past reference.

Maybe a bit of organizing the sandbox with categorized sub-folders would be 
good?

I'm really was just throwing out an idea in regard to limiting some of the 
problems of after the fact fixes or changes that can cause some problems. 
Ie.. give a new module a bit more exposure to a wider audience before its 
actually included.

Ron


> On Mon, Jun 7, 2010 at 2:33 AM, Ron Adam <rrr at ronadam.com
> <mailto:rrr at ronadam.com>> wrote:
>
>
>     On 06/01/2010 08:22 PM, Brett Cannon wrote:
>
>         I can only see two scenarios that might be considered acceptable to
>         address these issues.
>
>         One is that when new modules are accepted into the stdlib they are
>         flagged with a ExpermintalWarning so that people know that no
>         backwards-compatibility promises have been made yet. That gets the
>         module more exposure and gets python-dev real-world feedback to fix
>         issues before the module calcifies into a strong
>         backwards-compatibility. With that experience more proper decisions
>         can be made as to how to change things (e.g. the logging module's
>         default timestamp including microseconds which strptime cannot
>         parse).
>
>
>     Would it be possible to have a future_lib that gets enabled with
>     something like...
>
>        from __future__ import future_lib
>
>     These *new* library modules and packages won't be visible by
>     default. Maybe they stay there until the next major version or
>     possible some set period of time.
>
>     Ron
>
>     _______________________________________________
>     Python-ideas mailing list
>     Python-ideas at python.org <mailto:Python-ideas at python.org>
>     http://mail.python.org/mailman/listinfo/python-ideas
>
>