[Python-Dev] PEP 461: Adding % formatting to bytes and bytearray -- Final, Take 3
Nick Coghlan
ncoghlan at gmail.com
Sat Mar 29 22:51:48 CET 2014
On 30 March 2014 07:01, Ethan Furman <ethan at stoneleaf.us> wrote:
> On 03/29/2014 11:59 AM, Antoine Pitrou wrote:
>
>> On Sat, 29 Mar 2014 11:53:45 -0700 "Gregory P. Smith" wrote:
>>>
>>>
>>> I understand that sentiment but that is an unjustified fear. It is not a
>>> good reason not to do it. Projects are already trying to port stuff today
>>> and running into roadblocks when it comes to ascii-compatible bytes
>>> formatting for real world data formats in code needing to be 2.x
>>> compatible. I'm pulling out my practicality beats purity card here.
>>
>>
>> "Roadblocks" is an unjustified term here.
>
>
> It's actually quite appropriate: to get around a physical roadblock you
> would have to leave the road, forge through lumpy ground and stinging
> nettles, and then get back on the road.
>
> A very good analogy, actually. ;)
I tend to call them "barriers to migration". Up to Python 3.4, my
focus has been more on general "barriers to entry" for Python 3 that
applied as much or more to new users as they did to existing ones -
hence working on getting pip incorporated, providing a better path to
mastery for the codec system, helping Larry with Argument Clinic,
helping Eric with the simpler import customisation, trying to help
improve the integration with the POSIX text model, assorted tweaks to
make the type system more accessible etc.
I think Python 3.4 is now in a pretty good place on that front,
particularly with Larry stating up front that he considers the ongoing
rollout of Argument Clinic usage to be in scope for Python 3.4.x
maintenance releases.
So for 3.5, I think it makes sense to focus on those "barriers to
migration" and other activities that benefit existing Python 2 users
more so than users that are completely new to Python and starting
directly with Python 3. Binary interpolation is a big one (thanks
Ethan!), as is the proposed policy change to allow network security
features to evolve within Python 2.7 maintenance releases.
Our community has done a lot of work to support us in our goal of
modernising and migrating a large fraction of the ecosystem to a new
version of the language, even though the full implications of the
revised models for binary and text data turned out to be more profound
than I think any of us realised back in 2006 when Guido first turned
the previously hypothetical "Py3k" into a genuine active effort to
create a new revision of the language, better suited to the global
nature of the 21st century.
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-Dev
mailing list