Hi , I am new one but ur talked make me laugh too :D , although here is relevant link for you
" if Tk cannot come up with an exact match, it tries to find a similar font. If that fails, Tk falls back to a platform-specific default font. Tk's idea of what is "similar enough" probably doesn't correspond to your own view, so you shouldn't rely too much on this feature." http://www.pythonware.com/library/tkinter/introduction/x444-fonts.htm Hope it helps you On Thu, Feb 10, 2011 at 9:55 PM, <python-list-requ...@python.org> wrote: > Send Python-list mailing list submissions to > python-list@python.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.python.org/mailman/listinfo/python-list > or, via email, send a message with subject or body 'help' to > python-list-requ...@python.org > > You can reach the person managing the list at > python-list-ow...@python.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Python-list digest..." > > Today's Topics: > > 1. Yappi error "context not found" (Brian) > 2. Re: Markdown to reStructuredText (Michele Simionato) > 3. Shared memory python between two separate shell-launched > processes (Charles Fox (Sheffield)) > 4. Re: Easy function, please help. (Jason Swails) > 5. Re: Shared memory python between two separate shell-launched > processes (Jean-Paul Calderone) > 6. Re: Problem with giant font sizes in tkinter (Cousin Stanley) > 7. Re: email.encoders.encode_base64 creates one line only > (s...@uce.gov) > 8. Re: OO Python (Dan Stromberg) > 9. Re: Easy function, please help. (Ethan Furman) > 10. Re: Problem with giant font sizes in tkinter (rantingrick) > > > ---------- Forwarded message ---------- > From: Brian <dribna...@gmail.com> > To: python-list@python.org > Date: Thu, 10 Feb 2011 05:38:43 -0800 (PST) > Subject: Yappi error "context not found" > I'm posting here because I can't find a Yappi specific mailing list. > > I've been using the rather brilliant Yappi from > http://code.google.com/p/yappi/ > It works well for small programs with a few threads. However, when > trying to run it over large programs with several hundred threads I've > been getting the error "context not found". > > The most basic example I can come up with which illustrates the > problem is below. Changing the number of threads started from 25 down > to, say, 10, works fine. Any more than ~25 and the error keeps > appearing. This is using Python 2.6.5 and Ubuntu Linux 10.04. I don't > have another box to try this out on at the moment. > > I've tested a similar script using thread.start_new_thread() and that > doesn't seem to have the problem. So is there some issue with Yappi > and inheriting from threading.Thread? > > import yappi > import time > import threading > > class MyThread(threading.Thread): > def run(self): > time.sleep(1) > > yappi.start() > > for i in range(0,25): > c = MyThread() > c.start() > time.sleep(1) > > yappi.print_stats() > yappi.stop() > > > Running the above gives: > [*] [yappi-err] context not found. > [*] [yappi-err] context not found. > [*] [yappi-err] context not found. > [*] [yappi-err] context not found. > ... > > Any help appreciated. > > > > ---------- Forwarded message ---------- > From: Michele Simionato <michele.simion...@gmail.com> > To: comp.lang.pyt...@googlegroups.com > Date: Thu, 10 Feb 2011 00:03:19 -0800 (PST) > Subject: Re: Markdown to reStructuredText > Looks cool, I will have a look at it, thanks! > > > > ---------- Forwarded message ---------- > From: "Charles Fox (Sheffield)" <charles....@gmail.com> > To: python-list@python.org > Date: Thu, 10 Feb 2011 06:30:18 -0800 (PST) > Subject: Shared memory python between two separate shell-launched processes > Hi guys, > I'm working on debugging a large python simulation which begins by > preloading a huge cache of data. I want to step through code on many > runs to do the debugging. Problem is that it takes 20 seconds to > load the cache at each launch. (Cache is a dict in a 200Mb cPickle > binary file). > > So speed up the compile-test cycle I'm thinking about running a > completely separate process (not a fork, but a processed launched form > a different terminal) that can load the cache once then dunk it in an > area of shareed memory. Each time I debug the main program, it can > start up quickly and read from the shared memory instead of loading > the cache itself. > > But when I look at posix_ipc and POSH it looks like you have to fork > the second process from the first one, rather than access the shared > memory though a key ID as in standard C unix shared memory. Am I > missing something? Are there any other ways to do this? > > thanks, > Charles > > > > ---------- Forwarded message ---------- > From: Jason Swails <jason.swa...@gmail.com> > To: Benjamin Kaplan <benjamin.kap...@case.edu> > Date: Thu, 10 Feb 2011 09:50:18 -0500 > Subject: Re: Easy function, please help. > > > On Thu, Feb 10, 2011 at 3:31 AM, Benjamin Kaplan <benjamin.kap...@case.edu > > wrote: > >> >> > On Wed, Feb 9, 2011 at 5:34 PM, MRAB <pyt...@mrabarnett.plus.com> >> wrote: >> >> >>> Or typecast to an int if you want to neglect decimals before >> converting >> >>> to a string, etc. >> >>> >> >> [snip] >> >> Python doesn't have typecasting. :-) >> > >> > Because these basic types are not mutable? <excuse> Most of my work has >> to >> > be in Fortran, so I'm a relative newcomer to Python. When I don't need >> > Fortran-y performance it's much nicer (obviously to anyone that's used >> them >> > both)! Still don't know much deeper than Python's cosmetic surface at >> this >> > point. </excuse> >> > >> >> Not exactly. It's because everything in Python is an object. What >> you're doing isn't type casting. It's just calling an object >> constructor- no different than any other class in the language. >> > > Ah, makes sense, thanks. Most of what I see/work in is C and Fortran -- > not much OOP there :) > > --Jason > > -- >> http://mail.python.org/mailman/listinfo/python-list >> > > > > -- > Jason M. Swails > Quantum Theory Project, > University of Florida > Ph.D. Graduate Student > 352-392-4032 > > > ---------- Forwarded message ---------- > From: Jean-Paul Calderone <calderone.jeanp...@gmail.com> > To: python-list@python.org > Date: Thu, 10 Feb 2011 07:43:54 -0800 (PST) > Subject: Re: Shared memory python between two separate shell-launched > processes > On Feb 10, 9:30 am, "Charles Fox (Sheffield)" <charles....@gmail.com> > wrote: > > Hi guys, > > I'm working on debugging a large python simulation which begins by > > preloading a huge cache of data. I want to step through code on many > > runs to do the debugging. Problem is that it takes 20 seconds to > > load the cache at each launch. (Cache is a dict in a 200Mb cPickle > > binary file). > > > > So speed up the compile-test cycle I'm thinking about running a > > completely separate process (not a fork, but a processed launched form > > a different terminal) > > Why _not_ fork? Load up your data, then go into a loop forking and > loading/ > running the rest of your code in the child. This should be really > easy to > implement compared to doing something with shared memory, and solves > the > problem you're trying to solve of long startup time just as well. It > also > protects you from possible bugs where the data gets corrupted by the > code > that operates on it, since there's only one copy shared amongst all > your > tests. Is there some other benefit that the shared memory approach > gives > you? > > Of course, adding unit tests that exercise your code on a smaller data > set > might also be a way to speed up development. > > Jean-Paul > > > > ---------- Forwarded message ---------- > From: Cousin Stanley <cousinstan...@gmail.com> > To: python-list@python.org > Date: Thu, 10 Feb 2011 15:48:47 +0000 (UTC) > Subject: Re: Problem with giant font sizes in tkinter > Steven D'Aprano wrote: > > > I have a tkinter application under Python 2.6 which is shows text > > in a giant font, about twenty(?) times larger than expected. > > > > The fonts are set using: > > > > titlefont = '-Adobe-Helvetica-Bold-R-Normal-*-180-*' > > buttonfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > .... > > Although I've been a linux user for several years, > that type of font spec hurts my head .... :-) > > Will the more simplistic type of tuple spec > not work in your tkinter application ? > > canv.create_text( > 81 , 27 , > text = ' NTSC Standard ' , > fill = 'white' , > font = ( 'Helvetica' , 12 , 'bold' ) ) > > > -- > Stanley C. Kitching > Human Being > Phoenix, Arizona > > > > > ---------- Forwarded message ---------- > From: s...@uce.gov > To: python-list@python.org > Date: Thu, 10 Feb 2011 08:51:07 -0700 > Subject: Re: email.encoders.encode_base64 creates one line only > > This is with python 3.1.2 (r312:79147). I have not tried with 2.7. >> >> When I create an attachment with email.mime.image.MIMEImage, by default it >> uses email.encoders.encode_base64 for the encoder, but that results in a >> single line base64 string, instead of the recommended multiple 76-chars >> lines. >> >> This works with most MTA and MUA, but some of them choke on it. >> >> > In case somebody runs into the same issue: > http://bugs.python.org/issue9298 > > And I added a work around if you need a solution before this bug is fixed > at: > http://bugs.python.org/issue11156#msg128213 > > -- > Yves. > http://www.SollerS.ca/ > > http://blog.zioup.org/ > > > > ---------- Forwarded message ---------- > From: Dan Stromberg <drsali...@gmail.com> > To: Paul Symonds <paul.j.symo...@gmail.com> > Date: Thu, 10 Feb 2011 08:36:29 -0800 > Subject: Re: OO Python > On Wed, Feb 9, 2011 at 1:50 PM, Paul Symonds <paul.j.symo...@gmail.com> > wrote: > > Are there any good resources to learn OO Python from? > > Yes, plenty, but it's important for us to know so we can advise you: > Do you know any other OO languages yet? > > > > ---------- Forwarded message ---------- > From: Ethan Furman <et...@stoneleaf.us> > To: Jason Swails <jason.swa...@gmail.com>, python-list@python.org > Date: Thu, 10 Feb 2011 08:52:38 -0800 > Subject: Re: Easy function, please help. > Jason Swails wrote: > >> On Wed, Feb 9, 2011 at 8:16 PM, Ethan Furman wrote: >> while n: is plenty readable. n is either something or nothing, and >> something evaluates to True, nothing to False. >> >> Sure it's readable. But then you have to make sure that the loop will >> eventually take n down to 0. >> > > Sure, but the same holds true with 'while n != 0' -- you have to make sure > the loop will eventually take n down to 0. > > You can always *assume* that the programmer knew what they were doing (not >> an assumption I'm typically willing to make on code that's not my own). >> > > Hopefully not something you have to deal with unless you're debugging... > > How is "while n != 0:" any worse? (or abs(n) < tolerance). It has >> exactly the same effect without adding any code while at the same time >> directly communicates the intended conditional. IMO it makes reading the >> code easier to read barring effective documentation (my experience with >> people documenting their code is that they don't; at least in my field). >> "while n != 0" makes my life easier. >> > > In that instance (a bunch of mathematical functions), I can easily see > using that construct. > > The fact that the proposed loop finished with *nothing* was coincidental. >> What if he had been doing some type of prime factorization or something >> where each iteration reduced the number until eventually all you were left >> with was the multiplicative identity? You'd say (correctly) that obviously >> the same approach won't work, but in some lines of thought it's a logical >> extension to use the same construct (especially to those that don't fully >> understand why the original loop exits in the first place). Expanding the >> conditional a little can only help IMO. >> > > Thank you for making my argument for me -- you have to understand the tool > you are using to make the best use of it. > > def num_digits(n): >> return len(str(n).replace('-','').replace('.','')) >> >> Or typecast to an int if you want to neglect decimals before >> converting to a string, etc. >> >> Or use recursion! >> >> >>> def num_digits(n): >> ... if n == 0: >> ... return 0 >> ... else: >> ... return num_digits(n//10) + 1 >> ... >> >>> num_digits(1) >> 1 >> >>> num_digits(0) >> 0 >> >> >> 0 is still one digit. ;) >> >> >> Well that is something; yet only nothing evaluates to False. We seem to >> be at an impasse :). >> > > I fail to see how a faulty algorithm puts us at an impasse. To tweak your > code: > > --> def num_digits(n, _first_pass=True): > --> if n == 0: > --> return int(_first_pass) > --> else: > --> return num_digits(n//10, _first_pass=False) + 1 > > correctly handles the special case of zero. To use my style, it would look > like: > > --> def num_digits(n, _first_pass=True): > --> if n: > --> return num_digits(n//10, _first_pass=False) + 1 > --> else: > --> return int(_first_pass) > > And, of course, this only works for non-negative integers. (I'll leave the > discussion of whether zero is non-negative to others. ;) As I said > earlier, I can see using the 'if n == 0' construct in certain situations, > and if the non-zero branch were lengthy I would stick with the first version > here. > > ~Ethan~ > > > > ---------- Forwarded message ---------- > From: rantingrick <rantingr...@gmail.com> > To: python-list@python.org > Date: Thu, 10 Feb 2011 08:52:19 -0800 (PST) > Subject: Re: Problem with giant font sizes in tkinter > On Feb 10, 12:59 am, Steven D'Aprano <steve > +comp.lang.pyt...@pearwood.info> wrote: > > I have a tkinter application under Python 2.6 which is shows text in a > > giant font, about twenty(?) times larger than expected. > > > > The fonts are set using: > > > > titlefont = '-Adobe-Helvetica-Bold-R-Normal-*-180-*' > > buttonfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > labelfont = '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > > > On one PC (Fedora), the text is displayed fine. Running xlsfonts gives me > > this: > > > > $ xlsfonts -fn '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1 > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1 > > > > On a second PC (Ubuntu), the text is displayed in HUGE letters and I get > > this from xlsfonts: > > > > $ xlsfonts -fn '-Adobe-Helvetica-Bold-R-Normal-*-140-*' > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1 > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso10646-1 > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1 > > -adobe-helvetica-bold-r-normal--14-140-75-75-p-82-iso8859-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso10646-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1 > > -adobe-helvetica-bold-r-normal--20-140-100-100-p-105-iso8859-1 > > > > I don't know how to diagnose or fix the problem. What should I do to fix > > this problem? > > > First let me stop laughing... hold on... yea just a minute... a little > longer please... gawd i am enjoying this... ok i am ready... *pffftt* > ha ha ha ha ha ha ha! > > I thought you hated Tkinter Steven? That is what you told this fine > group many times anyway. Also on many occasions you have said that you > have no use for GUI's, period. This is very interesting that know you > cannot even draw text to preferred size. > > Oh, and about your problem. READ THE FREAKING MANUAL! > > > > > -- > http://mail.python.org/mailman/listinfo/python-list >
-- http://mail.python.org/mailman/listinfo/python-list
