[python-committers] clinic churn after beta2

[Nick Coghlan]

On 9 Jan 2014 02:34, "Georg Brandl" <g.brandl at gmx.net> wrote:
>
> 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.

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 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/20140109/2e33c691/attachment-0001.html>