[python-committers] clinic churn after beta2

[Georg Brandl]

Am 08.01.2014 11:08, schrieb Nick Coghlan:
> 
> On 8 Jan 2014 17:06, "Georg Brandl" <g.brandl at gmx.net <mailto: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
> <mailto: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).

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