On Wed, Jan 8, 2014 at 3:40 AM, M.-A. Lemburg <mal@egenix.com> wrote:
PS: The PEP mentions having to code for Python 3.0-3.4 as well, which would don't support the new methods. I think it's perfectly fine to have newly ported code to require Python 2.7/3.5+. After all, the porting effort will take some time as well.
tl;dr We must get the relevant library projects involved in this discussion. I prefer Nick's solution to the problem at hand. <disclaimer> I've mostly stayed out of this discussion because I neither have many unicode-related use-cases nor a deep understanding of all the issues. However, my investment in the community is such that I've been following these discussions and hope to add what I can in what few places I chime in. :) </disclaimer> Requiring 3.5 may be tricky though. How soon will 3.5 show up in OS distros or be their system Python? Getting 3.5 on their system may not be a simple option for some (perhaps too few to matter?) and may be seen as too onerous to others. This effort is meant to ease porting to Python 3 and not as just a carrot like most other new features. It boils down to 3.5 being *the* target for porting from 2.7. Otherwise we'd be better off adding a new type to 3.5 for the wire-protocol use cases and providing a 2.7/3.x backport on the cheeseshop that would facilitate porting such code bases to 3.5. My understanding is that is basically what Nick has proposed (sorry, Nick, if I've misunderstood). The latter approach makes more sense to me. However, it seems like this whole discussion is motivated by a particular group of library projects. Regardless of what we discuss or the solutions on which we resolve, we'd be making a mistake if we did not do our utmost to ensure those projects are directly involved in these discussions. -eric