Am 08.01.2014 11:08, schrieb Nick Coghlan: > > On 8 Jan 2014 17:06, "Georg Brandl" <g.bra...@gmx.net > <mailto:g.bra...@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" <e...@trueblade.com > <mailto:e...@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 _______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers
