best way to increment an IntVar?

[Alan G Isaac]

Of course one can do
myintvar.set(myintvar.get()+1)
but surely there is a better way?

I'm surprsied that
myintvar += 1
is not allowed.

Thanks,
Alan Isaac

[Ben Finney]

Post by Alan G Isaac
Of course one can do
myintvar.set(myintvar.get()+1)
but surely there is a better way?

What is an IntVar? It's not a built-in type, so you'll need to tell us.

type(myintvar)

Where is it imported from?

import sys
sys.modules[type(myintvar).__module__]

Post by Alan G Isaac
I'm surprsied that
myintvar += 1
is not allowed.

Does the documentation lead you to believe it would be allowed?

help(type(myintvar))

[rantingrick]

Post by Ben Finney

Post by Alan G Isaac
Of course one can do
   myintvar.set(myintvar.get()+1)
but surely there is a better way?

What is an IntVar? It's not a built-in type, so you'll need to tell us.

For those who don't know; IntVar is from the module Tkinter. It is a
class to contain an integer control var used to update Tkinter widgets
that support it.

@OP: No there is not an __iadd__ method in the IntVar class but if you
really, really want to update this way just subclass IntVar and create
the method yourself. OOP is cool like dat!

You can also configure a Tkiter widget via the Python syntax w[key] =
value OR w.config(key1=value1, key2=value2, ...)

[Dennis Lee Bieber]

On Thu, 24 Jun 2010 15:07:29 +1000, Ben Finney

Post by Ben Finney
What is an IntVar? It's not a built-in type, so you'll need to tell us.

I suspect it's from Tkinter -- an instance of a class that links
Python data types into the tcl/tk runtime

Post by Ben Finney

help(Tkinter.IntVar)

Help on class IntVar in module Tkinter:

class IntVar(Variable)
| Value holder for integer variables.
|
| Methods defined here:
|
| __init__(self, master=None, value=None, name=None)
| Construct an integer variable.
|
| MASTER can be given as master widget.
| VALUE is an optional value (defaults to 0)
| NAME is an optional Tcl name (defaults to PY_VARnum).
|
| If NAME matches an existing variable and VALUE is omitted
| then the existing value is retained.
|
| get(self)
| Return the value of the variable as an integer.
|
| set(self, value)
| Set the variable to value, converting booleans to integers.
|

It is NOT a numeric "variable" in Python realms.

So var+=increment can't be used because Python would rebind the name
var to a new object -- but Tkinter would still be hooked to the original
object and never see the change.

[Bruno Desthuilliers]

Dennis Lee Bieber a écrit :
(snip - about Tkinter IntVar type)

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.
So var+=increment can't be used because Python would rebind the name
var to a new object -- but Tkinter would still be hooked to the original
object and never see the change.

foo = []
bar = foo
foo += [1]
foo

[1]

Post by Dennis Lee Bieber

bar

[1]

Post by Dennis Lee Bieber

bar is foo

True

Post by Dennis Lee Bieber

foo.__iadd__([2])

[1, 2]

Post by Dennis Lee Bieber

_ is foo

True
IOW : __iadd__ doesn't necessarily returns a new object !-)

[Alan G Isaac]

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.

Sure, but why does it not behave more like one?
It seems both obvious and desirable, so I'm
guessing there is a good reason not to do it.

Post by Dennis Lee Bieber
So var+=increment can't be used because Python would rebind the name
var to a new object

import Tkinter as tk

... def __iadd__(self, val):
... self.set(self.get()+val)
... return self
...

Post by Dennis Lee Bieber

root = tk.Tk()
myintvar2 = IntVar2()
temp = myintvar2
myintvar2 += 5
print(myintvar2.get(),myintvar2 is temp)

(5, True)

Alan Isaac

[Dave Angel]

<div class="moz-text-flowed" style="font-family: -moz-fixed">On

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.

Sure, but why does it not behave more like one?
It seems both obvious and desirable, so I'm
guessing there is a good reason not to do it.

Post by Dennis Lee Bieber
So var+=increment can't be used because Python would rebind the name
var to a new object

