[Python-ideas] from __past__ import division, str, etc

[Nick Coghlan]

On 9 January 2014 01:05, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On 9 January 2014 00:57, Alejandro López Correa <alc at spika.net> wrote:
>> Hi,
>>
>> I'm new here. I am sorry if this idea has already been discussed, but I have
>> not found a way to search this list (I am not used to mailing lists at all).
>>
>> I've seen recently some discussion in reddit about python 2 vs python 3, and
>> the slow adoption of the latter. I am proposing here pragmatic way to speed
>> up the process of porting old code and thus solving the split in the
>> community, that I believe it is a serious threat. It is not clean, not at
>> all, but it might work: just give python 2 whiners what they [we] want, and
>> do it using "from __past__ import", in a similar way "from __future__
>> import" is used.
>
> Hi,
>
> You may want to read through
> http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html
> before lending too much weight to ill-informed Reddit commentary.

My apologies, that was rather rude of me when you're offering to help
(I'm irritable at the moment since I've deemed it necessary to spend a
bunch of time over the past week updating my Python 3 Q & A rather
than enjoying my Christmas holidays, working on Python 3.4 or, this
week, enjoying linux.conf.au 2014).

Anyway, the problems impacting wire protocol developers are known, but
it's been damnably difficult to get anything other than "I like Python
2 better" out of them when it comes to discussing possible *solutions*
(although even the descriptions of the problems have been useful in
guiding some changes over the course of the 3.x series). The primary
pain point for developers of binary protocol manipulation code is that
the Python 2 text model was *right* for boundary code that converts
binary data to text or structured data. However, it's wrong for
basically everything else, which is why we changed it for Python 3.

The main challenge is thus getting people to stop asking the question
"How do we bring back the Python 2 text model" (which is never going
to happen - we changed the model for a reason), and instead ask "What
changes can be made to Python 3, such as introducing additional
purpose specific types, to make it a better language for wire protocol
development?". There's nothing actually *saying* "thou shalt only use
builtin types for manipulation of wire protocol data", but that's the
way all porting efforts have been carried out to date.

As part of addressing that, it's likely that certain kinds of Python 2
code will become easier to port to Python 3, but the bigger issue is
to actually try to improve wire protocol development in Python 3
rather than getting stuck on just recreating the deeply flawed Python
2 model.

I put some possible ideas for improvements at
http://python-notes.curiousefficiency.org/en/latest/python3/questions_and_answers.html#is-python-3-more-convenient-than-python-2-in-every-respect,
but what we really need at this point is some *experimentation* with
possible approaches (especially new types like asciiview and
asciibytes).

Regards,
Nick.

>
> Cheers,
> Nick.
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia



-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia