I have some code developed in Python, which makes heavy use of Python 3 language features, such as f-strings (which require Python 3.6 or later).
Due to a customer commission I have found myself in the situation that this code needs to run on Windows Server 2003. Python has officially dropped support for legacy versions of Windows sometime around the release of Python 3.5.
Is there a "port" (I guess this would be the best way to call it) of Python 3.6 to legacy Windows, or does anyone have a good idea of how to get my code to run without doing too much heavy lifting?
Related
I am using VS code for python development. I had to disable python language server and enable jedi to fix an excessive RAM consumption problem with python language server. Many people encountered similar problems when you search on Google.
What is the difference between jedi and python language server?
I am using Windows 10 64-bit, python 3.7.3.
Jedi is an auto-completion library written in Python while the language server is implemented in C#. The latter was done for performance and to share a common code base between the Python extension for VS Code and the Python workload of Visual Studio. Eventually the language server will become the default experience in the Python extension for VS Code.
As for the memory issues, they are being actively worked on, so do make sure you are trying a new version of the language server (0.2.65 is the latest as of this writing). And if you are still having memory issues please file issues as appropriate.
Does PyPy support the aio and Python 3.5?
I need the performance of PyPy and asynchrous code of asyncio. Also I need to use async/await in my code. Is that possible?
If so, what are the nuances?
The current version of PyPy (version 7.2.0 at the time of writing) supports asyncio on at least Linux and Windows.
Old, now outdated (as of 2019-10-20) notes:
Currently there is a PyPy version (v7.0) compatible with Python 3.5 and a beta version (v7.1.1) compatible with Python 3.6. Both versions support asyncio on Linux (and probably macOS, but I didn’t try myself), but only the latter supports asyncio on Windows.
Old, now outdated (as of 2019-04-16) notes:
Currently PyPy supports Python 3.5, so asyncio should just work. However Python 3.x on Windows is still beta-quality. Unfortunately currently the extension module for overlapped IO, which is needed to run asyncio on Windows, isn't yet implemented.
Old, now outdated (as of 2018-06-10) notes:
Currently PyPy supports Python 3.5. Note that PyPy's Python 3 support is only beta quality in the moment. We are continuously working on improving it. It's not yet production-ready, though. Most code involving asyncio should just work. If not, please check the open bug reports or create a new one or let me know here in the comments.
Old, now outdated (as of 2017-08-18) notes:
Currently PyPy supports Python 3.3. This means that you can install asyncio on PyPy3.3. Note that PyPy's 3.3 support is only alpha / beta quality in the moment. We are however actively working on increasing performance and compatibility with CPython.
The async / await feature was added in Python 3.5. We started a very experimental branch with Python 3.5 support, but it's still got a long way to go. Luckily we have a GSoC student working on it currently, but still it could take several years (depending on how much donations and volunteer work we receive).
EDIT 1: Previously there was a feature missing to run asyncio. It was implemented shortly before this edit. The answer was edited accordingly.
EDIT 2: We just released an alpha version of PyPy3.3. We don't recommend anyone to try the old PyPy3 release supporting only Python 3.2. This is why I rewrote most of the answer.
Old, now obsolete (as of 2016-05-30) notes:
The PyPy3 version from the website is very old and only implements Python 3.2 - we haven't done a release for over one and a half year. Because Python 3.2 is missing the yield from feature, asyncio won't work with this version.
No. According to PyPy website it is only Python 3.2.5 compliant, while asyncio requires Python 3.4 (actually can be installed using pip on 3.3, thanks #dirn). Also on Asyncio Wiki, it is stated that asyncio doesn't work on PyPy yet (though Wiki was last updated in August 2015).
I want to use PyPy with Python 2.6. The default version (PyPy 1.4.1) seems to be 2.5 when downloading binaries. Google doesn't seem to be helping much, advice?
You can download a nightly build if one exists for your platform. They support Python 2.7 and an official release with this support is supposed to happen in the next days, as PyPy developers are sprinting at PyCon right now.
Edit: As of 2012, PyPy stable releases support Python 2.7 and there is ongoing effort to support 3.x.
If you use an OS for which no nightlies are available, you can still build PyPy from source using latest code from Mercurial. You'll need a somewhat beefy machine for that and building on Windows (specially 64 bits) has a couple of hurdles to clear, so you might want to join #pypy in freenode if that is what you need.
I have a lovely Macbook now, and I'm enjoying coding on the move. I'm also enjoying coding in Python. However, I'd like to distribute the end result to friends using Windows, as an executable.
I know that Py2Exe does this, but I don't know how portable Python is across operating systems. Can anyone offer any advice? I'm using PyGame too.
Many thanks
The Python scripts are reasonably portable, as long as the interpreter and relevant libraries are installed. Generated .exe and .app files are not.
Py2exe generates Windows executables, so they will only work on the Windows Platform. The FAQ at http://www.py2exe.org/index.cgi/FAQ has more information on how it all works. Essentially it provides what is needed to run on Win9x as well as more current platforms. NOTE: the FAQ mentions some potential gotchas with character encodings and the work arounds.
With python, it is common enough on Unix based systems, as several Linux distributions have their custom maintenance scripts written in the language. So the Python scripts will be just as portable as Ruby scripts, etc. As long as the target machine has the interpreter and you are not using external programs that are only on one type of platform, others will be able to use your work.
Personally I experienced huge difficult with all the Exe builder, py2exe , cx_freeze etc. Bugs and errors all the time , keep displaying an issue with atexit module.
I find just by including the python distro way more convinient. There is one more advantage beside ease of use.
Each time you build an EXE for a python app, what you essential do is include the core of the python installation but only with the modules your app is using. But even in that case your app may increase from a mere few Kbs that the a python module is to more than 15 mbs because of the inclusion of python installation.
Of course installing the whole python will take more space but each time you send your python apps they will be only few kbs long. Plus you want have to go to the hussle of bundling the exe each time you change even a coma to your python app. Or I think you do , I dont know if just replacing the py module can help you avoid this.
In any case installing python and pygame is as easy as installing any other application in windows. In linux via synaptic is also extremly easy.
MACOS is abit tricky though. MACOS already come with python pre installed, Snow leopard has 2.6.1 python installed. However if you app is using a python later than that and include the install of python with your app, you will have to instruct the user to set via "GET INFO -> open with" the python launcher app which is responsible for launcing python apps to use your version of python and not the onboard default 2.6.1 version, Its not difficult and it only takes a few seconds, even a clueless user can do this.
Python is extremely portable, python pygame apps cannot only run unchanged to the three major platform , Windows , MACOS ,Linux . They can even run on mobile and portable devices as well. If you need to build app that runs across platform , python is dead easy and highly recomended.
If you are planning to include Linux in your portability criteria, it's worth remembering that many distributions still package 2.6 (or even 2.5), and will probably be a version behind in the 3.x series as well (I'm assuming your using 2.x given the PyGame requirement though).
Versions of PyGame seem to vary quite heavily between distros as well.
I'm trying to write an application that should work both on Windows 98 and XP. I decided to go with Python, but I'm having trouble even installing it on Win'98 (Python 2.7 installer says something about missing features of Windows Installer, but AFAIK 2.0 is the latest Windows Installer version compatible with '98).
Does anyone have a working Windows 98 environment with Python and wxPython? How did you make it work? I don't need Python 2.7, but a 2.4 or 2.5 would be nice.
If not, what other high-level language would you suggest that is actively maintained, can display Windows widgets and works with Windows 98? (asm/C/C++ and other low-level languages are out of question -- this is a simple application whose main job is to display windows and dialogs).
I'm pretty sure we used Python2.4 and wxPython on '98 way back when.
I don't have a win98 machine to test it on, but it looks like at least Python2.5.4 binaries are available for win98
I think win98 support may have been dropped for 2.6
wxPython download page says this
Microsoft Windows
The Win32 version of wxPython is
distributed as a set of standard
self-installing executables. This
allows you the convenience of using
the Start Menu and Add/Remove Programs
just like any other Windows software.
There are two versions of wxPython for
each of the supported Python versions
on Win32. They are nearly identical,
except one of them has been compiled
with support for the Unicode version
of the platform APIs. Unless you've
been told differently, you probably
want to get the Unicode build of
wxPython. Although they are not
nativly Unicode like NT-based systems,
the Unicode build of wxPython will
also mostly work on Windows 98/Me
systems using a Microsoft hack called
MSLU (or unicows.dll) that translates
unicode API calls to ansi API calls.
However the coverage of the API is not
complete so there are some difficult
bugs lurking in there, so the best
thing to do is to upgrade your
machines if possible, otherwise
Windows 98/Me users may want to try
the ANSI build instead.
and they are still release installers for Python2.5
Yes, Python droped Win9x/NT support at version 2.5.4.
However there are alternates builds: http://www.msfn.org/board/topic/162317-python-27-for-windows-95/