import Tkinter as tk

... self.set(self.get()+val)
... return self
...

Post by Dennis Lee Bieber

root = tk.Tk()
myintvar2 = IntVar2()
temp = myintvar2
myintvar2 += 5
print(myintvar2.get(),myintvar2 is temp)

(5, True)
Alan Isaac

A real Python integer is immutable. But for tkinter, you want something
that can change. So they define an object that can be changed. But the
default behavior of += is to assign a new object with the new value,
rather than changing the previous object.

DaveA

[Alan G Isaac]

the default behavior of += is to assign a new object with the new value,
rather than changing the previous object.

a = []
temp = a
a += [2]
temp

[2]

Alan Isaac

[Dave Angel]

<div class="moz-text-flowed" style="font-family: -moz-fixed">On

the default behavior of += is to assign a new object with the new value,
rather than changing the previous object.

a = []
temp = a
a += [2]
temp

[2]
Alan Isaac

I said "default", not "only" behavior. I suspect list provides an
__iadd__ method to provide this ability. Integers do not, and
therefore neither does the object the OP was asking about.

DaveA

[Alan G Isaac]

Post by Dave Angel
I said "default", not "only" behavior. I suspect list provides an
__iadd__ method to provide this ability. Integers do not, and
therefore neither does the object the OP was asking about.

I have no idea what "default behavior" is supposed to mean.
Mutable objects like a list will generally modify in place.
Immutable objects of course will not. An IntVar is mutable.
You have given no reason for it not to handle ``+=`` in an
unsurprising fashion. It is not an int.

Alan Isaac

[Dave Angel]

Post by Alan G Isaac

Post by Dave Angel
I said "default", not "only" behavior. I suspect list provides an
__iadd__ method to provide this ability. Integers do not, and
therefore neither does the object the OP was asking about.

I have no idea what "default behavior" is supposed to mean.
Mutable objects like a list will generally modify in place.
Immutable objects of course will not. An IntVar is mutable.
You have given no reason for it not to handle ``+=`` in an
unsurprising fashion. It is not an int.
Alan Isaac

To quote the docs,

"If a specific method is not defined, the augmented assignment falls
back to the normal methods. For instance, to execute the statement x +=
y, where /x/ is an instance of a class that has an __iadd__()
<#object.__iadd__> method, x.__iadd__(y) is called. If /x/ is an
instance of a class that does not define a __iadd__() <#object.__iadd__>
method, x.__add__(y) and y.__radd__(x) are considered, as with the
evaluation of x + y."

In other words, if a class defines __add(), but not __iadd__(), then
it'll behave this way. That's what I mean by default.

I didn't say it should, merely that it does. I suspect that __iadd__
didn't exist when IntVar was being defined, and nobody got around to
adding it.

Another part of the docs would seem to encourage IntVar to change:

"An augmented assignment expression like x += 1 can be rewritten as x =
x + 1 to achieve a similar, but not exactly equal effect. In the
augmented version, x is only evaluated once. Also, when possible, the
actual operation is performed /in-place/, meaning that rather than
creating a new object and assigning that to the target, the old object
is modified instead"

DaveA

[rantingrick]

Post by Alan G Isaac

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.

Sure, but why does it not behave more like one?
It seems both obvious and desirable, so I'm
guessing there is a good reason not to do it.

This is a good point. And i have always believed the IntVar should
work this way. However it has not been changed because those who have
the power to change it really don't use GUI's (much less Tkinter) or
for that matter really care. I fear your laments will only fall on
deaf ears as the many before you. However i find the control vars in
most instances not really the best choice. For check buttons and
radiobuttions they are essintial, however for labels, texts,
listboxes, etc, just use w.config()

As another example; IDLE is full of atrocities like using built-ins
for variables, polluting namespaces with from Tkinter import * (not to
mention that this slows load time to a crawl when you have load 30
namespaces with 500 or so names), the package is missing much needed
comments and doc strings, and the most annoying and i would say
*idiotic* of all is the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy! WTF! So after you run your test and
try to press the little red X button to close the window guess what
happens...yes the mainloop quits processing events but the GUI stays
plopped right there on your monitor until you go and kill the process
from task manager... WHAT F'N MORON WROTE THIS CODE?!?! But what is
more amazing is how this atrocious code has lingered the stdlib for so
long. People it's time to wake up, IDLE needs a complete re-write.

