This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author gpolo
Recipients gpolo, loewis, pysquared
Date 2008-06-26.22:43:16
SpamBayes Score 0.0010262745
Marked as misclassified No
Message-id <ac2200130806261543j7c009edamef0cab492aa5181@mail.gmail.com>
In-reply-to <1214517596.03.0.279480697623.issue1774370@psf.upfronthosting.co.za>
Content
> Graham Horler <grahamh@users.sourceforge.net> added the comment:
>
>> I'm aware of that and that is why everywhere I see Checkbutton
>> being used I see a explicit variable being created.
>
> Absolutely the reason for this patch, to get rid of unnecessary code.
> What's not to like?

You are not getting my point here. What I'm trying to say is: if you
are going to add such code to make it easier to get/set the variable
option value then you better add it to every other widget that
supports a variable option, or a textvariable (*variable in general).
This would make things uniform, you would never need to create a
Variable instance yourself. What I would really hate to see is a
widget that acts like a Variable was created for me, so I can
access/set its value, and others that have the same option but doesn't
allow me that.
And, finally, being explicit is not a bad thing.

>
>> I was referring to the other widgets that accepts *variable options.
>> ... add this functionality everywhere it would cause some
>> benefit, not only for Checkbutton.
>
> I'm all for that, just could not find another widget that created an
> inaccessible default variable.  Suggestions welcome.
>

Radiobutton for example ?
History
Date User Action Args
2008-06-26 22:43:17gpolosetspambayes_score: 0.00102627 -> 0.0010262745
recipients: + gpolo, loewis, pysquared
2008-06-26 22:43:17gpololinkissue1774370 messages
2008-06-26 22:43:16gpolocreate