We Keep Coding

Documentation for python base classes?

This has got to be a silly question... but googling didn't actually help. Extra kudos for pycharm enabled answers. :)
I need a simple little UDP echo server (spare me the twisted advertisements please, this is a throw away thing, I just need to use it to peek at what a little embedded gadget is broadcasting). So I find section 21.21 of the Python 3 reference manual. It's a simple example that does exactly what I want.
But the same document also mentions a DatagramRequestHandler class. But there's no further explanation on how that differs from its parent class, or what it provides. I had really hoped that when I imported said class, that pycharm would somehow display a helpful popup for it, but I'm unable to discover such a thing.
Do I assume correctly, that I should just go find the source in my (macosx) install and look directly at that? is there a pattern for how people do that? My actual question here, is actually less about DatagramRequestHandler, and more about the general pattern, because this obviously will happen else where in the base docs.
(context: my traditional experience is with Smalltalk image based environments, where you can always just jump from class to class to class, and navigate quickly from application code all the way to the bowels, as a sort of exploratory way of learning and discovery)

There is an option to navigate to the declaration of the name under your cursor, Navigate->Declaration (shortcut CTRL+b in my keymap).

If you have such a question there are three things to do:
google it (eg. python DatagramRequestHandler)
use the help function in a interactive python session. eg.
import socketserver; help(socketserver.DatagramRequestHandler)
look into the code
Most of the time the first option is enough (this time I found only something in german). The result from the second option is in this "example" not so interesting or useful. So you have to use try third option.

Changing GUI library : QT, wxPython... anything else?

Actually working on a project in python with PyQT, we choose to create widgets that were "unpleasant" or that didn't have a good enough behaviour.
So, we finally found that QToolbox, QDate and some others had a behaviour non acceptable for the project, so we had to adapt these.
We had also to create a complete new widget : A scheduler.
As we were creating these, it has been decided that it took too much time. So we were asked to think about other libraries.
I actually found a project of a scheduler in wxPython, that actually looks like what we want ( but we believe that we'll have to adapt it a lot ). Here it is : http://code.google.com/p/wxscheduler/
So, I ask everyone that have some more experience than me in GUI programming in python : Do we need to start again the project in anything other than PyQT? I know the question is weird, but what you need to know is :
The project has now been going on for 2 months
I know only PyQT, and started working in python 2 month ago
We are currently 3 in the project, and we currently know only PyQT
We have currently managed a lot of the PyQT widgets, and were starting to code these new widgets.
Please help us =)
Thanks
Edit : I should have add that the project is opensource and multi-platform

Feel free to look at other libraries if you like. Robin Dunn, the creator of wxPython, recently started working on PySide and he found it somewhat similar to wx, so you might find that wxPython will fit your brain fairly well too. I certainly think wx's class names are more intuitive than PyQt's. The only way to know for certain is to actually experiment a little and see if it works. I will say that the wxPython community is one of the best Python communities I've dealt with over the years.

One possibility would be to use an HTML scheduler control via QtWebKit. If your UI can accommodate a QWebView in the place where you'd otherwise have a custom scheduler widget, there are probably a number of excellent scheduler widgets (implemented as jQuery plugins, etc.) you could choose from.

we choose to create widgets that were "unpleasant" or that didn't have
a good enough behaviour.
Why don't you create "pleasant" widgets ?
so we had to adapt these.
Yes. It is the solution.
it has been decided that it took too much time
Don't you think it would take much more time if you change the whole GUI API ?
As for i know, there is not such native Scheduler in any Python GUI library, especially one you could use with Qt. I don't think it would be so long to recreate one, unless you have very specific needs, that would confirm you wouldn't find a such existing thing in an existing library.
Concerning wxScheduler, i guess you can have a look to the code, even it uses wxWidget and you're working with Qt, to get an idea how to do it.

Sublime Text editor plug-in, scan div id's and classes

I'm aware I'm supposed to show some starting code to give you a clue as to what I'm trying to do, but I'm really at a basic level and I can't find any resources to show me what I'm after. Basically, I'm trying to write a plug-in for Sublime Text editor, which selects all div ID's then outputs them into a file. What's the best approach? It seems like it should be easy, but I'm not too sure.
Thanks in advance for your help,
Ewan

This looks like a good place to start: http://www.sublimetext.com/docs/plugin-basics