But i wonder how many have called for changes and those changes have
fallen on deaf ears. How many have submitted beautiful code only to be
ignored because of childish rivalries? Why do i even waste my time
posting to this group? There's a good question.

[Emile van Sebille]

On 6/25/2010 10:24 AM rantingrick said...

Post by rantingrick

Post by Alan G Isaac

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.

Sure, but why does it not behave more like one?
It seems both obvious and desirable, so I'm
guessing there is a good reason not to do it.

This is a good point. And i have always believed the IntVar should
work this way. However it has not been changed because those who have
the power to change it really don't use GUI's (much less Tkinter) or
for that matter really care. I fear your laments will only fall on
deaf ears as the many before you. However i find the control vars in
most instances not really the best choice. For check buttons and
radiobuttions they are essintial, however for labels, texts,
listboxes, etc, just use w.config()
As another example; IDLE is full of atrocities like using built-ins
for variables, polluting namespaces with from Tkinter import * (not to
mention that this slows load time to a crawl when you have load 30
namespaces with 500 or so names), the package is missing much needed
comments and doc strings, and the most annoying and i would say
*idiotic* of all is the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy! WTF! So after you run your test and
try to press the little red X button to close the window guess what
happens...yes the mainloop quits processing events but the GUI stays
plopped right there on your monitor until you go and kill the process
from task manager... WHAT F'N MORON WROTE THIS CODE?!?! But what is
more amazing is how this atrocious code has lingered the stdlib for so
long. People it's time to wake up, IDLE needs a complete re-write.
But i wonder how many have called for changes and those changes have
fallen on deaf ears. How many have submitted beautiful code only to be
ignored because of childish rivalries? Why do i even waste my time
posting to this group? There's a good question.

IIRC, IDLE was written by Guido so that he could experience writing in
python (which he also wrote). _You_ can either rewrite it or not, but
realize no one else is going to do it, so stop wasting your time asking
for it to be rewritten.

Emile

[rantingrick]

Post by Emile van Sebille
IIRC, IDLE was written by Guido so that he could experience writing in
python (which he also wrote).  _You_ can either rewrite it or not, but
realize no one else is going to do it, so stop wasting your time asking
for it to be rewritten.

I AM rewriting it, however i am heavily contemplating whether i will
or will not share the code with such ungrateful heathens.

[Emile van Sebille]

On 6/25/2010 1:07 PM rantingrick said...

Post by rantingrick

Post by Emile van Sebille
IIRC, IDLE was written by Guido so that he could experience writing in
python (which he also wrote). _You_ can either rewrite it or not, but
realize no one else is going to do it, so stop wasting your time asking
for it to be rewritten.

I AM rewriting it, however i am heavily contemplating whether i will
or will not share the code with such ungrateful heathens.

Idle is dead -- long live idlefork!

http://osdir.com/ml/python.idle/2002-09/msg00105.html


Emile

[rantingrick]

Post by Emile van Sebille

Post by rantingrick
I AM rewriting it, however i am heavily contemplating whether i will
or will not share the code with such ungrateful heathens.

Idle is dead -- long live idlefork!

Thanks Emile for sharing this. Nobody had told me about the IDLE fork
project. And that is very strange to me considering all the noise i've
made about IDLE over the last year or so. Anyway i was reading from
the "main" IDLEFORK project page and noticed something peculiar...

"""The IDLEfork project was an official experimental development fork
of Python's small, light, 'bundled' integrated development
environment, IDLE."""

...Ok, sounds great!

"""On June 29, 2003 the IDLEfork code base (rev 0.9b1) was merged back
into Python. Its location in the Python source tree was moved from .../
Tools/idle to .../Lib/idlelib, and the IDLEfork project went into
bugfix mode."""

