Re: [Tutor] Is it possible to tell, from which class an method was inherited from

[Peter Otten]

Jojo Mwebaze wrote:

> Thanks guys for the responses,
> 
> inspect.classify_class_attrs(klass)
> 
> does the magic

Argh, undocumented functions. How did you find that gem?

___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] How to plot graph?

[Walter Prins]

Hi Tee,

On 20 January 2011 03:48, tee chwee liong  wrote:

>  actually i just want to plot a simple x and y graph. any suggestion?
> how about using excel to plot? any sample code that i can follow to:
> 1) launch excel
> 2) read x-y from a text file
> 3) plot graph
>

Try this page:
http://www.blog.pythonlibrary.org/2010/09/27/wxpython-pyplot-graphs-with-python/

Lots of example there which should circumscribe what you want to do.

Walter
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Tutor] Tkinter in classes...why?

[Elwin Estle]

I have some experience in Tcl\Tk, and so far, Tkinter is striking me as harder 
to use that Tk in it's "native" environment.

I am attempting to re-write a program I originally did in Tcl\Tk in Python.  I 
managed to get a GUI done using just Tkinter, and, after an initial struggle 
with the Tkinter syntax (and especially the widget "naming" conventions),  had 
no problem getting widgets to display, etc.

But, the tutorials I have encountered all mentioned that it is supposed to be a 
good idea to put one's GUI stuff in a class, then create an instance of the 
class (which I don't entirely understand, since I thought the whole "class" 
thing was for stuff that you were gonna have a lot of, like similar records in 
a database or something, so you could use the class like a factory to spit out 
little copies of itself.

Anyway, when I attempted to convert my non-class based Tkinter code into a 
class, that's when the problems started.  I guess I still don't have a handle 
on all the "self.this's & self.that's", tho I have created some classes for the 
aforementioned database entry type stuff and haven't had too much trouble.

For starters, it seems like the first thing these class based tutorials do is 
to start with a frame inside the main Tkinter window?  Why?  Why not just grid 
stuff right into the window, instead of making a frame and gridding widgets 
into that.

Is the (self, master) thing in the __init__ section a convention, or is the use 
of the "master" a requirement?   Can you call it something else?  What is the 
purpose of doing an __init__ with a frame after having done __init__ with 
(self, master)?

All this in Tcl\Tk seems to me, in comparison, just dead nuts simple...but 
Tkinter...seems to have made unnecessarily complicated.  Maybe once I 
understand it, I won't think of it that way, but for now...whatta PITA!


  
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Tkinter in classes...why?

[David Hutto]

On Thu, Jan 20, 2011 at 2:43 PM, Elwin Estle  wrote:
> I have some experience in Tcl\Tk, and so far, Tkinter is striking me as 
> harder to use that Tk in it's "native" environment.
>
> I am attempting to re-write a program I originally did in Tcl\Tk in Python.  
> I managed to get a GUI done using just Tkinter, and, after an initial 
> struggle with the Tkinter syntax (and especially the widget "naming" 
> conventions),  had no problem getting widgets to display, etc.
>
> But, the tutorials I have encountered all mentioned that it is supposed to be 
> a good idea to put one's GUI stuff in a class, then create an instance of the 
> class (which I don't entirely understand, since I thought the whole "class" 
> thing was for stuff that you were gonna have a lot of, like similar records 
> in a database or something, so you could use the class like a factory to spit 
> out little copies of itself.
>
> Anyway, when I attempted to convert my non-class based Tkinter code into a 
> class, that's when the problems started.  I guess I still don't have a handle 
> on all the "self.this's & self.that's", tho I have created some classes for 
> the aforementioned database entry type stuff and haven't had too much trouble.
>
> For starters, it seems like the first thing these class based tutorials do is 
> to start with a frame inside the main Tkinter window?  Why?  Why not just 
> grid stuff right into the window, instead of making a frame and gridding 
> widgets into that.
>
> Is the (self, master) thing in the __init__ section a convention, or is the 
> use of the "master" a requirement?   Can you call it something else?  What is 
> the purpose of doing an __init__ with a frame after having done __init__ with 
> (self, master)?
>
> All this in Tcl\Tk seems to me, in comparison, just dead nuts simple...but 
> Tkinter...seems to have made unnecessarily complicated.  Maybe once I 
> understand it, I won't think of it that way, but for now...whatta PITA!

It's just like any other concept, at first it is a PITA, then it
becomes a normal utilization for your projects. Stick to your own
platform, and design for it, then expand for others in your portfolio.

>
>
>
> ___
> Tutor maillist  -  Tutor@python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>



-- 
The lawyer in me says argue...even if you're wrong. The scientist in
me... says shut up, listen, and then argue. But the lawyer won on
appeal, so now I have to argue due to a court order.

Furthermore, if you could be a scientific celebrity, would you want
einstein sitting around with you on saturday morning, while you're
sitting in your undies, watching Underdog?...Or better yet, would
Einstein want you to violate his Underdog time?

Can you imagine Einstein sitting around in his underware? Thinking
about the relativity between his pubic nardsac, and his Fruit of the
Looms, while knocking a few Dorito's crumbs off his inner brilliant
white thighs, and hailing E = mc**2, and licking the orangy,
delicious, Doritoey crust that layered his genetically rippled
fingertips?

But then again, J. Edgar Hoover would want his pantyhose intertwined
within the equation.

However, I digress, momentarily.

But Einstein gave freely, for humanity, not for gain, other than
personal freedom.

An equation that benefited all, and yet gain is a personal product.

Also, if you can answer it, is gravity anymore than interplanetary static cling?
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

[Tutor] If I use this code will it delete my program fileS?

[walter weston]

I have a question I know the shutil module deletes directories, If I use this 
code will it delete all of my program files?

import shutil
shutil.rmtree('C:\Program Files (x86)')
  ___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] If I use this code will it delete my program fileS?

[Wayne Werner]

On Thu, Jan 20, 2011 at 9:32 PM, walter weston wrote:

>  I have a question I know the shutil module deletes directories, If I use
> this code will it delete all of my program files?
>
> import shutil
> shutil.rmtree('C:\Program Files (x86)')
>


Assuming you have the proper permissions, yes.

An easy and safe(ish) way to test this would be to create a directory and
populate it with subdirectories and files, then try calling rmtree() on that
directory. Of course it's also safer to use forward slashes in your
directory. For instance, if you had rmtree('C:\test'), it will try to remove
the directory that has a tab character in it.

HTH,
Wayne
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor

Re: [Tutor] Tkinter in classes...why?

[Liam Clarke-Hutchinson]

Your signature is obscenely large David.

> But, the tutorials I have encountered all mentioned that it is supposed to
be a good idea to put one's GUI stuff in a class, then create an instance of
the class (which I don't entirely understand, since I thought the whole
"class" thing was for stuff that you were gonna have a lot of, like similar
records in a database or something, so you could use the class like a
factory to spit out little copies of itself.

You're creating an instance of a class, with all the state of that instance
relevant to only that instance. Consider an instance of a class to be a
convenient way of handling variable scope, I guess. Coming from Tcl to
Python will have some significant differences, I'm sure, but Python's OOP is
far more likely to be aligned to mainstream coding than Tk... give me a
second to google Tcl to determine if it has OO paradigms... ...okay, sorta
does.

> All this in Tcl\Tk seems to me, in comparison, just dead nuts simple...but
Tkinter...seems to have made unnecessarily complicated. Maybe once I
understand it, I won't think of it that way, but for now...whatta PITA!

Tcl is not Python. Fair enough that you recoil at what you consider to be
unnecessary complexity, but yeah, Tcl is is not Python. I've heard good
things about Tcl, but I also know that none of my programming peers use it.
Perhaps try another Python GUI library like wxPython, or pyGTK or pyQT etc.
That way, they might be different enough that you can escape comparisons to
Tcl.

But hey, sometimes, a language just doesn't fit your way of working. If Tcl
suits you better, then stick with Tcl.

Regards,

Liam Clarke


On Fri, Jan 21, 2011 at 8:57 AM, David Hutto  wrote:

> On Thu, Jan 20, 2011 at 2:43 PM, Elwin Estle 
> wrote:
> > I have some experience in Tcl\Tk, and so far, Tkinter is striking me as
> harder to use that Tk in it's "native" environment.
> >
> > I am attempting to re-write a program I originally did in Tcl\Tk in
> Python.  I managed to get a GUI done using just Tkinter, and, after an
> initial struggle with the Tkinter syntax (and especially the widget "naming"
> conventions),  had no problem getting widgets to display, etc.
> >
> > But, the tutorials I have encountered all mentioned that it is supposed
> to be a good idea to put one's GUI stuff in a class, then create an instance
> of the class (which I don't entirely understand, since I thought the whole
> "class" thing was for stuff that you were gonna have a lot of, like similar
> records in a database or something, so you could use the class like a
> factory to spit out little copies of itself.
> >
> > Anyway, when I attempted to convert my non-class based Tkinter code into
> a class, that's when the problems started.  I guess I still don't have a
> handle on all the "self.this's & self.that's", tho I have created some
> classes for the aforementioned database entry type stuff and haven't had too
> much trouble.
> >
> > For starters, it seems like the first thing these class based tutorials
> do is to start with a frame inside the main Tkinter window?  Why?  Why not
> just grid stuff right into the window, instead of making a frame and
> gridding widgets into that.
> >
> > Is the (self, master) thing in the __init__ section a convention, or is
> the use of the "master" a requirement?   Can you call it something else?
>  What is the purpose of doing an __init__ with a frame after having done
> __init__ with (self, master)?
> >
> > All this in Tcl\Tk seems to me, in comparison, just dead nuts
> simple...but Tkinter...seems to have made unnecessarily complicated.  Maybe
> once I understand it, I won't think of it that way, but for now...whatta
> PITA!
>
> It's just like any other concept, at first it is a PITA, then it
> becomes a normal utilization for your projects. Stick to your own
> platform, and design for it, then expand for others in your portfolio.
>
> >
> >
> >
> > ___
> > Tutor maillist  -  Tutor@python.org
> > To unsubscribe or change subscription options:
> > http://mail.python.org/mailman/listinfo/tutor
> >
>
>
>
> --
> The lawyer in me says argue...even if you're wrong. The scientist in
> me... says shut up, listen, and then argue. But the lawyer won on
> appeal, so now I have to argue due to a court order.
>
> Furthermore, if you could be a scientific celebrity, would you want
> einstein sitting around with you on saturday morning, while you're
> sitting in your undies, watching Underdog?...Or better yet, would
> Einstein want you to violate his Underdog time?
>
> Can you imagine Einstein sitting around in his underware? Thinking
> about the relativity between his pubic nardsac, and his Fruit of the
> Looms, while knocking a few Dorito's crumbs off his inner brilliant
> white thighs, and hailing E = mc**2, and licking the orangy,
> delicious, Doritoey crust that layered his genetically rippled
> fingertips?
>
> But then again, J. Edgar Hoover would want his pantyhose intertwi

[Tutor] not understanding a recursion example

[Bill Allen]

I am not understanding the following code (I did not write it).  It
demonstrates walking a tree-like data structure using recursion.  It does
run and produces reasonable output.  I particularly do not understand the
"traverse.level" statements.  Can anyone give me an idea how this is working
and the principles?  I would like understand recursive calls in Python
better as I have not used the technique previously.

Thanks,
Bill


data = {'count': 2,
'text': '1',
'kids': [{'count': 3,
  'text': '1.1',
  'kids': [{'count': 1,
'text': '1.1.1',
'kids': [{'count':0,
  'text': '1.1.1.1',
  'kids': []}]},
   {'count': 0,
'text': '1.1.2',
'kids': [{'count':0,
  'text': '1.1.1.2',
  'kids': [{'count':0,
'text': '1.1.1.1.1',
'kids': []}]}]},
   {'count': 0,
'text': '1.1.3',
'kids': []}]},
 {'count': 0,
  'text': '1.2',
  'kids': []}]}

def traverse(data):
print(' ' * traverse.level + data['text'])
for kid in data['kids']:
traverse.level += 1
traverse(kid)
traverse.level -= 1

if __name__ == '__main__':
traverse.level = 1
traverse(data)
___
Tutor maillist  -  Tutor@python.org
To unsubscribe or change subscription options:
http://mail.python.org/mailman/listinfo/tutor