However, the implicit conversions are *critical* to sharing constants between the two code paths in Python 2 without coercing bytes to str or vice-versa (disabling the implicit coercion breaks Unicode handling), so I'm still not sure the goal is achievable without creating a new type *specifically* for that task.

">

(original) (raw)


On 9 Jan 2014 22:08, "Antoine Pitrou" <solipsis@pitrou.net> wrote:
\>
\> On Thu, 9 Jan 2014 09:03:40 -0500
\> Daniel Holth <dholth@gmail.com> wrote:
\> > They emphatically do not want the Python 2
\> > model especially not implicit coercion. They only want additional
\> > tools for text or string processing in Python 3.
\>
\> That's a good point. Now it's up to people who need those additional
\> tools to propose them. We can't second-guess everyone's needs.

Note that I've tried to find prettier ways to write the standard library's URL parsing code. In addition to the original alternatives I explored, I'm currently experimenting with a generic function based approach with mixed results.� I'm reserving judgement until I see how the completed conversion looks, but currently it doesn't seem any simpler than my current higher order function approach.

However, the implicit conversions are \*critical\* to sharing constants between the two code paths in Python 2 without coercing bytes to str or vice-versa (disabling the implicit coercion breaks Unicode handling), so I'm still not sure the goal is achievable without creating a new type \*specifically\* for that task.

Python 3 only code is generally much simpler - you can usually pick binary or text and just support one of them, rather than trying to support both in the same API.

Cheers,
Nick.

>
\> Regards
\>
\> Antoine.
\> \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
\> Python-Dev mailing list
\> Python-Dev@python.org
\> https://mail.python.org/mailman/listinfo/python-dev
\> Unsubscribe: https://mail.python.org/mailman/options/python-dev/ncoghlan%40gmail.com