Look at http://www.sublimetext.com/docs/2/api_reference.html, though be advised that Sublime Text 3 is currently in beta. It introduces changes to the plugin api, and a requirement to support Python 3. See http://www.sublimetext.com/docs/3/porting_guide.html

Assuming you have some familiarity with python, I would start with this tutorial on for writing plugins (Link). The author of that tutorial wrote, among other things, package control. Granted, it is for ST2, but for what you are trying to do, I don't for see any major issues with writing a plugin that is compatible with both ST2 and ST3.
How you go about writing your particular plugin is up to you. One approach may be leveraging the view.find_all() method. This takes a regular expression and returns a set of regions. From these regions, you can grab the text, and subsequently the IDs for the divs. There may be a better way, but that might work as an initial attempt. Writing to a file can be done through the usual python means.

With WXPython when is it necessary to use classes?

I'm very new to python and i have some stupid question, thank you for helping!
when I search online about wxpython questions, I see almost 100% of the people use class for wxpython. From the book i learnt, the author didn't mention using class for wxpython, instead he gave us a few examples that didn't use class.
I just want to know, when is it good to use class and when is it really not so necessary.

You will need to use a class to overwrite the behavior of an existing Widget.
Many tutorials online start by using a custom extension of wx.Frame as the base window for the application, but in fact there is no real reason to do that.
If you are satisfied with everything that widgets normally provide out of the box there is no reason to use classes - in fact you should avoid Object Oriented Programming as much as possible. Using a more functional approach will result in cleaner code and less troubles.

In wxPython, you should use classes whenever you want to extend the functionality of something wxPython provides to you.
A lot of wxPython apps at the very least define a class inheriting from wx.Frame to serve as the main GUI. If you need to add special behavior to certain widgets (e.g. add a method to wx.Button), you might also want to write a class for that. Lastly, some special features in wxPython (like tabbed GUIs or wizards) require you to write a class for each page.
There's a lot of cases where you need to write a class. You almost always need to at least write one class for your main frame. Other than that, it depends on what kind of problems you're trying to solve.
I'm not sure what book you read, but if you haven't already I'd recommend wxPython in Action, which is really the definitive guide to wxPython.

WxPython differences between Windows and Linux

The tutorials I've found on WxPython all use examples from Linux, but there seem to be differences in some details.
For example, in Windows a Panel behind the widgets is mandatory to show the background properly. Additionally, some examples that look fine in the tutorials don't work in my computer.
So, do you know what important differences are there, or maybe a good tutorial that is focused on Windows?
EDIT: I just remembered this: Does anybody know why when subclassing wx.App an OnInit() method is required, rather than the more logical __init__()?

I've noticed odd peculiarities in a small GUI I wrote a while back, but it's been a long time since I tried to the specifics are a rather distant memory. Do you have some specific examples which fail? Maybe we can improve them and fix the bugs?
Have you tried the official wxPython tutorials? ...or were you after something more specific?
r.e. your edit - You should use OnInit() because you're subclassing wx.App (i.e. it's a requirement for wxWidgets rather than Python) and the wxPython implementation is wherever possible, just a wrapper for wxWidgets.
[Edit] Zetcode has a fairly lengthy tutorial on wxPython. I've not looked through it all myself, but it might be of some help?
The wxWidgets::wxApp::OnInit() documentation is fairly clear:
This must be provided by the application, and will usually create the application's main window, optionally calling wxApp::SetTopWindow. You may use OnExit to clean up anything initialized here, provided that the function returns true.
If wxWidgets didn't provide a common interface then you'd have to do different things in C++ (using a constructor) compared to Python's __init__(self,...). Using a language-independent on-initialisation allows wxWidgets ports to other languages look more alike which should be a good thing right? :-)

EDIT: I just remembered this: Does anybody know why when subclassing wx.App an OnInit() method is required, rather than the more logical __init__()?
I use OnInit() for symmetry: there's also an OnExit() method.
Edit: I may be wrong, but I don't think using OnInit() is required.

I find a number of small differences, but don't remember all of them. Here are two:
1) The layout can be slightly different, for example, causing things to not completely fit in the window in one OS when the do in the other. I haven't investigated the reasons for this, but it happens most often when I use positions rather than sizers to arrange things.
2) I have to explicitly call Refresh more in Windows. For example, if you place one panel over another, you won't see it the top panel in Windows until you call Refresh.
I general, I write apps in Linux and run them in Windows, and things work similarly enough so this is a reasonable approach, but it's rare for me when something runs perfectly straight out of the gate after an OS switch.