wxPython


Todespreis

Member
Joined
Jun 16, 2021
Messages
87
Hey there again! What is wxPython? Okay, it's a runtime. But what the hell is a runtime? And what do i do with it? I mean, python works just right out of the house on pandora, does'nt it? So why do i need it? And when i want to do something with with PyGame, i have to provide my own libGL? What does that mean? I thought, there is only one Library of openGL. Okay, now you know, that i'm stupid and don't even know, what libraries are. Help! O.O"
 
A library is a pre-compiled piece of code. The idea is that you can re-use these parts of available code in your application.
It makes life easier as for example you don't need to create your own math functions you could just re-use them.
You can either statically link them to your application, so the code is just merged in your own application which makes your application a bit bigger.
Or you dynamically link them, so when the application is started it will require the external library. This also has the advantage that this library can be updated separately.
In Linux you might also see these dynamically linked libraries as .so (shared object) files and they usually reside in a /lib/ folder. LibGL is probably one of these files.

Python programs are usually not compiled into a static executable. Python is interpreted during execution of your program and can use wxPython code to create GUI's etc.
wxPython on Pandora is a handy package so you have Python + wxPython for the ARM platform.
 
A library is a pre-compiled piece of code
Not for python they ain't, unless you're arguing that python has no libraries. Python can preprocess files to remove comments and other extraneous test and these days appears to tokenise a lot of text too, leaving more or less on the help text and other strings as ascii, but libraries are generally shipped as source and you preprocess them when you run them.
The idea is that you can re-use these parts of available code in your application.
It makes life easier as for example you don't need to create your own math functions you could just re-use them.
You can either statically link them to your application, so the code is just merged in your own application which makes your application a bit bigger.
Or you dynamically link them, so when the application is started it will require the external library. This also has the advantage that this library can be updated separately.

In Linux you might also see these dynamically linked libraries as .so (shared object) files and they usually reside in a /lib/ folder. LibGL is probably one of these files.

Python programs are usually not compiled into a static executable. Python is interpreted during execution of your program and can use wxPython code to create GUI's etc.
wxPython on Pandora is a handy package so you have Python + wxPython for the ARM platform.
Yes, as far as I know the canonical place for libraries is /usr/lib, but debian and other distros softlink this to /lib. Archlinux doesn't so this however.
 
Not for python they ain't, unless you're arguing that python has no libraries. Python can preprocess files to remove comments and other extraneous test and these days appears to tokenise a lot of text too, leaving more or less on the help text and other strings as ascii, but libraries are generally shipped as source and you preprocess them when you run them.
That's indeed correct, all Python code is usually interpreted but some parts can be wrappers for C libraries. But in general python modules are regular uncompiled python code.
Libraries on Linux are usually pre-compiled as .so files. So if a Python wrapper is using a .so file it needs to have been compiled for the ARM platform to be used on Pandora.
 
Libraries on Linux are usually pre-compiled as .so files. So if a Python wrapper is using a .so file it needs to have been compiled for the ARM platform to be used on Pandora.
Yes, wxwidgets appears to be implemented by files like /usr/lib/libwx_base-3.0.so and /usr/lib/libwx_gtk3u*.so but perhaps more important for the authors of wxPython are the headers in /usr/include/wx-3.0/wx (which are .h files) but those are more or less machine readable files that document the interfaces you need to use to interface with the .so files. Those .so files will need to be written in the softfp dialect of ARM machine code. wxPython I'd expect to have a C component which #includes those header files and a python interface into that C code, and that C code will need to be compiled for the ARM platform as well. But that's normal on the Pandora, all files in /usr/bin and /usr/lib will be ARM machine code. But for all users of wxPython will only ever need to code Python to interface with that, which is more or less agnostic about which platform it's running on.
 
Back
Top