[TIP] Dropping Python 3.2 support for various projects
rharding64 at yahoo.com
Sun Oct 25 14:41:50 PDT 2015
we don't use anything newer than 2.7.x at my company, too many inconsistencies and changes abound beyond.
Sent from my iPad
> On Oct 25, 2015, at 3:31 PM, Robert Collins <robertc at robertcollins.net> wrote:
>> On 23 October 2015 at 21:32, Laura Creighton <lac at openend.se> wrote:
>> In a message of Thu, 22 Oct 2015 23:22:36 +0200, Laura Creighton writes:
>> Turns out I was mistaken. 3.3 is far from done. There seems to be
>> too little overlap between 'people who use PyPy' and 'people who use
>> Python 3' to generate enough volunteers for getting later 3.x
>> support into PyPy. And there isn't enough money in the pot to
>> hire somebody to do this. Of course, the more your 3.x lags, the
>> more difficult it is for 3.x users to use PyPy, so we don't expect
>> a hoard of new 3.x users to decend on the place any time soon.
>> Would it be possible to get a pinned version for PyPy only so that
>> people who are testing against PyPy can continue to do so?
> I don't think an externally pinned version is needed: folk can locally
> do this as needed.
> For instance, in project X, if you use coverage, then you'd have deps
> like so for your testing:
> coverage<4:python_version>="3" and python_version<"3.3"
> coverage:python_version<"3" or python_version>="3.3"
> And so on for any other deps when they drop 3.2 support. If that
> becomes overwhelming, or project X doesn't see pypy3 as a thing they
> want to directly support, then the next project downstream of X can do
> the same thing in their requirements files.
> Robert Collins <rbtcollins at hp.com>
> Distinguished Technologist
> HP Converged Cloud
> testing-in-python mailing list
> testing-in-python at lists.idyll.org
More information about the testing-in-python