OO on python real life tutorial?

[filippo]

Hello,

I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.

My problem is that I cannot figure out how OO could be useful in my
case. Is there a OO tutorial out there to help me?

Thanks,

Filippo

[Fredrik Lundh]

"filippo" wrote:

I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.

My problem is that I cannot figure out how OO could be useful in my
case. Is there a OO tutorial out there to help me?

How many do you need ? ;-)

Here's Jay Parlar's proposed class intro for the python tutorial:

http://pytut.infogami.com/node11-baseline.html

I haven't seen them myself, but the related ShowMeDo videos might be
helpful:

http://showmedo.com/videos/series?na...IPython_JerolH

See also chapters 12-16 in "How to Think Like a Computer Scientist":

http://www.ibiblio.org/obp/thinkCSpy/

</F>

[Claudio Grondi]

filippo wrote:

Hello,

I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.

My problem is that I cannot figure out how OO could be useful in my
case.

Be warned, that I am a bit biased here and my opinion is probably not
mainstream, but I think OO won't be useful in your case, so there is no
reason to learn about it.
A row by row porting will be ok, but if I were you, I would use probably
Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths with growing project sizes, but
yours is still far below the threshold).
Consider it that way: if you cannot figure out how OO could be useful,
just be more self-confident and accept the enlightenment, that it
probably or even for sure can't.

Claudio Grondi
Is there a OO tutorial out there to help me?

>
Thanks,

Filippo

[filippo]

thanks Fredrik and Claudio,

probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?

Claudio Grondi ha scritto:

Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths with growing project sizes, but
yours is still far below the threshold).

I want to switch to wxpython because I don't like Tk too much. It is
difficult sometimes to have full control of the widgets (i.e. focus
sequence). Why do you think wxwidget is not suitable for low-medium
size projects? Could you give me some practical examples of this?

Thanks and best regards,

Filippo

[filippo]

Fredrik Lundh ha scritto:

How many do you need ? ;-)

(snip)

thanks Fredrik,

I know there are plenty of tutorials and manuals. I know what classes,
inheritance and polymorphism are. My problem is that I cannot figure
out how they can help me in my practical problem (my software). The
only things I can imagine is to create some objects like "customer" but
all I can do is to try to force the object to act like my "structured
way of thinking" the problems.

I will read your links, however.

Thanks,

Filippo

[Diez B. Roggisch]

filippo schrieb:

thanks Fredrik and Claudio,

probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?

Claudio Grondi ha scritto:

>Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths with growing project sizes, but
yours is still far below the threshold).

I want to switch to wxpython because I don't like Tk too much. It is
difficult sometimes to have full control of the widgets (i.e. focus
sequence). Why do you think wxwidget is not suitable for low-medium
size projects? Could you give me some practical examples of this?

You shouldn't take that advice too serious. He does not know much about
your project, yet still he advices you to discard OO - that is just
preposterous. His advice regarding the toolkit - well, you seem to have
experienced difficulties in tk, so ditch it if you like.

While OO isn't the silver bullet, it certainly has its merits, and to be
honest: I can't believe that there exist many 10k lines of code programs
with database access and the like that don't gain from using OO principles.

Of course you can create data structures that fit your need - dicts and
lists. But the least OO gives you is to name these, for better
understanding. E.g.

class Hotel(object):
def __init__(self, name):
self.name = name

def __str__(self):
return "<Hotel: %s>" % self.name

which won't work better from a functional point of view than

{hotel_name = "Funny Horse House"}

But the type Hotel then introduces better readability, especially for
others.

The very moment you have code that looks like this:
if hotel["type"] == 'whatever':
do_something_with_whatever(hotel)
else:
do_something_with_rest(hotel)

overloading will come to use, and OO plays out its strength:

class Hotel(object):
def __init__(self, name):
self.name = name

def __str__(self):
return "<Hotel: %s>" % self.name

def do_something(self):
pass
class WhateverHotel(Hotel):
def do_something(self):
# we're doing something completely different here
pass
Then you just do

hotel.do_something()

So the code hasn't to know anything about the possible differences in
hotel types.

I've been doing an online hotel reservation system, btw, and I assure
you: OO was very helpful, even in its crappy PHP incarnation.

Diez

[filippo]

Diez B. Roggisch ha scritto:

I've been doing an online hotel reservation system, btw, and I assure
you: OO was very helpful, even in its crappy PHP incarnation.

