Developers have been pushing for some time that we drop support for legacy installations (Python2.7 and 32bit Windows) because it makes things harder to maintain.
My own sense is that some users want or need these, but it is getting harder to support them. Below are some of the reasons I know about, but chip in if you know more reasons (especially reasons that we need prolonged support).
On balance, my feeling is that we should soon drop support for legacy options soon (maybe in release 3.1.0), unless I hear arguments otherwise.
Known reasons to drop 32bit support
Iām currently adding support for a new keyboard/USB lib and audio lib (same code as in psychtoolbox) that should dramatically improve timing of both. These libs only support 64bit Windows.
The releases pages are getting rather confusing for users because of all the possible downloads for each version
Known reasons to drop Python2 support
On Mac this has already essentially stopped being supported because it failed to compile recently and I havenāt worked out why
On windows, I could technically build a 64bit Python3 release but it feels like thatās too many options
We are also currently avoiding some recent nice features of newer Python versions (like the nicer formatted strings) because of supporting Python2 at the same time
Known reasons to keep dual support
Currently the pyo audio lib is only 32bit windows, but this will probably change soon, and even if it doesnāt the new lib from psychtoolbox should make it redundant
the iolabs button box definitely doesnāt have a Python3 so weād be effectively dropping support for that, but it hasnāt been made for years and, as far as I can tell from google, everyone else dropped support long ago.
Much to my chagrin, the Eyelink 1000 eye-tracking system only fully supports PsychoPy with Python 2.7. They are beginning to support Python 3 with PsychoPy, but the software is in beta phase and they donāt recommend using it for āserious data collectionā. This seems like an issue that would affect many users, so it seems worth considering as a reason to keep dual support.
Py2.7 end of life doesnāt itself bother me. That just means no updates to Python (and itās a year away, which doesnāt mean we need to end support now). Iām looking for practical issue one way or other
The next version of pyo (which we currently use for microphone) will apparently have 64bit windows wheels and already support Py3/Py2 so thatās not an issue
Potential issues:
eyetracker (and other hardware?) support. @sol you probably know best who to speak to at SRR. Could you see what their thoughts/plans are?
I think we certainly need to drop support for 32-bit Python but not 2.7 just yet. However, we need to make it clear that you need the 64-bit version of Python, since the default download on https://www.python.org/ is the 32-bit version.
I really would like to take advantage of features provided by Python 3.6+ when working on core PsychoPy modules.
I think this is a good point. Supporting so many configurations makes the release process more difficult and takes up time that could be better spent on fixing bugs or adding features. And needing to span Python 2 and 3 limits potential productivity of the developers.
I think an ideal outcome might be to make solid final releases for both Python 2.7 and 32 bit, on all platforms. Itās not like ceasing development for them means that people canāt still continue to use those releases well into the future, including with older hardware that might or might not be updated to support Python 3.
The current rate of rapid development is being driven by the online capacities, and presumably those users arenāt concerned by these Python platform issues. Meanwhile, the biggest current issues facing ālegacyā users are probably ones to do with audio and video dependencies. Maybe some of the audio issues at least might be resolved by incorporating the PsychToolbox code from Mario (with the improved keyboard handling too, at least for 64 bit Python 2.7)? Maybe that is a natural point to say that the legacy releases are on a firm footing and should be usable on current studies for a few years, but those with needs for new features need to make the jump to Python 3/64 bit?
From my perspective, as long as existing releases of psychopy arenāt going away, making new development only available in modern versions of python sounds perfect to me.
Me raising the issue now is actually mostly driven by the psychtoobox (PTB) libs. Yes, Iām confident they will very much improve timing in both audio and keyboard.
Iām doubtful that I can make the PTB audio code work on 64bit at all, and the keyboard code isnāt currently working there either (will take a fair bit of effort for me to work out why).
Iād like to make these new libs (PsychHID and PsychPortAudio) a part of PsychoPy3.1. If we do want to support Py2.7 or 32bit windows for PsychoPy3.1 then well need to write PsychoPy Builderās keyboard to make a decision about which keyboard calls to use (whereas if we drop support for 2.7 then we write the Builder Keyboard only to use the superior PTB keyboard).
That might be an incentive to use 64-bit if users get better features and support. Since PsychoPy falls under scientific computing, where people may need as much system RAM as possible for working with arrays (images, audio and movie clips, trial data, etc.), it might be worth encouraging the move. There are several posts where people report memory errors when creating experiments with images and movies, something people shouldnāt need to worry about.
I would support the idea of freezing 32-bit/Python 2.7 version and doing bugfixes only on it, while the 64-bit/3.6+ version gets fixes and features.
Sorry, yes, I might not be able to get Psychportaudio working on 32 bit windows at all.
OK, well for me I think this comes down to hardware. Iād we can get support for 64bit windows from people like SRResearch then great. Otherwise we might need to struggle on for a bit with dual option.
FWIW @mdc Iām not actually sure the video issue is fixed by 64bits I think its most likely a bug with a leak rather than a genuine memory problem. It always occurs for people at 120 videos as far as I can tell
While I will likely be using old Python 2.7 versions of Psychopy for years, ceasing support in new versions doesnāt bother me if the Eyelink issue is sorted out.
Just out of interest, Alex, what is your driving consideration there? (Iām the same, for an established longitudinal study that is using an incredibly old version of PsychoPy, running under Windows XP, but wonder what would lead others to do the same.)
Since SMI eye trackers are no longer supported, I donāt think the old SMI SDK will work with Python 3.
So anyone working with an SMI eye tracker will have to stick to Python 2.7.
SMI eye trackers can be controlled via simple direct UDP network messaging, you donāt need to go via the SDK. Iāve recently updated our internal modules that do that from Python 2 to 3. I could release those for anyone that wants them. Although the code includes functions closely based on our own idiosyncratic lab protocols, it does allow control over most eye tracker features simply by sending text messages like ET_REC, ET_STP, etc to the eye tracker PC. It includes interactive calibration, where PsychoPy draws a calibration target and shifts it around the screen in response to calibration instructions from iView.
