Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Georg Brandl 
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"  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.

>> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Nick Coghlan 
On 8 Jan 2014 17:06, "Georg Brandl"  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"  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
> [email protected]
> https://mail.python.org/mailman/listinfo/python-committers
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Antoine Pitrou 
On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
> 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.

Agreed with Nick here. Let's just add a third beta for the clinic churn.

Regards

Antoine.


___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Eli Bendersky 
On Wed, Jan 8, 2014 at 2:16 AM, Antoine Pitrou  wrote:

> On mer., 2014-01-08 at 12:06 +1000, Nick Coghlan wrote:
> > 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.
>
> Agreed with Nick here. Let's just add a third beta for the clinic churn.
>

+1

Eli
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Barry Warsaw 
On Jan 08, 2014, at 05:39 PM, Nick Coghlan wrote:

>I suspect a 6 month cycle would confuse users and inconvenience
>redistributors, but a 12—17 month cycle so 3.5 is published before 2.7
>enters security fix only mode would make a *lot* of sense.

18 months is already the typical development cycle for new versions of Python,
so it would have to be markedly shorter than that.  6-9 months seems about
right, and if we adopted that *and* tightly focused new features in 3.5 to
those that making porting from Python 2 easier, then I could see that as a
reasonable alternative, especially given the realities of the baked-in time
constraints for 3.4.

Adding another beta for clinic churn seems entirely reasonable.

So, let's put "Goals for 3.5" on the agenda for the Language Summit.

-Barry
___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Georg Brandl 
Am 08.01.2014 11:08, schrieb Nick Coghlan:
> 
> On 8 Jan 2014 17:06, "Georg Brandl"  >
> 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"  > 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).

Not sure how that is different from converting everything to str and then
converting back after manipulation -- what people want is seamless and efficient
working with the "native" type for sockets, files etc.

But I haven't read up these threads, and I hope a PEP will come out of that as
well.

> 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.

Well, even if it works I just hope that wouldn't lead to everyone just using the
new type and leaving bytes to rot.

Georg

___
python-committers mailing list
[email protected]
https://mail.python.org/mailman/listinfo/python-committers

Re: [python-committers] clinic churn after beta2

2014-01-08 Thread Nick Coghlan 
On 9 Jan 2014 02:34, "Georg Brandl"  wrote:
>
> Am 08.01.2014 11:08, schrieb Nick Coghlan:
> >
> > On 8 Jan 2014 17:06, "Georg Brandl" >
> > 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"  > > 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).
>
> Not sure how that is different from converting everything to str and then
> converting back after manipulation -- what people want is seamless and
efficient
> working with the "native" type for sockets, files etc.

And that's what I'm saying we *can't* do, because it would put us back in
the position of favouring ASCII compatible binary protocol development over
normal application code. Is network protocol handling an important use
case? Absolutely. However, the core data model needs to continue to push
people strongly towards converting binary data to text or another more
structured format rather than manipulating the raw bytes directly.

I think PEP 460 is a potentially reasonable idea as a way of helping a
couple of specific projects port over, but I also think it's a change that
doesn't actually make it substantially easier to write binary protocol
handling code in Python 3 in general (the impact on urllib.parse is exactly
zero, for example).

There has been a near complete and total lack of experimentation with ways
of making binary protocol development in Python 3 fun and straightforward,
and, as near as I can tell, this has been due to people insisting on only
using the core types, even though we've been suggesting for years that a
new, more specialised type may be needed (perhaps based on memoryview, or
at least the PEP 3118 buffer API).

I can't blame the people doing the conversions for that - not only am I one
of them, but conversions to date have mostly been done based on necessity
(stdlib) or due to user demand (third party libraries and frameworks)
rather than the "just for fun" style of development that leads people to
build the infrastructure they need rather than waiting for someone else to
do it for them.

> But I haven't read up these threads, and I hope a PEP will come out of
that as
> well.

At this point we need experimental code on PyPI that aims to prove that Py3
can be just as fun for binary protocol manipulation *today* far more than
we need proposals to change Python 3.5.

> > 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.
>
> Well, even if it works I just hope that wouldn't lead to everyone just
using the
> new type and leaving bytes to rot.

No, because any new type should *only* be used for ASCII compatible binary
protocols. That's an important use case (especially for web protocols), but
still just a subset of the overall space of binary formats.

The folks like Armin Ronacher that are currently complaining are the ones
that really liked having such a type as a builtin and aren't interested in
understanding why we decided it was a seriously problematic default choice.
Since they don't have a vested interest in Python 3 (Python 2 works
perfectly well for binary protocol h