How to integrate Pyglet with Twisted/Asyncio? - python-3.x

How can I integrate a Python-Pyglet game with either Twisted or Asyncio?
I was going to ask a more general question, like "How can I add networking to a Python-Pyglet game?", but when doing any kind of web-search, "all roads lead to Twisted", anyway. However, both Pyglet and Twisted have their own event-loop, and it's not clear how they can be integrated. None of the other answers I've found, have more detail than "use Twisted", either.
Twisted does have a list of libraries it integrates with, including GUI ones like WxPython, but Pyglet is not on the list. I read one article that said Pyglet was going to be integrated with Twisted - from 2008, so I'm not holding my breath.
There is a pyglet-twisted library, but it's five years old on Github. There's no version information, but the sample-code has Python-2 print statements, so I'm guessing it's out-of-date. Using Pyglet and Twisted together
Same for Asyncio, which I also looked at - it has its own event-loop. Although Pyglet docs do have some information about doing a custom event-loop, I'm not sure how well it plays with others. I'd actually prefer using Asyncio, if it's feasible to get them to play nicely together.

You could get a quick win by basing code off of pigtwist and convert Py2 to Py3 syntax. Which doesn't look like a whole lot. There's also the crochet package that runs twisted in it's own thread, which you could run the network stack on. I also found this example, which uses a coiterator approach.
Hopefully pyglet will incorperate asyncio into itself given that it's a pure Python library. Maybe file a ticket with the team?

Related

Contributing to unmaintained reactor in Twisted or maintain separate implementation?

Future Edit
As of twisted 15.5.0 and kivy 1.9.1, the kivy implementation works on python3. I also use AMP, which is not yet in the release but was merged 2 months ago and will be in the next twisted release.
Introduction
I'm developing an app using Kivy and plan to extend it using multi-processing and, more importantly Twisted. The app has a master component and a slave which should be controllable from various masters, including over a network (hence twisted).
Kivy has it's own twisted support code (in kivy/support.py called instal_twisted_reactor) which works in python2 but doesn't in python3 due to the unported status of the _threadedselect reactor.
I've hacked a port of twisted/internet/_threadedselect.py to python3 which is sufficient to run the kivy example code (one server GUI and one client GUI sending text). Normally I'd then go for a pull request upstream, but there's a few more factors in play:-
_threadedselect.py is, as best as I can tell, unmaintained in twisted, and in fact was last even mentioned on their mailing list back in 2006 (as a candidate for removal)
The twisted requirements for python3 porting include appropriate unit tests, and I don't have to knowledge (networking wise especially) to write appropriate unit tests for this reactor
I do not know whether any other project (besides kivy) even uses _threadedselect.py
Main Question
Given the above, is it advisable to put in the effort to get _treadedselect.py patched upstream (and henced ported to python3)? Or would it be more efficient to maintain a separate implementation in my own project (or optionally contributed to kivy's project).
Disclaimer: I'm (obviously) not a maintainer for either project
Non-essential details:
Kivy isn't the most popular UI base in python, hence it doesn't have a twisted maintained reactor (a la GTK, QT, TK etc.), but its the best fit for what I want to do. I've considered tornado etc. but that's really a matter for another question.
Also, the modifications needed are (so far) really minor. queue to Queue, zope interface decorators, except using as rather than comma, and using the function next rather than using a generator's next method.
Thank you for your interest in contributing to the Twisted ecosystem. I hope I can clear up your confusion so you can move forward.
First of all, Kivy is a very important Python library, and one we at the Twisted project definitely care about (I'm super happy to hear you're using them together!) so you are mistaken if you believe that Kivy doesn't have a reactor simply because it "isn't the most popular UI base in python"; the only reason it doesn't have a reactor in Twisted is that nobody contributed one.
There are a couple of possible ways forward, but they depend on some technical details you haven't covered in your question, and one SO answer is probably not enough to resolve the conflict; you will probably want to join the Twisted mailing list and discuss this there.
Regardless of the Python 3 port, _threadedselect is a private API, with no compatibility contract, and Kivy should not be using it. So in order to move forward, this will need to change. However, it is unlikely to be removed, as it is internally the basis of the wxpython reactor, which is a public API distributed with Twisted, and will eventually need to be ported to python 3 itself to complete the port.
The first way forward would be to improve _threadedselect's test coverage and make it a public API again. This strikes me as not necessarily the best move, because getting the thread interaction correct is very tricky and I would not want to encourage people - even people dealing with low-level enough implementation details to want to implement a reactor - to do it that way if any other options were available. However, if _threadedselect had a valid use-case within Kivy, and an advocate willing to do some maintenance work, this is definitely plausible.
The second way forward would be to create a reactor based on an internal socket-monitoring API within Kivy. Is there one? Most of the UIs which Kivy is a wrapper over (CoreFoundation, X11, Windows) do have socket-monitoring of some kind built in. Can Kivy tap into that, possibly? This is less error-prone than threading, if you can manage it, but sometimes it's impossible; I don't see any directly exposed APIs in Kivy for this. If you could develop such a thing it could be within Twisted or within Kivy depending on your preference.
I hope to hear from you in a more discussion-oriented forum soon :)

