On 21May2019 1621, MRAB wrote: > Does it behave nicely with py.exe? This is still something of an open issue with the Store package for Python - py.exe doesn't look for the registry keys in a way that will find them (due to some very obscure compatibility quirks). The Store package does not include py.exe though, so this only comes up if you install a second copy with the regular installer. And that would have to be a 3.8 alpha release to have any chance of getting the fix, since if you install a 3.7 release along with the 3.7 Store package then the regular install is likely going to shadow the Store package anyway, and I wasn't planning on adding to 3.6's launcher at this stage. So far I haven't heard much feedback about this being a real issue - it's almost all been theoretical questions rather than "why did py.exe just fail?" issues. I expect they'll come up, and when they do I'm sure they'll point towards a good solution. > Earlier this year I installed an extension in Visual Studio Code for > programming Arduino. It installed its own version of Python 2.7 (I'm on > Python 3) and changed the file associations to point to that, thus > breaking my scripts. (I wasn't keen on its customised icons, either.) I > was somewhat unhappy at that... The Store package should change otherwise unassigned file associations to point at it when it is installed. If you already have file associations, you might get a prompt next time you double-click a .py file, but it shouldn't just steal them. Cheers, Steve
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4