[python-committers] clinic churn after beta2

[Nick Coghlan]

On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl at gmx.net> wrote:
>
> Am 08.01.2014 03:23, schrieb Benjamin Peterson:
> > On Tue, Jan 7, 2014, at 06:06 PM, Nick Coghlan wrote:
> >> On 8 Jan 2014 08:44, "Eric V. Smith" <eric at 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.
> >
> > It's not design from scratch, since it should be fairly close to the 2.x
> > string formatting mini-languages.
>
> Yes, I think the feature set should be settled upon quickly.

I'm not yet convinced restoring more string-like behaviour to bytes is a
better solution than a dedicated type specifically for working with ASCII
compatible wire protocols (that approach is still being kicked around as a
possibility in the parallel discussion on python-ideas).

One key advantage of such a type is that it could be designed to make "text
or ASCII bytes" code like the URL parsing as straightforward to write as it
was in Python 2, whereas adding formatting to bytes objects wouldn't help
with that discrepancy at all.

Cheers,
Nick.

>
> >> 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.
> >
> > I think a shorter cycle for 3.5 is fine, too.
>
> Great!  I agree with Nick that 6 months is too short, but I would
definitely
> start with betas after 6 months.
>
> Georg
>
> _______________________________________________
> python-committers mailing list
> python-committers at python.org
> https://mail.python.org/mailman/listinfo/python-committers
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-committers/attachments/20140108/3b9c4f1b/attachment.html>