thanks Diez,
I'll keep trying OO paradigm. Probably the advantages will be clearer
to me porting to python my app.

Best regards,

Filippo

[Claudio Grondi]

filippo wrote:

thanks Fredrik and Claudio,

probably structured coding paradigm is what I need. Claudio, could you
explain better your sentence below?

Claudio Grondi ha scritto:

>>Python/Tk for it in order to avoid programming in wxPython if not really
necessary (wxPython has its strengths with growing project sizes, but
yours is still far below the threshold).

I personally don't like wxPython because the way it works is very
counter intuitive for me and appear to me somehow non-Pythonic (I warned
you, I am a bit biased to have something against OO, especially I mean,
that the concept of inheritance produces more confusion than it helps).
You are not in a big project with many programmer who must work together
- in my eyes the only context in which OO starts to make sense. You also
don't need something what Tk does not come with to be forced to switch
to wxPython (e.g. in order to use Scintilla). wxPython is like
programming in Microsoft Visual Basic or Visual C++ : some love it, some
don't. Nothing comes at no cost, so when from the one side you don't
need to care about some portions of code on the other side you loose
insight into them and in case of bad luck you will spend days/weeks on
resolving things and bother much other experts to help you, where in
case of not going into it you were able to resolve your problems yourself.

I want to switch to wxpython because I don't like Tk too much. It is
difficult sometimes to have full control of the widgets (i.e. focus
sequence). Why do you think wxwidget is not suitable for low-medium
size projects? Could you give me some practical examples of this?

I haven't said, that it is not suitable. Maybe you consider it from this
point of view:
The best programming environment is this one you know best.
You don't like Tk because you have learned about it quirks. So you hope
to escape this using another set of tools coming with a bunch of another
quirks you probably don't know about. If you want to go into the
effort to learn about them anyway, why not? Maybe you have the luck and
don't spend hours/days/weeks on debugging things buried deep in the OO
inheritance stuff and hidden this way from your direct insight? Good luck!

Claudio Grondi

[filippo]

Claudio Grondi ha scritto:

(megasnip)

I caught your point of view. I start reading a book on wxpython to
understand if it can help to solve my problems. At the same time I will
port my program to Python/Tk in order to have a faster first beta
release.

Thanks for your explanation.

Filippo

[Ron Adam]

filippo wrote:

Hello,

I coded my +10k lines app using Perl/Tk. It is something like a hotel
software manager, it has a bunch of windows to manage the arrivals,
bills etc etc. I want to port this on Python/WxPython but I'd like to
get benefit of python, not just doing a row by row raw porting.

My problem is that I cannot figure out how OO could be useful in my
case. Is there a OO tutorial out there to help me?

Thanks,

Filippo

One of the nice things about python is you can easily mix 00 and
structured programming styles together as you need.

I would also suggest separating you data structures which can either be
in 00 or structured tables from your interface. The interface can
definitely benefit from being in OO.

If you tie your data too tightly to your interface, it will make
maintaining and or switching interfaces later a lot harder.

So you will have two groups of OO structures One for your data and one
for your interface, and those can be in separate files.

I don't know much about hotel management, but you might have a table of
records, where each table object is a room, or area, that is a group
of stuff to be managed together.

Your data structures would be along the line of...

(Very roughly to give you an idea of where you might start.)

class record(object):
attributes to store info about an object
needing to be managed.
...

class table(object):
list of records that consist of an "area of
responsibility" to be managed together such as the
items in a room.
...
methods to add, remove, get, and search table.
...

class hoteldata(object):
list of tables
...
methods to add, remove, get, search tables.
...
methods to generate report and graph data,
but not methods to display such data, those would
be in the interface group.
Each record may consist of the individual things in that area. Where an
area is "an area of responsibility" that is to be assigned to an
individual and or needs to be handled together.

And your interface OO structures would then consist of your widgets,
windows, and forms you need in order to view, add, update, and delete
records.

It may not be too difficult to reorganize your current program into one
of this type as you will probably just be regrouping many of your
functions into class's to handle your records and tables.

This is more of an accounting approach where you are using OO to model
lists and records, and not a simulation where you would use OO to
actually model the objects which can also work, but is much harder to do.

Cheers,
Ron

[Patrick Thomson]

I personally don't like wxPython because the way it works is very

counter intuitive for me and appear to me somehow non-Pythonic

