On 8 Jan 2014 08:44, "Eric V. Smith" <eric@trueblade.com> wrote:
>
> On 1/7/2014 7:33 PM, Benjamin Peterson wrote:
> > A PyPI module is not so great because you'll have to change every
> > formatting operation to use a function from a module rather than the %
> > operator or the format method.
>
> I think this is the crux of the issue. Are we trying to say "porting
> your existing code will be easier", or "change your existing code to
> this new library, and we'll provide the library on 2.x and 3.y" (for
> some values of x and y).
>
> I think the former is the right way to go, but I also think if we do
> that we should shoot for 3.4, and this would necessitate a delay in 3.4.
> Providing this feature for 3.5 might be too late for the target audience
> of code porters.

I'm saying hacking in a complex change in a few weeks when there isn't consensus even on the basics of the design just because a few moderately high profile developers failed to understand what "5 years to be the default choice for new projects" meant would be the height of irresponsibility. Create the module, figure out the exact formatting mini-language and semantics, post it on PyPI where compatibility modules like six and future can get at it, and *then* propose syntactic/builtin support for 3.5.

The 5 year goal was for the Python 3 ecosystem to be a sufficiently functionally complete alternative to Python 2 for it to be recommended by default for every use case where Python 2 wasn't already being used.

Addressing the key remaining barriers to migration for existing Python 2 users would be an excellent objective to attain before we end upstream support for Python 2.7, but it's one that would be better addressed by a slightly shorter dev cycle than normal for 3.5 than it would be by falling into the "just one more feature" trap for Python 3.4.

Cheers,
Nick.

>
> Eric.
>
> _______________________________________________
> python-committers mailing list
> python-committers@python.org
> https://mail.python.org/mailman/listinfo/python-committers