apostrophe not considered with tkinter's wordstart and wordend
When I place my mouse over a word (and I press something)
I want the program to analyze the word.
Tkinter almost provides the perfect option:
self.text.get('current wordstart', 'current wordend')
Unfortunately apostrophes are not considered using wordstart and wordend.
http://infohost.nmt.edu/tcc/help/pubs/tkinter/
Says:
"For the purposes of this operation, a word is either
a string of consecutive letter, digit, or underbar (_) characters,
or a single character that is none of these types."
The easy work around is to highlight the word and use:
self.text.get('sel.first', 'sel.last')
However, it seems like it could be an easy improvement
if we could include the apostrophe in the list of word characters.
Is it possible that this could be added in an upcoming version of Python --
or is this a Tk issue?
Windows 7 & Python 3.4
--
https://mail.python.org/mailman/listinfo/python-list
Re: apostrophe not considered with tkinter's wordstart and wordend
Thanks guys :-] Rick Johnson: > but you could implement any pattern matching you want > by binding the correct events and then processing the > "target string" on the Python side. I'm curious about what events you would use. The only work around I thought of is to create a word list and then apply tags & use tag_bind(). -- https://mail.python.org/mailman/listinfo/python-list
Re: apostrophe not considered with tkinter's wordstart and wordend
We resolved it over at the comp.lang.tcl group.
It turns out what Christian suggested affects what is selected when you double
click a word. He later discovered a different method for producing what I want.
Below is my test code that implements both of these things
(tested with Python 3.4 and PyCharm).
import tkinter
import tkinter.messagebox as messagebox
class Creator(object):
def __init__(self):
root = self.root = tkinter.Tk()
# Main Frame
f_main = tkinter.Frame(root, borderwidth=6, relief='flat')
f_main.grid(row=0, column=0, sticky='nsew')
# Text widget, its font and frame
f_txt = tkinter.Frame(f_main, borderwidth=2, relief="sunken")
f_txt.config(width=768, height=768)
f_txt.grid_propagate(False) # ensures a consistent GUI size
f_txt.pack(padx=4, pady=4, side="bottom", fill="both", expand=True)
my_txt = tkinter.Text(f_txt, name='t')
my_txt.config(undo=True, wrap='word')
my_txt.grid(row=0, column=0, sticky="nsew")
self.text = my_txt
# Scrollbar and config
f_scroll = tkinter.Frame(root, borderwidth=4, relief="groove")
f_scroll.grid(row=0, column=1, sticky='nsew')
scrollbar = tkinter.Scrollbar(f_scroll, command=my_txt.yview)
scrollbar.pack(side='left', fill='y', pady=2, padx=0, expand=True)
my_txt.config(yscrollcommand=scrollbar.set)
scrollbar.columnconfigure(0, weight=1)
# Stretchable
root.columnconfigure(0, weight=1)
root.rowconfigure(0, weight=1)
f_main.columnconfigure(0, weight=1)
f_main.rowconfigure(0, weight=1)
f_txt.rowconfigure(0, weight=1)
f_txt.columnconfigure(0, weight=1)
my_txt.bind("", self.test)
my_txt.focus_set()
def test(self, event=None):
txt = str(self.text)
a = "::tk::TextPrevPos {} current tcl_wordBreakBefore".format(txt)
b = "::tk::TextNextPos {} current tcl_wordBreakAfter".format(txt)
ind1 = self.root.tk.eval(a)
ind2 = self.root.tk.eval(b)
x = self.text.get(ind1, ind2)
messagebox.showinfo('info', x)
# ===
# start up
# ===
GUI = Creator()
GUI.root.tk.eval("catch {tcl_endOfWord}")
GUI.root.tk.eval("catch {tcl_startOfPreviousWord}")
GUI.root.tk.eval("set tcl_wordchars {[[:alnum:]']}")
GUI.root.tk.eval("set tcl_nonwordchars {[^[:alnum:]']}")
GUI.root.mainloop()
--
https://mail.python.org/mailman/listinfo/python-list
Re: apostrophe not considered with tkinter's wordstart and wordend
I copied the GUI creation from my personal text editor. The scrollbar and stretchability could have been left out, for sure. You're only seeing a portion of a more complex GUI. After writing several Tkinter applications, I decided that subclassing without a clear reason only had the effect of polluting the namespace of my class. I like seeing only my attributes and methods during code completion. Thanks for your interest and help. -- https://mail.python.org/mailman/listinfo/python-list
find all multiplicands and multipliers for a number
def m_and_m(dividend): rlist = [] dm = divmod end = (dividend // 2) + 1 for divisor in range(1, end): q, r = dm(dividend, divisor) if r is 0: rlist.append((divisor, q)) return rlist print(m_and_m(999)) --- output: [(1, 999), (3, 333), (9, 111), (27, 37), (37, 27), (111, 9), (333, 3)] --- How do we describe this function? Does it have an established name? What would you call it? Does 'Rosetta Code' have it or something that uses it? Can it be written to be more efficient? What is the most efficient way to exclude the superfluous inverse tuples? Can it be written for decimal numbers as input and/or output? Thank you! -- https://mail.python.org/mailman/listinfo/python-list
Re: find all multiplicands and multipliers for a number
Thank you all. I learned a lot. -- https://mail.python.org/mailman/listinfo/python-list
a more precise distance algorithm
I read an interesting comment: """ The coolest thing I've ever discovered about Pythagorean's Theorem is an alternate way to calculate it. If you write a program that uses the distance form c = sqrt(a^2 + b^2) you will suffer from the lose of half of your available precision because the square root operation is last. A more accurate calculation is c = a * sqrt(1 + b^2 / a^2). If a is less than b, you should swap them and of course handle the special case of a = 0. """ Is this valid? Does it apply to python? Any other thoughts? :D My imagining: def distance(A, B): """ A & B are objects with x and y attributes :return: the distance between A and B """ dx = B.x - A.x dy = B.y - A.y a = min(dx, dy) b = max(dx, dy) if a == 0: return b elif b == 0: return a else: return a * sqrt(1 + (b / a)**2) -- https://mail.python.org/mailman/listinfo/python-list
Re: a more precise distance algorithm
On Monday, May 25, 2015 at 1:27:24 PM UTC-7, Christian Gollwitzer wrote: > Wrong. Just use the built-in function Math.hypot() - it should handle > these cases and also overflow, infinity etc. in the best possible way. > > Apfelkiste:~ chris$ python > Python 2.7.2 (default, Oct 11 2012, 20:14:37) > [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin > Type "help", "copyright", "credits" or "license" for more information. > >>> import math > >>> math.hypot(3,4) > 5.0 > > Christian Thank you! :D I forgot about that one. I wonder how the sympy Point.distance method compares... -- https://mail.python.org/mailman/listinfo/python-list
Re: a more precise distance algorithm
On Monday, May 25, 2015 at 1:27:43 PM UTC-7, Gary Herron wrote: > This is a statement about floating point numeric calculations on a > computer,. As such, it does apply to Python which uses the underlying > hardware for floating point calculations. > > Validity is another matter. Where did you find the quote? Thank you. You can find the quote in the 4th comment at the bottom of: http://betterexplained.com/articles/surprising-uses-of-the-pythagorean-theorem/ -- https://mail.python.org/mailman/listinfo/python-list
Re: a more precise distance algorithm
On Monday, May 25, 2015 at 8:11:25 PM UTC-7, Steven D'Aprano wrote: > Let's compare three methods. > ... > which shows that: > > (1) It's not hard to find mismatches; > (2) It's not obvious which of the three methods is more accurate. Thank you; that is very helpful! I'm curious: what about the sqrt() function being last is detrimental? >From a point of ignorance it seems like we are just producing errors sooner, and then multiplying them, with this alternative method. -- https://mail.python.org/mailman/listinfo/python-list
Re: a more precise distance algorithm
Oh ya... true >_< Thanks :D On Monday, May 25, 2015 at 9:43:47 PM UTC-7, Ian wrote: > > def distance(A, B): > > """ > > A & B are objects with x and y attributes > > :return: the distance between A and B > > """ > > dx = B.x - A.x > > dy = B.y - A.y > > a = min(dx, dy) > > b = max(dx, dy) > > if a == 0: > > return b > > elif b == 0: > > return a > > This branch is incorrect because a could be negative. > > You don't need this anyway; the a == 0 branch is only there because of > the division by a in the else branch. > > > else: > > return a * sqrt(1 + (b / a)**2) > > Same issue; if a is negative then the result will have the wrong sign. -- https://mail.python.org/mailman/listinfo/python-list
Re: a more precise distance algorithm
On Monday, May 25, 2015 at 10:16:02 PM UTC-7, Gary Herron wrote: > It's probably not the square root that's causing the inaccuracies. In > many other cases, and probably here also, it's the summing of two > numbers that have vastly different values that loses precision. A > demonstration: > > >>> big = 1.0 > >>> small = 0.1 > >>> (big+small)-big # Should produce a value =small, but gives an exact > zero instead. > 0.0 > > The squaring of the two values in x*x+y*y just makes the addition even > more error prone since the squares make large values even larger and > small values even smaller. I appreciate your help. -- https://mail.python.org/mailman/listinfo/python-list