While Claudio has a point (wxPython is a C++ library at heart), I
believe that wxPython is the best solution for Python GUI's out there.
TK may be a lot easier, but with a little practice wxPython becomes
very clear, and the skills you learn therein will be applicable to
almost any other GUI toolkit out there (Swing and SWT were far, far
easier to learn thanks to my wxPython experience.) After all, GvR said
that "wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first."

The Wax toolkit (http://zephyrfalcon.org/labs/wax.html) attempts to
solve the problems inherent with wxPython and make it more pythonic.
I've never used it, so I don't know if it succeeds.

wxPython is like programming in Microsoft Visual Basic or Visual C++ :
some love it, some don't.

Though that is true, I don't think that the analogy holds up at all.
The power of wxPython lies in its attractiveness across all platforms
and the freedom that it gives you; VB and VC++ lock you in what
Microsoft want you to do. (To be fair, that isn't a Bad Thing by
definition.)

I want to switch to wxpython because I don't like Tk too much. It is
difficult sometimes to have full control of the widgets (i.e. focus
sequence). Why do you think wxwidget is not suitable for low-medium
size projects? Could you give me some practical examples of this?

I respectfully disagree with Grondi's opinions; a list of notable
wxPython projects (http://wiki.wxpython.org/index.cgi/wxPythonPit_Apps)
showcases projects both small and expansive.

--

Patrick Thomson

[Robert Hicks]

filippo wrote:

Claudio Grondi ha scritto:

(megasnip)

I caught your point of view. I start reading a book on wxpython to
understand if it can help to solve my problems. At the same time I will
port my program to Python/Tk in order to have a faster first beta
release.

Thanks for your explanation.

Filippo

Have a look at wxGlade if you want to do some windowing prototyping:

wxglad.sf.net

HTH

Robert

[Claudio Grondi]

Patrick Thomson wrote:

>>I personally don't like wxPython because the way it works is very
counter intuitive for me and appear to me somehow non-Pythonic

While Claudio has a point (wxPython is a C++ library at heart), I
believe that wxPython is the best solution for Python GUI's out there.
TK may be a lot easier, but with a little practice wxPython becomes
very clear, and the skills you learn therein will be applicable to
almost any other GUI toolkit out there (Swing and SWT were far, far
easier to learn thanks to my wxPython experience.) After all, GvR said
that "wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first."

The Wax toolkit (http://zephyrfalcon.org/labs/wax.html) attempts to
solve the problems inherent with wxPython and make it more pythonic.
I've never used it, so I don't know if it succeeds.

>>wxPython is like programming in Microsoft Visual Basic or Visual C++ :
some love it, some don't.

Though that is true, I don't think that the analogy holds up at all.
The power of wxPython lies in its attractiveness across all platforms
and the freedom that it gives you; VB and VC++ lock you in what
Microsoft want you to do. (To be fair, that isn't a Bad Thing by
definition.)

>>>I want to switch to wxpython because I don't like Tk too much. It is
difficult sometimes to have full control of the widgets (i.e. focus
sequence). Why do you think wxwidget is not suitable for low-medium
size projects? Could you give me some practical examples of this?

I respectfully disagree with Grondi's opinions; a list of notable
wxPython projects (http://wiki.wxpython.org/index.cgi/wxPythonPit_Apps)
showcases projects both small and expansive.

What I can't understand here is, with which of my opinions you disagree
as one line below of my posting (you are responding to) I write: "I
haven't said, that it is not suitable [for low-medium
size projects]." ...

By the way: why is it so hard to develop a wxPython application which
runs with any wxPython version? Are the subsequent wxPython versions by
definition not compatible or do only the quirks change from release to
release being shifted between the problem zones?

Claudio Grondi

[bearophileHUGS]

Patrick Thomson:

After all, GvR said that
"wxPython is the best and most mature cross-platform GUI toolkit,
given a number of constraints. The only reason wxPython isn't the
standard Python GUI toolkit is that Tkinter was there first."

The Wax toolkit (http://zephyrfalcon.org/labs/wax.html) attempts to
solve the problems inherent with wxPython and make it more pythonic.

Wax is quite nice. A complete and improved (made even simpler and
cleaner, copying other ideas from Tkinter too) Wax may be good to
replace/mount side by side Tkinter in future (3.0?) Python
distributions. Often it's a work of designing easy to use APIs.

Bye,
bearophile