I'm using pygame with python 2.6 right now, But I want to use python 3.1.1 instead. The normal pygame only works with 2.x, but the subversion ones work with 3.x I think. But what about pgreloaded? Is that useable yet? The normal pygame actually works with 3.1 too, but not for os x (at least there isn't a download). Does anyone actually use pgreloaded or subversion pygames? So anyway, should I use pygame subversion, pgreloaded, or stick with the current pygame? I don't really care about being compatible with other things or distribution.
Thanks!
EDIT: Ok, I got rid of python 2.6, installed 3.1, used svn command to get pygame, tried running python3 setup.py, didn't work, changed raw_input in setup.py to input(), worked, now my pygames (that were so simple that they work the same under 2.6 and 3.1) run with python 3.1. :) I didn't get pgreloaded because there's no documentation for it.
Just stick with Python 2.6.
pgreloaded has documentation - there is even an own package at http://code.google.com/p/pygame/downloads/list.
I think JD's link to pgreloaded doc is out of date, try this one:
http://wiki.pgreloaded.googlecode.com/hg/documentation/index.html
Or consider using Pyglet (http://pyglet.org/), which is a thin wrapper around openGL, esp. made for games. It works pretty well, documentation is reasonable, but it of course lacks the massive userbase that Pygame has. It is more mature than PGreloaded imho.
Related
I want to use Qt5 and QtQuick2 with a binding such as PyQt, but it seems the only builds available for PyQt are for Python 3.3. Are there any bindings I can use with Python 2.7?
I assume you're talking about binary installers for Windows. The maintainer of PyQt5 has made it very clear that he will not be providing them for PyQt5/Python2:
>>> Are there any Windows binary installers for PyQt5 and Python 2.7?
>>
>> No, and I don't intend to provide any.
>
> Thanks. Any particular reason?
Incompatibilities between dependencies and compiler versions - there would be no support for QtWebKit.
I'm trying to limit the total number of installer I maintain.
I'm doing my bit to encourage people to move to Py3.
PyQt5 for Py2 is fully supported, so there is nothing to stop anybody
else doing the work.
So you'd better have a very good reason for insisting on using Python2 with PyQt5, because you'll be commited to either maintaining Windows builds yourself, or relying on a third party to do it for you.
If you do a little web-searching, you will find a few binary installers out there, as well as instructions/tutorials for buidling them yourself. But I'm not going to endorse any of them here, because I haven't tried any of them myself (and have no intention of doing so).
How would I use 2 different python mods in the same file when both mods require different python versions? I am trying to write a program that uses pygame, which only works with 3.2 and pymssql, which only works with 3.3. I get errors if I try to run them both in the same file(on either python version), but not if I run them separately.
There is no simple solution for you. In my opinion, it is the pygame communitie's responsibility to make it work on Python 3.3. Python 3.3 has a higher potential to be widely distributed than Python 3.2. Also, "supporting Python 3" nowadays should mean supporting Python 3.3/3.4, and not only Python 3.2. I guess this is on the todo list of the pygame maintainers. If in doubt, you might want to ask on the corresponding forums/mailing list if supporting Python 3.3 is already planned.
If you are curious and not frightened, you might event want to dig into why pygame fails on Python 3.3 and start fixing issue by issue. I guess this effort will be highly appreciated.
Edit:
I was assuming that you did your research homework a bit :-) Looks like pygame is available for Python 3.3:
https://bitbucket.org/pygame/pygame/downloads
Thanks #batbrat.
This topic is in response to a problem I've been having getting Pygame to be set up correctly on my computer. I have Windows 7, Python 3.3 and "64-bit" Windows (now I know what a bit and a byte are, but I don't really understand the implications of having a "64-bit" computer) I'm proficient in Python but know nothing about binaries, dependencies, registries or other such internal/system-level structures; not that I'm not interested, but at the moment most of what goes on is essentially "over my head".
But anyway, with that said, the problem I've been experiencing is basically that I can't install pygame. I've been over several versions of the same question (on Stack Overflow and other places on the web), and I've attempted to install pygame countless times. Sometimes it seems to work fine until I attempt to use it (the installation appears to have been successful but Python gives me errors when I try to use pygame), or I get something about Python 3.3 not being in my "registry" (which from what I read appears to be another OS-level/internal structure for those who understand "the base code of the universe"). They could actually develop a series of tutorials on just the installation process. :)
But all joking aside, I am at a loss here and considering just giving up on pygame. So my question would be, is there any way to use what's already installed (Python's libraries etc.) to develop games? If not, do you know of any alternatives that don't require the same level of experience to install? I've Googled around but everything I've found about game design in Python leads back to pygame. Thanks in advance.
To save yourself pain, just use 32bit python, and 32bit pygame. If you mix 32 and 64 bit, it will not run correctly. That's probably the problem you're having.
Since you have python 3.3, you would use https://bitbucket.org/pygame/pygame/downloads/pygame-1.9.2a0.win32-py3.3.msi
You shouldn't have to edit the registry or your environmentvariables unless something goes wrong.
As mentioned previously, tkinter would offer a solution. For example, this was created in tkinter (http://www.youtube.com/watch?v=RHxLkNryOzI)
The pygame downloads page hasn't been updated for a while and is incompatible with python 3.x. Newer versions of pygame can be downloaded here.
I'd personally use pygame as there's audio support as well but tkinter could be used.
Can I use Python 2.7 modules from Python 2.6? Or do something to achieve the same effect?
I'm limited to use Python 2.6, but an issue exists in the subprocess module provided by Python 2.6. This is fixed in Python 2.7. I'm curious if I rig this up using pip (or equivalent) to sidestep the bug temporarily until upgrading one day. How would I go about doing this?
Yes, usually. The difference between 2.6 and 2.7 isn't very big, as 2.7 is supposed to be a bridge between 2.6 and 3.0. As a result, most Python modules for 2.7 will work in both of these versions (usually better in 2.6 than 3.0).
Of course, the only surefire way to know the answer is to try!
EDIT: To be clear, I do not recommend that you do this at all, if you have a choice.
Hacking around a Python installation just because of a Python bug in one module is a bad idea.
If you really want to stay on Python 2.6, but also want to fix this bug, I might suggest compiling Python 2.6 from source, but also applying the relevant bug fix code to the subprocess module from 2.7.
You will end up with a custom build of Python 2.6. Of course, if you're stuck on the standard 2.6 because you are unable to install any different version, then this won't help.
Etienne Perot suggested using a Python 3.2 subprocess backport available at http://code.google.com/p/python-subprocess32/ instead of hacking around the Python installation.
This let me install the module into my virtual environment's site-packages, and patch the subprocess code with http://hg.python.org/cpython/rev/767420808a62 to fix the bug mentioned in question. Afterwards, a simple import subprocess32 as subprocess fixed the problem.
I bought a low-end MacBook about a month ago and am finally getting around to configuring it for Python. I've done most of my Python work in Windows up until now, and am finding the choices for OS X a little daunting. It looks like there are at least five options to use for Python development:
"Stock" Apple Python
MacPython
Fink
MacPorts
roll-your-own-from-source
I'm still primarily developing for 2.5, so the stock Python is fine from a functionality standpoint. What I want to know is: why should I choose one over the other?
Update:
To clarify, I am looking for a discussion of the various options, not links to the documentation. I've marked this as a Community Wiki question, as I don't feel there is a "correct" answer. Thanks to everyone who has already commented for their insight.
One advantage I see in using the "stock" Python that's included with Mac OS X is that it makes deployment to other Macs a piece of cake. I don't know what your deployment scenario is, but for me this is important. My code has to run on any number of Macs at work, and I try to minimize the amount of work it takes to run my code on all of those systems.
I would highly recommend using MacPorts with Porticus for managing your Python installation. It takes a while to build everything, but the advantage is that whatever you build yourself will be built against the same libraries, so you won't have to futz around with statically linked shared objects, etc. if you want your Python stuff to work with Apache, PostgreSQL, etc.
If you choose to go this way, remember to install the python_select port and use it to make your system use the Python installed from MacPorts.
As an added bonus, MacPorts has packages for most main-stream Python eggs, so if you should be able to have MacPorts keep you up-to-date with the latest versions of all that stuff :)
Here's some helpful info to get you started. http://www.python.org/download/mac/
Depends what you are using python for. If you are using MacOS funitionality and things like PyObjC you are probably best of with MacPython or the python provided by Apple.
I use Python on my Mac mostly for development of server side applications which later will run on FreeBSD & Linux boxes. For that I have used fink python for a few years and ever since MacPorts python. With mac ports it is simple to add required c modules (like database driver etc). It's also easy to keep two python Versions (2.5 & 2.6 in my case) around.
I used "compile your own" python to test pre-3.0 python but generally I find managing dependencies to c modules painfull if done by hand.
Thanks to easy_install installing pure python modules is fast and easy for all the options mentioned above.
I was never very much an IDE person. For development I use command line subversion installed by MacPorts, Textmate and occasionaly Expandrive do directly access files on servers. I personally are very dependent on Bicyclerepairman for Textmade to handle my refactoring needs.
Others seem to be very happy with Eclipse & Pydev.
How about EPD from Enthought? Yes, it's large but it is a framework build and includes things like wxPython, vtk, numpy, scipy, and ipython built-in.
I recommend using Python Virtual environments, especially if you use a Timecapsule because Timecapsule will back everything up, except modules you added to Python!
Based on the number of bugs and omissions people have been encountering in Leopard python (just here on SO!), I couldn't recommend that version. e.g., see:
Why do I get wrong results for hmac in Python but not Perl?
Problems on select module on Python 2.5
I would choose MacPorts.
It does not eliminate your existing python supplied by Apple since it installs by default in /opt/local/bin (plays nice with it) and plus it is easy to download and install additional python modules (even binary modules that you need to compile!). I use Porticus GUI to maintain my MacPorts installed list of packages, including python.
In my windows environment I use Eclipse and PyDev, which works quite well together, even if it's a bit sparse. Apparently the exact same environment is available for the Mac as well, so I suggest downloading Eclipse and using the internal update software function to update PyDev with the URL http://pydev.sourceforge.net/updates/. To look further into PyDev, look here.
Apple's supplied python is quite old – my tiger install has 2.3.5. This may not be a problem for you, but you would be missing out on a lot. Also, there is a risk that Apple will update it. I'm not sure if moving from 2.3.5 to (say) 2.4 would cause code to break, but I guess it's possible. This happened to perl people recently: http://developers.slashdot.org/article.pl?sid=09/02/18/1435227
Macpython is a framework build (as is Apple's, I believe). To be honest, I'm not sure exactly what that means, but it's a prerequisite for some modules, in particular wxPython. If you get python from macports or fink, you will not be able to run wxPython (unless you run it through X11).
And guess what was forgotten by every answer here ... ActivePython.
No compilation required, even for third-party modules such as numpy, lxml, pyqt and thousands of others.
I recommend python (any python?) plus the ipython shell. My most recent experience with MacPython was MacPython 2.5, and I found IDLE frustrating to use as an editor. It's not very featureful, and its' very slow to scroll large quantities of output.