On 9 Jan 2014 02:34, "Georg Brandl" <g.bra...@gmx.net> wrote: > > 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.
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 handling on POSIX systems, and even Windows for many web use cases, especially for devs that have long ago mastered the rough edges of the Python 2 model), it's natural that their reaction is "I will just use Python 2" and "the core developers don't understand Unicode". That doesn't make them right, but it *does* mean taking the time to make sure we fully understand the aspects that are causing pain and explore genuine alternatives for addressing them, rather than blindly adding back deeply, deeply error prone constructs that are a frequent source of data corruption when provided as builtins rather than as advanced tools you only reach for when you know you need them. Cheers, Nick. > > Georg > > _______________________________________________ > python-committers mailing list > python-committers@python.org > https://mail.python.org/mailman/listinfo/python-committers
_______________________________________________ python-committers mailing list python-committers@python.org https://mail.python.org/mailman/listinfo/python-committers