Re: [Tutor] Tkinter layout question
On Mon, 24 Apr 2017 09:24:55 +1000
Phil wrote:
> On Sun, 23 Apr 2017 09:39:54 +0200
> Sibylle Koczian wrote:
>
> > Am 20.04.2017 um 14:43 schrieb Alan Gauld via Tutor:
> > > Its not too bad you can map the large 9x9 table to the smaller
> > > units using divmod()
> > >
> > > So the 7th element becomes
> > > divmod(7) -> 2,1
> > >
> >
> > Should be divmod(7, 3), shouldn't it?
>
> Thanks Sibylle, I eventually stumbled upon the answer using my usual
> trial-and-error method. The 3, as in the number of cells, was the key.
Actually, that's not correct either.
Say I want the 7th cell in the first line of a 9 x 9 grid, that would be x = 7,
y = 1. divmod(7,1) = 2,1 or the first cell in grid 3. So far so good.
Another example, x = 4, y = 3. divmod(4,3) = 1,1. What I need here is grid 2 x
= 1 and y = 3.
Further complications are, arrays, or lists in Python, start a 0 and divmod may
not be the answer because divide by 0 is not possible. Making adjustments for
these two possibilities has resulted in complicated code that does give the
desired result. Of course, I may have misunderstood the intention of Alan's
mapping method.
So, what I need is a function to map from a 9 x 9 grid to a cell in a 3 x 3
grid.
My feeble simplified attempt is as follows:
def map_cell(x,y):
return divmod(x,y)
while(True):
x,y = input().split(" ")
print (map_cell(int(x), int(y)))
--
Regards,
Phil
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Tkinter layout question
On Sun, 23 Apr 2017 09:39:54 +0200 Sibylle Koczian wrote: > Am 20.04.2017 um 14:43 schrieb Alan Gauld via Tutor: > > Its not too bad you can map the large 9x9 table to the smaller units > > using divmod() > > > > So the 7th element becomes > > divmod(7) -> 2,1 > > > > Should be divmod(7, 3), shouldn't it? Thanks Sibylle, I eventually stumbled upon the answer using my usual trial-and-error method. The 3, as in the number of cells, was the key. -- Regards, Phil ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] classproperty: readonly and inheritance - not more needed
Thomas Güttler wrote:
>
>
> Am 20.04.2017 um 14:26 schrieb Steven D'Aprano:
>> On Thu, Apr 20, 2017 at 10:39:57AM +0200, Thomas Güttler wrote:
>>
- its hard to get classproperty to work right.
>>>
>>> What is "righ"?
>>>
>>> In my case a read-only classproperty is enough. Inheritance should be
>>> supported.
>>>
>>> I don't have a usecase for a setter.
>>
>> The standard library is not just for you :-)
>>
>> If Peter's solution is "good enough" for you, then great, go ahead and
>> use it. But beware: of the two implementations I know, you cannot have
>> both:
>>
>> - access from instances;
>> - read-only property;
>>
>> You can have access from instances, but then the classproperty is not
>> read-only. Or you can have read-only access, but only from the class
>> object.
>
> I can't follow what you. What do you mean with "... is not read-only".
>
> This snippet works fine:
>
> {{{
>
> class classproperty(object):
> def __init__(self, f):
> self.f = f
> def __get__(self, obj, owner):
> return self.f(owner)
>
> class Foo(object):
> @classproperty
> def my_prop(cls):
> return 42
>
> print Foo.my_prop
>
> print Foo().my_prop
> }}}
>
> Regards,
>Thomas
>
Python 2.7.6 (default, Oct 26 2016, 20:30:19)
[GCC 4.8.4] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> class classproperty(object):
... def __init__(self, f):
... self.f = f
... def __get__(self, obj, owner):
... return self.f(owner)
...
>>> class Foo(object):
... @classproperty
... def my_prop(cls):
... print "calculating..."
... return 42
...
>>> Foo.my_prop
calculating...
42
Now the "not read-only" part:
>>> Foo.my_prop = "whatever"
>>> Foo.my_prop
'whatever'
You now have a string attribute, the property is lost. Methods behave the
same way and it's generally not a problem, but you should at least be aware
of this behaviour.
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] classproperty: readonly and inheritance - not more needed
Am 20.04.2017 um 14:26 schrieb Steven D'Aprano:
On Thu, Apr 20, 2017 at 10:39:57AM +0200, Thomas Güttler wrote:
- its hard to get classproperty to work right.
What is "righ"?
In my case a read-only classproperty is enough. Inheritance should be
supported.
I don't have a usecase for a setter.
The standard library is not just for you :-)
If Peter's solution is "good enough" for you, then great, go ahead and
use it. But beware: of the two implementations I know, you cannot have
both:
- access from instances;
- read-only property;
You can have access from instances, but then the classproperty is not
read-only. Or you can have read-only access, but only from the class
object.
I can't follow what you. What do you mean with "... is not read-only".
This snippet works fine:
{{{
class classproperty(object):
def __init__(self, f):
self.f = f
def __get__(self, obj, owner):
return self.f(owner)
class Foo(object):
@classproperty
def my_prop(cls):
return 42
print Foo.my_prop
print Foo().my_prop
}}}
Regards,
Thomas
--
Thomas Guettler http://www.thomas-guettler.de/
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Tkinter layout question
Phil wrote: > On Sun, 23 Apr 2017 09:52:16 +0200 > Peter Otten <__pete...@web.de> wrote: > >> If you wrote the above with Buttons instead of DisplayTables you'd >> encounter the same behaviour. The problem is that you call >> tkinter.Tk() twice (which is generally a recipe for disaster; if you >> want multiple windows use tkinter.Toplevel() for all but the first >> one). >> >> Once you have fixed that you should be OK: >> >> import tkinter as tk >> import table_class >> >> root = tk.Tk() >> >> tab = table_class.DisplayTable(root, >> ["Left","middle","Right"], >> [[1,2,1], >> [3,4,3], >> [5,6,5]], >> datacolor='blue', >> cellcolor='yellow', >> gridcolor='red', >> hdcolor='black') >> >> second_tab = table_class.DisplayTable(root, >> ["Left","middle","Right"], >> [[1,2,1], >> [3,4,3], >> [5,6,5]], >> datacolor='blue', >> cellcolor='green', >> gridcolor='red', >> hdcolor='black') >> >> tab.pack(side=tk.LEFT) >> second_tab.pack() >> >> root.mainloop() > > Thank you again Peter. Of course your changes worked but at the moment I'm > not sure why. > > if root = tk.Tk() then why isn't table_class.DisplayTable(root, the same > as table_class.DisplayTable(tk.Tk(),. Obviously it isn't but I don't know > why. Consider the function make_a_cake(). If you use it eat_a_piece_of(make_a_cake()) eat_a_piece_of(make_a_cake()) that's short for one_cake = make_a_cake() eat_a_piece_of(one_cake) another_cake = make_a_cake() eat_a_piece_of(another_cake) i. e. you had two pieces of cake, one piece of each of two cakes. If you write cake = make_a_cake() eat_a_piece_of(cake) eat_a_piece_of(cake) you have still eaten two pieces of cake but both are taken from the same cake. Likewise when you write root = tk.Tk() first_table = DisplayTable(root) second_table = DisplayTable(root) both tables share the same instance of the Tk class. > Also I found that root.mainloop() isn't necessary in that the result is > the same with or without. Perhaps it serves some other purpose? Try running it from the command line, not in idle. In every tkinter program there must be a main loop to respond to events. ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Tkinter layout question
On Sun, 23 Apr 2017 09:52:16 +0200 Peter Otten <__pete...@web.de> wrote: > If you wrote the above with Buttons instead of DisplayTables you'd > encounter the same behaviour. The problem is that you call > tkinter.Tk() twice (which is generally a recipe for disaster; if you > want multiple windows use tkinter.Toplevel() for all but the first > one). > > Once you have fixed that you should be OK: > > import tkinter as tk > import table_class > > root = tk.Tk() > > tab = table_class.DisplayTable(root, > ["Left","middle","Right"], > [[1,2,1], > [3,4,3], > [5,6,5]], > datacolor='blue', > cellcolor='yellow', > gridcolor='red', > hdcolor='black') > > second_tab = table_class.DisplayTable(root, > ["Left","middle","Right"], > [[1,2,1], > [3,4,3], > [5,6,5]], > datacolor='blue', > cellcolor='green', > gridcolor='red', > hdcolor='black') > > tab.pack(side=tk.LEFT) > second_tab.pack() > > root.mainloop() Thank you again Peter. Of course your changes worked but at the moment I'm not sure why. if root = tk.Tk() then why isn't table_class.DisplayTable(root, the same as table_class.DisplayTable(tk.Tk(),. Obviously it isn't but I don't know why. Also I found that root.mainloop() isn't necessary in that the result is the same with or without. Perhaps it serves some other purpose? -- Regards, Phil ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Tkinter layout question
Phil wrote: > On Thu, 20 Apr 2017 13:43:07 +0100 > Alan Gauld via Tutor wrote: > >> If still confused drop a question here. > > I hope I'm not over doing the questions here. I'm only posting after hours > of experimenting and Internet searching. > > How do I create multiple instances of the table on the one frame? I think > the table class as presented is not capable of that. If I create multiple > instances like this then, of course, I end up with two instances of the > same frame. > > import tkinter as tk > import table_class > > tab = table_class.DisplayTable(tk.Tk(), > ["Left","middle","Right"], > [[1,2,1], > [3,4,3], > [5,6,5]], > datacolor='blue', > cellcolor='yellow', > gridcolor='red', > hdcolor='black') > > > second_tab = table_class.DisplayTable(tk.Tk(), > ["Left","middle","Right"], > [[1,2,1], > [3,4,3], > [5,6,5]], > datacolor='blue', > cellcolor='green', > gridcolor='red', > hdcolor='black') > > second_tab.pack(side = tk.LEFT) > tab.pack() > > I've tried different pack options including packing onto the parent frame. > If you wrote the above with Buttons instead of DisplayTables you'd encounter the same behaviour. The problem is that you call tkinter.Tk() twice (which is generally a recipe for disaster; if you want multiple windows use tkinter.Toplevel() for all but the first one). Once you have fixed that you should be OK: import tkinter as tk import table_class root = tk.Tk() tab = table_class.DisplayTable(root, ["Left","middle","Right"], [[1,2,1], [3,4,3], [5,6,5]], datacolor='blue', cellcolor='yellow', gridcolor='red', hdcolor='black') second_tab = table_class.DisplayTable(root, ["Left","middle","Right"], [[1,2,1], [3,4,3], [5,6,5]], datacolor='blue', cellcolor='green', gridcolor='red', hdcolor='black') tab.pack(side=tk.LEFT) second_tab.pack() root.mainloop() ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Tkinter layout question
Am 20.04.2017 um 14:43 schrieb Alan Gauld via Tutor: Its not too bad you can map the large 9x9 table to the smaller units using divmod() So the 7th element becomes divmod(7) -> 2,1 Should be divmod(7, 3), shouldn't it? ___ Tutor maillist - Tutor@python.org To unsubscribe or change subscription options: https://mail.python.org/mailman/listinfo/tutor
Re: [Tutor] Button command arguments: Using class to wrap function call versus using lambda in tkinter
boB Stepp wrote:
> Phil's recent postings have motivated me to try studying tkinter more
> systematically starting today, so I have been looking over available
> web resources. Playing around with the code in one such resource, I
> was looking at a section entitled "Arguments to Callbacks" towards the
> bottom of the page at
>
>
http://userpages.umbc.edu/~dhood2/courses/cmsc433/spring2012/?section=Notes&topic=Python¬es=92
>
> they have the code snippet:
>
> ==
> import Tkinter
>
>
> # command class to wrap function call with args
> # a.k.a. "currying"
> class Command:
> def __init__(self, callback, *args, **kwargs):
> self.callback = callback
> self.args = args
> self.kwargs = kwargs
>
> def __call__(self):
> return apply(self.callback, self.args, self.kwargs)
>
>
> def callback(arg):
> print "You called callback with the following arg: %s" % arg
>
>
> root = Tkinter.Tk()
>
> Tkinter.Button(root, text="Foo", command=Command(callback, 'Foo')).pack()
> Tkinter.Button(root, text="Bar", command=Command(callback, 'Bar')).pack()
> Tkinter.Button(root, text="Baz", command=Command(callback, 'Baz')).pack()
>
> root.mainloop()
> ==
>
> This is Python 2 code, so I endeavored to convert it to Python 3. I
> came up with:
>
> ==
> #!/usr/bin/env python3
>
> import tkinter as tk
>
> # Command class to wrap function call with args
> # A.K.A. "currying"
> class Command:
> def __init__(self, callback, *args, **kwargs):
> self.callback = callback
> self.args = args
> self.kwargs = kwargs
>
> def __call__(self):
> return self.callback(*self.args, **self.kwargs)
>
> def callback(arg):
> print('You called callback with the following arg: %s' % arg)
>
> root = tk.Tk()
> tk.Button(root, text='Foo', command=Command(callback, 'Foo')).pack()
> tk.Button(root, text='Bar', command=Command(callback, 'Bar')).pack()
> tk.Button(root, text='Baz', command=Command(callback, 'Baz')).pack()
>
> root.mainloop()
> ==
>
> This seems to work fine, and got me to wondering about using lambda
> instead of this class wrapper approach, which gave me:
>
> ==
> import tkinter as tk
>
> def callback(arg):
> print('You called callback with the following arg: %s' % arg)
>
> root = tk.Tk()
> tk.Button(root, text='Foo', command=lambda arg='Foo':
> callback(arg)).pack() tk.Button(root, text='Bar', command=lambda
> arg='Bar': callback(arg)).pack() tk.Button(root, text='Baz',
> command=lambda arg='Baz': callback(arg)).pack()
>
> root.mainloop()
> ==
>
> And this also works well. Seeing as this approach has fewer lines of
> code and reads clearly, what advantages would the class wrapper
> approach have? The only thing that is occurring to me in my current
> sleepy state is that the class wrapper is much more flexible with
> handling varying passed arguments. Are there other considerations I
> should be aware of?
Generally I'd also prefer the lambda or functools.partial(callback, "Foo"),
but if you want to maintain per-button state a class may be worth
considering. A simple example:
class Callback:
def __init__(self, template):
self.count = 0
self.template = template
def __call__(self):
self.count += 1
print(self.template.format(self.count))
tk.Button(root, text='Foo', command=Callback("Foo pressed {} times")).pack()
___
Tutor maillist - Tutor@python.org
To unsubscribe or change subscription options:
https://mail.python.org/mailman/listinfo/tutor