hmm 2003? Bummer. This means that even the newest attempt to upgrade
idle was nearly ~7 years ago? So it seems old IDLE is really living up
to it's name. Looks like the dev cycle is completely "idle" at this
point and suffering the fate of monkey patch syndrome. I think it's
high time we create a new IDLE fork and then mold it back into the
stdlib. This time actually creating a Pythonic IDLE which conforms to
the stdlib for comments, docstrings, working test subjects, etc...

Any module in the stdlib should have proper comments, docstrings on
every method, and most importantly a test case wrapped up in a "if
__name__ == '__main__'" block. And this test case SHOULD NEVER BLOW
CHUNKS! The test case is sooo important to new programmers learning
Python, and i cannot stress that enough!

Now. I would be more than happy to start by doc'ing out all the
methods, classes, modules, etc. However i'm not about to waste my time
if i cannot get the code accepted into the stdlib because "some
people" here hate me.

@OP: I am very sorry to have hijacked your thread. This was not my
intention however the state of IDLE (and any stdlib module) is very
important to the future of Python. And since IDLE is written in
Tkinter there is a connection to the subject matter within this
thread. Although i will admit it's a very distant connection.

[Steven D'Aprano]

Looks like the dev cycle is completely "idle" at this point and
suffering the fate of monkey patch syndrome.

That's the second time that I've noticed you use the term "monkey patch".
I don't think it means what you seem to think it means. You seem to be
using it in the sense of "being patched by monkeys", but that's not the
commonly agreed meaning of monkey-patching.

Monkey-patching is patching code on the fly, rather than modifying the
source code or subclassing it. For example, suppose for I wanted math.sin
to accept arguments in degrees rather than radians, I might do this:

import math
_sin = math.sin # save the original code
def sin(x):
return _sin(math.radians(x))

math.sin = sin


And lo and behold, now every module that uses math.sin will see your new
version. That's a monkey-patch. It's an incredibly powerful technique,
allowing you to not only shoot your own foot off, but that of everyone
else as well.

http://en.wikipedia.org/wiki/Monkey_patch

[rantingrick]

Post by Steven D'Aprano
That's the second time that I've noticed you use the term "monkey patch".
I don't think it means what you seem to think it means. You seem to be
using it in the sense of "being patched by monkeys", but that's not the
commonly agreed meaning of monkey-patching.
Monkey-patching is patching code on the fly, rather than modifying the
source code or subclassing it. For example, ...<snip great tutorial!>

Yes i am aware of the true meaning of "monkey-patching" however i do
occasionally use it out of "accepted" context to mean that something
was done in a half arse way. I tend to be slightly rebellious as most
of the group has probably realized at this point. But i am very happy
that you took the time to explain to the commonly the accepted
definition of MP. Because there are always new programmers listening
who may not be familiar with these terms. This sort of self-less help
it what i want to see more of.

I want to show you guys and example of a group that *all* groups
should aspire to be...overly-dramatic-and-useless-pause-here... the
"Google SketchUp Help Group"! A fine class of folks who would go to
extraordinary lengths to help new users. Here is a thread that
showcases how dedicated these people really are...[Warning: You will
be amazed!]

http://www.google.com/support/forum/p/sketchup/thread?tid=6ec1e3310b9c8151&hl=en

Clearly the user is upset and blabbing all sorts of incendiary
nonsense but again and again the good folks at SketchUp stay calm and
always attempt to help. This is how i would like to see this group get
along. Of course we can still have fun and be sarcastic, but we need
to collaborate more because this constant in-fighting is slowing
Python's development progress. Look guys, check your egos and pride at
the door, when you're here, you're family!

PS I'll give 50 points to the first chap who guesses my identity on
that group ;-)
PPS: Sorry for stealing your quote Menseator, but it was just too
juicy to pass up ;-)
PPPS: Sorry Mensenator you can't get the fifty points because now you
know ;-)

[Michael Torrie]

Post by Emile van Sebille
Idle is dead -- long live idlefork!
http://osdir.com/ml/python.idle/2002-09/msg00105.html

Actually idlefork is dead. It was merged back into Idle sometime around
Python 2.3. At least that's what its homepage claims.