python3 tkinter or ncurses

I want to impliment some kind of UI for my Python programs (some simple operations, nothing advanced).
So I looked around and considered ncurses and tkinter for python. Yet I am not sure which of these two would suit best my needs for a simple interface (in the sense of easy to learn to program) with the best output possibilies. It does not have to be fancy or anything, just help me visualise my code (lets say a text based chess game).
intuitively i would take tkinter, but could you probably just summarise for me the advantages of the two UIs? (in addition ncurses does not seem to have a good tutorial for python...)
Thank you in advance!
I would like to suggest tkinter as it comes with python and compare to other GUI packages it has good tutorials. And also it will help you to improve your OOP concept for python
If you plan on using your application across platforms, Tkinter or PyQt are both good choices. If you want a GTK+ application that matches your GNOME environment and don't plan on using the application on other platforms, then I would suggest using GTK+ via gobject-introspection (from pygobject). In Fedora, you should have support for it out of the box. Other distributions may require the installation of additional packages.
For more information on the above bindings, see:
TkDocs
The Python GTK+ 3 Tutorial
(Sorry I couldn't post a link for PyQt because I don't have enough reputation to post more than 2 links.)
Additionally, it's worth noting that both PyQt and GTK+ have interface designers available so that you don't have to create your interfaces programmatically if you don't want to. For PyQt I believe Qt Creator comes with an interface designer. For GTK+ you have Glade.

New-style Signal and Slot Support, PyQt

I'm writing a GUI application with PyQt4 (Python3). One my friend pointed out that using pyuic4 is a bad practice and referred me to uic module and Connecting Slots By Name features. He didn't have time to explain more and the references I have are rather short, I couldn't grasp the idea from them (uic module, LoadingUIFilesAtRuntime, connecting slots by name).
On StackOverflow there is at least one related question but the links to the literature are broken there.
I could follow standard tutorials and did simple GUI using pyuic, but now feel a little bit confused... Any good examples and/or references are welcome.
Firstly, using pyuic4 is certainly not "bad practice".
There are three main ways to get PyQt4 UI's into your code:
Write it all by hand yourself
Use pyuic4 to auto-generate a python module that can be imported
Use the uic package to load ui files directly at runtime
Of these, the first two are by far the most common, and most documentation, tutorials, advice, etc that you will come across will use those methods.
A good source for PyQt4 tutorials can be found in this section of the PyQt4 Wiki. However, I should probably point out that, although still relevant, many of them are quite old and so still use the old-style signals and slots.
However, the difference between the old- and new- styles is not that difficult to understand, so maybe a simple example is all that's needed.
Here's the old-style way to connect a button-click signal to a handler method (aka slot):
self.connect(self.button, QtCore.SIGNAL('clicked()'), self.handleButtonClick)
and here's the new-style way:
self.button.clicked(self.handleButtonClick)
As you can see, the new-style is much simpler and more pythonic. On the other hand, the old-style is quite similar to how signals are connected using C++ (and for this reason can still be useful in certain circumstances).
If you have problems with connecting signals when writing your GUIs, you can always ask a question here - but it's much easier to get good answers if you ask specific questions that include example code.

How to Be Python 3 Ready?

What are the current rules for writing python code that will pass cleanly through 2to3 and what are the practices that seem to be best suited to writing code that will not become mired forever in version 2.
I have read from the SciPy/NumPy forums that "100% test coverage" (unit testing) is important for many people, and I am not sure if that would apply to everybody. Certainly having a reasonable set of unit tests to try your code out with after conversion, seems a sane step.
Are there other things? What are skilled Pythonistas doing if they are writing 2.x code that they hope to have come through "cleanly" in the 2to3 process.
I am looking for specific instances of "[don't] do this" as well as some more general "best-practices", but specific instances of "do's and don'ts" are helpful.
Let's assume that frameworks, libraries (Django, SciPy/NumPy), and every other C Extension we need gets ported to Python3 eventually, and I'm asking about how you write and maintain the pure python language code that you write yourself.
Update: It's possible that what I really want is the "style guide" and list of deprecated features that everybody was already staying away from. I cut my teeth on Python 1.5 and moved to 2.0, and then have not really followed much of the 2.5/2.6 era, used them but really my code is more 2.1 era.
I'd say:
Read the "What's new for Python 3.0". Very informative.
In particular, if you care about Unicode or text encodings at all, take the time to understand what has changed for 3.x. That's probably one of the trickier things to change for Python 3.x.
Get Python 2.6 or 2.7, and run your code with the -3 flag. It will tell you about things in your code that will need changing.
Before using 3rd-party packages, check to see if they have a Python 3.x version. If not, check the package web site, mailing lists, version control repositories etc to see how actively the package is being developed and whether there is a roadmap towards Python 3.x support.
Download Python 3.x and try it out! Admittedly, that might not be practical if you care about code that currently depends on packages that don't yet support Python 3.x (e.g. wxPython or Django).