[Alan G Isaac]

Post by rantingrick
the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy!

Did you open an issue?
http://bugs.python.org/

Alan Isaac

[rantingrick]

Post by rantingrick
the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy!

Did you open an issue?http://bugs.python.org/

If *I* open an issue it will be ignored or quickly dismissed because
the people in charge of the Python community hate me. The reason for
this hate is because I am very outspoken and will not allow myself to
be brow beaten by some of the thugs within this group. Thats Ok, the
only people they hurt in the end is themselves. Well not really...
their actions filter out improvements that will benefit others. I have
said it before and i'll say it again...

IDLE IS BROKEN BEYOND REPAIR! WE MUST SALVAGE THE VERY FEW PARTS OF IT
THAT CAN BE SALVAGED AND RE-WRITE THE REST FROM THE GROUND UP! YOU
CANNOT KEEP MONKEY PATCHING BROKEN SOFTWARE!!!

Until that statement sinks into the exceedingly thick skulls around
here we will forever live in a state of stdlib hell. Yes IDLE was
originally written by the great GvR. He had a vision and we failed to
maintain that vision. The code sucks and is in a state not welcome in
any stdlib, however i am sure at the time he wrote it he could not
make as pretty as it should have been because he was also in the
process of building Python itself.

I don't blame GvR for the poor style of IDLE. I blame ALL OF YOU for
not allowing new code to replace this rotten piece of crap that makes
python look like some children's toy. You people should be ashamed of
yourselves. You have fallen asleep at the wheel and now the Valdeez is
spewing black crude into the word of programming covering all hope
with a nasty black film of pollution.

Some of you don't care about IDLE, well thats fine, but you should
care about the stdlib being clean and up to date.

[Alan G Isaac]

Post by rantingrick

Post by rantingrick
the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy!

Did you open an issue?http://bugs.python.org/

If *I* open an issue it will be ignored or quickly dismissed because
the people in charge of the Python community hate me.

I bet against that assessment.
For this particular issue. ;-)

As for the larger issue, I believe DreamPie is under
active development?
http://dreampie.sourceforge.net/

fwiw,
Alan Isaac

[Mark Lawrence]

Post by rantingrick

Post by rantingrick
the "if __name__ == '__main__' tests" use
root.quit instead of root.destroy!

Did you open an issue?http://bugs.python.org/

If *I* open an issue it will be ignored or quickly dismissed because
the people in charge of the Python community hate me. The reason for
this hate is because I am very outspoken and will not allow myself to
be brow beaten by some of the thugs within this group. Thats Ok, the
only people they hurt in the end is themselves. Well not really...
their actions filter out improvements that will benefit others. I have
said it before and i'll say it again...
IDLE IS BROKEN BEYOND REPAIR! WE MUST SALVAGE THE VERY FEW PARTS OF IT
THAT CAN BE SALVAGED AND RE-WRITE THE REST FROM THE GROUND UP! YOU
CANNOT KEEP MONKEY PATCHING BROKEN SOFTWARE!!!
Until that statement sinks into the exceedingly thick skulls around
here we will forever live in a state of stdlib hell. Yes IDLE was
originally written by the great GvR. He had a vision and we failed to
maintain that vision. The code sucks and is in a state not welcome in
any stdlib, however i am sure at the time he wrote it he could not
make as pretty as it should have been because he was also in the
process of building Python itself.
I don't blame GvR for the poor style of IDLE. I blame ALL OF YOU for
not allowing new code to replace this rotten piece of crap that makes
python look like some children's toy. You people should be ashamed of
yourselves. You have fallen asleep at the wheel and now the Valdeez is
spewing black crude into the word of programming covering all hope
with a nasty black film of pollution.
Some of you don't care about IDLE, well thats fine, but you should
care about the stdlib being clean and up to date.

Normal dross from a complete and utter moron. Thankfully one completely
useless idiot doesn't make a community. As I have suffered from
physical and mental health problems for some years I reckon I do quite
well. You, sadly, are beyond redemption.

Have a nice day.

Mark Lawrence.

[Aahz]

Post by Mark Lawrence
Normal dross from a complete and utter moron. Thankfully one completely
useless idiot doesn't make a community. As I have suffered from
physical and mental health problems for some years I reckon I do quite
well. You, sadly, are beyond redemption.

Please don't continue responding if you can't stay civil -- as the
saying goes, when a wise man and a fool get into an argument, nobody can
tell which is which.

[rantingrick]

Post by Aahz

Normal dross from a complete and utter moron.  Thankfully one completely
useless idiot doesn't make a community.  As I have suffered from
physical and mental health problems for some years I reckon I do quite
well. You, sadly, are beyond redemption.

Please don't continue responding if you can't stay civil -- as the
saying goes, when a wise man and a fool get into an argument, nobody can
tell which is which.

Thanks Aahz for stepping in with some moral grounding. But is it
*maybe* just a wee bit too harsh to call Mark a fool? ;-)

[rantingrick]

Post by rantingrick
Some of you don't care about IDLE, well thats fine, but you should
care about the stdlib being clean and up to date.

Normal dross from a complete and utter moron.  Thankfully one completely
useless idiot doesn't make a community. <snip> You, sadly, are beyond redemption.

Ok Mark, i've had about enough of your trollish behavior and
bombastically blatant Ad hominem attacks against me. Save us all some
headache and please don't reply to any of my posts in the future
*unless* you can muster the strength AND NOT resort to inflammatory
hate speech against my person. I know you hate me with a purple
passion and i am very sorry you let emotion rule your life so
completely and sadly, so self destructively. Maybe one day you
smile...?

However I *do* hope to make you one my closest allies in the future.
But only *you* have the power to turn this negative energy around into
something positive... here's to hope'in Mark, heres to Hope'in.

[Terry Reedy]

Post by rantingrick
If *I* open an issue it will be ignored or quickly dismissed because
the people in charge of the Python community hate me.
Nonsense.
Though an inflammatory, hyperbole-filled rant made up of nothing but
charged declarations and rhetoric, and lacking actual reasoned and
evidence supported arguments will certainly get deleted-- like I'm going
to do with most of your message as I quote But! I think you're missing

Rick, I am one of the all-too-few people who review tracker issues and
occasionally close them. I do not 'hate' you and have never
'brow-beaten' you. As you seem to be aware, the rhetorial confines of
the tracker are much stricter than here. 'Reasoned and evidence
supported arguments' are definitely the coin of that realm. Rants are out.

If you have a potential contribution but do not trust yourself to
restrain yourself as appropriate to the tracker, you can send it to me.
If I think it plausible, I will open an issue and credit 'anonymous' or
whatever neutral, unloaded name you prefer ('Rick' ok, 'RantingRick' not).

[rantingrick]

Post by Terry Reedy
Rick, I am one of the all-too-few people who review tracker issues and
occasionally close them. I do not 'hate' you and have never
'brow-beaten' you.

Yes and i never said you did, i am sorry if you felt my words were
directed towards you, please believe they were not. I have always
thought you to be someone who never lets emotions get in the way of
business. Thank you for that.

Post by Terry Reedy
If you have a potential contribution but do not trust yourself to
restrain yourself as appropriate to the tracker, you can send it to me.
If I think it plausible, I will open an issue and credit 'anonymous' or
whatever neutral, unloaded name you prefer ('Rick' ok, 'RantingRick' not).

Yes and i *did* send you an email about two days ago and it keeps
bouncing. I just figured you had blocked me or something? However i
just found a new address for you and i will be trying it shortly.
Anyway could you send me an email so i can contact you in the future.
As i have said before i do not want any credit, or recognition. I only
want to improve the stdlib.

Thanks Terry.

[Terry Reedy]

Post by Alan G Isaac

Post by Dennis Lee Bieber
It is NOT a numeric "variable" in Python realms.

Sure, but why does it not behave more like one?
It seems both obvious and desirable, so I'm
guessing there is a good reason not to do it.

tkinter was written long before newstyle classes and properties existed.
For 3.x, all the classes had to be and were updated. I presume
properties could now be used in 3.x to update the interface.