The right language for OpenGL UI prototyping. Ditching Python

So, I got this idea that I'd try to prototype an experimental user interface using OpenGL and some physics. I know little about either of the topics, but am pretty experienced with programming languages such as C++, Java and C#. After some initial research, I decided on using Python (with Eclipse/PyDev) and Qt, both new to me, and now have four different topics to learn more or less simultaneously.
I've gotten quite far with both OpenGL and Python, but while Python and its ecosystem initially seemed perfect for the task, I've now discovered some serious drawbacks. Bad API documentation and lacking code completion (due to dynamic typing), having to import every module I use in every other module gets tedious when having one class per module, having to select the correct module to run the program, and having to wait 30 seconds for the program to start and obscure the IDE before being notified of many obvious typos and other mistakes. It gets really annoying really fast. Quite frankly, i don't get what all the fuzz is about. Lambda functions, list comprehensions etc. are nice and all, but there's certainly more important things.
So, unless anyone can resolve at least some of these annoyances, Python is out. C++ is out as well, for obvious reasons, and C# is out, mainly for lack of portability. This leaves Java and JOGL as an attractive option, but I'm also curious about Ruby and Groovy. I'd like your opinion on these and others though, to keep my from making the same mistake again.
The requirements are:
Keeping the hell out of my way.
Good code completion. Complete method signatures, including data types and parameter names.
Good OpenGL support.
Qt support is preferable.
Object Oriented
Suitable for RAD, prototyping
Cross-platform
Preferably Open-Source, but at least free.
It seems you aren't mainly having a problem with Python itself, but instead with the IDE.
"Bad API documentation"
To what API? Python itself, Qt or some other library you are using?
"lacking code completion (due to dynamic typing)"
As long as you are not doing anything magic, I find that PyDev is pretty darn good at figuring these things out. If it gets lost, you can always typehint by doing:
assert isinstance(myObj, MyClass)
Then, PyDev will provide you with code completion even if myObj comes from a dynamic context.
"having to import every module I use in every other module gets tedious when having one class per module"
Install PyDev Extensions, it has auto-import on the fly. Or collect all your imports in a separate module and do:
from mymodulewithallimports import *
"having to select the correct module to run the program"
In Eclipse, you can set up a default startup file, or just check "use last run configuration". Then you never have to select it again.
"before being notified of many obvious typos and other mistakes"
Install PyDev Extensions, it has more advanced syntax checking and will happily notify you about unused imports/variables, uninitialized variables etc.
Looking just at your list I'd recommend C++; especially because Code Completion is so important to you.
About Python: Although I have few experience with OpenGL programming with Python (used C++ for that), the Python community offers a number of interesting modules for OpenGL development: pyopengl, pyglew, pygpu; just to name a few.
BTW, your import issue can be resolved easily by importing the modules in the __init__.py files of the directory the modules are contained in and then just importing the "parent" module. This is not recommended but nonetheless possible.
I don't understand why nobody has heard of the D programing language?
THIS IS THE PERFECT SOLUTION!!!!
The only real alternative if you desire all those things is to use Java, but honestly you're being a bit picky about features. Is code completion really that important a trait? Everything else you've listed is traditionally very well regarded with Python, so I don't see the issue.
The text editor (not even an IDE) which I use lets you import API function definitions. Code completion is not a language feature, especially with OpenGL. Just type gl[Ctrl+I] and you'd get the options.
I tried using Java3D and java once. I realized Java3D is a typical Java API... lots of objects to do simple things, and because it's Java, that translates to a lot of code. I then moved to Jython in Eclipse to which cleaned up the code, leaving me with only the complexity of Java3D.
So in the end, I went in the opposite direction. One advantage this has over pure python is I can use Java with all of Eclipse's benefits like autocomplete and move it over to python when parts get unwieldy in Java.
It seems like Pydev can offer code completion for you in Eclipse.
I started off doing OpenGL programming with GL4Java, which got migrated to JOGL and you should definately give it (JOGL) a try. Java offers most of the features you require (plus Eclipse gives you the code completion) and especially for JOGL there are a lot of tutorials out there to get you started.
Consider Boo -- it has many of Python's advantages while adopting features from elsewhere as well, and its compile-time type inference (when variables are neither explicitly given a specific type or explicitly duck typed) allows the kind of autocompletion support you're asking about.
The Tao.OpenGL library exposes OpenGL to .NET apps (such as those Boo compiles), with explicit support for Mono.
(Personally, I'm mostly a Python developer when not doing C or Java, but couldn't care less about autocompletion... but hey, it's your question; also, the one-class-per-module convention seems like a ridiculous amount of pain you're putting yourself through needlessly).

Resources