Re: Profiler showing path dependency?
Hi, Our tool can help with this: https://github.com/devopspp/pyliveupdate/blob/master/README.md#profiler. It can output a flamegraph and a per-path call summary. Feel free to check it out and let me know if there is any questions. -CC On Friday, March 13, 2020 at 4:52:51 PM UTC-7, Go Luhng wrote: > Consider a simple call graph: `main()` calls `foo()`, which calls > `bar()`. Then `main()` calls `qux()` which also calls `bar()`, but > with different parameters. > > When you run the above through cProfile and view the result in > SnakeViz, you will see `main()` calling `foo()` and `qux()`, with each > of them calling `bar()`. However, if you hover or click on `bar()`, > you will see the global aggregate statistics for it. For example, the > number of times it has been called, and their total time cost. > > Is there a way to get a path-dependent profiler breakdown for `bar()`? > Specifically for this example, statistics for when it is called by > `foo()`, and separately statistics for when it is called by `qux()`. -- https://mail.python.org/mailman/listinfo/python-list
RE: Module import best practice
On Thu, 26 Mar 2020, Schachner, Joseph wrote: I can only tell you my preference. I prefer that Python modules be as self-contained as possible, because "global" is within a module; to share between modules you have to import something, as you know. Joseph, This makes good sense. I don't know that I'll end up with a chain of namespaces, but I should avoid that possiility. If I understand your reasoning, within commonDlg.py I should import required modules for each class and not all of them at the beginning of the file. And each module that uses classes from commonDlgs should include 'from commonDlg import ...' only the classes it needs, even when there are several (but not all commonDlg classes). Is this correct? Many thanks, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: Confusing textwrap parameters, and request for RE help
On 2020-03-25 16:09:24 -0400, Richard Damon wrote: > On 3/25/20 3:52 PM, Peter J. Holzer wrote: > > If anything, I think it was fixed-width fonts which contributed to the > > decline of hyphenation: With a fixed-width font you can't get a proper > > justification anyway, and if your right margin is ragged, hyphenation is > > much less important > > Actually, fixed width fonts are easy to justify, you just add additional > space between words through the line. Yes. It's easy to do it wrong and impossible to do it right :-) (BTDT) The problem is that you can only insert an integral number of spaces und the number of spaces you need to insert is rarely a multiple of the number of gaps between words. So you get uneven spacing, which looks horrible. hp -- _ | Peter J. Holzer| Story must make more sense than reality. |_|_) || | | | [email protected] |-- Charles Stross, "Creative writing __/ | http://www.hjp.at/ | challenge!" signature.asc Description: PGP signature -- https://mail.python.org/mailman/listinfo/python-list
Re: Confusing textwrap parameters, and request for RE help
On 2020-03-26, Peter J. Holzer wrote: >> Actually, fixed width fonts are easy to justify, you just add additional >> space between words through the line. > > Yes. It's easy to do it wrong and impossible to do it right :-) > > (BTDT) > > The problem is that you can only insert an integral number of spaces und > the number of spaces you need to insert is rarely a multiple of the > number of gaps between words. So you get uneven spacing, which looks > horrible. That was always an interesting freshman programming homework problem. But you're right, nobody in their right mind would actually want to generate real output that way. Ragged-right is far, far better than using fixed-width font justified with extra spaces scattered in. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Confusing textwrap parameters, and request for RE help
On 3/26/20 3:20 PM, Grant Edwards wrote: > On 2020-03-26, Peter J. Holzer wrote: >>> Actually, fixed width fonts are easy to justify, you just add additional >>> space between words through the line. >> Yes. It's easy to do it wrong and impossible to do it right :-) >> >> (BTDT) >> >> The problem is that you can only insert an integral number of spaces und >> the number of spaces you need to insert is rarely a multiple of the >> number of gaps between words. So you get uneven spacing, which looks >> horrible. > That was always an interesting freshman programming homework > problem. But you're right, nobody in their right mind would actually > want to generate real output that way. Ragged-right is far, far > better than using fixed-width font justified with extra spaces > scattered in. > > -- > Grant > > > Back in the day it was FREQUENTLY done, in part to show off, anyone could type with a typewriter and get jagged right margins, but with a computer you could get justified margins with uneven internal spacing!! Status! -- Richard Damon -- https://mail.python.org/mailman/listinfo/python-list
Re: Confusing textwrap parameters, and request for RE help
On 2020-03-26, Richard Damon wrote: >> [...] nobody in their right mind would actually >> want to generate real output that way. > > Back in the day it was FREQUENTLY done, in part to show off, anyone > could type with a typewriter and get jagged right margins, but with a > computer you could get justified margins with uneven internal spacing!! > Status! It would have been better phrased "nobody _should_ actually want to". Sure, it was fun _producing_ output like that. But for anybody who had to read it, the novelty wore off pretty quickly. After few lines it was just annoying. Most of us don't need any help making our writing even more annoying. -- Grant -- https://mail.python.org/mailman/listinfo/python-list
Re: Module import best practice
Rich, On 26/03/20 9:09 AM, Rich Shepard wrote: I'm writing an application using Python3 and Tkinter. The views/ directory contain multiple modules, including one called commonDlgs.py. This contains classes (such as those for validating data entry) used by all the data entry views. Some classes in commonDlgs imports other modules. My question is whether to import into each view class those modules needed by it or import all supporting modules at the top of commonDlgs.py, then import that module in each view with: from . import commonDlgs as cd rather than importing specific classes in each view module? My personal approach is to follow 'the Zen of Python' and prefer "explicit" over "implicit". (it helps beginners, as well as us old-fogies whose minds cannot retain things for very long) I see little point in importing 'stuff' that's not used. On the other hand, if that becomes the criteria for splitting one's code-base into ever more modules, likely it will cause more trouble than good. Plus if a module contains two classes but you only import one, the entire class is imported anyway - so, it's not like you're saving CPU-time or storage-space! As you've probably realised by now, there is a 'happy medium', but it's impossible to lay down a 'law'. It's probably one of those 'feelings' that comes with experience - and the only way you can gain experience is... Another problem with trying to gain such experience, is that Python has changed. You have demonstrated a "relative import". Its introduction (and the importlib, and "packages") opened-up a whole new vista* of opportunities), but much of the material available on-the-web pre-dates this. * Microsoft-ies may be confused by the real meaning of this word. Aside from the drudge of typing, there are two (main) potential issues to be considered - and hopefully avoided: proliferation and circular references. Proliferation: My mother-in-law had five kids. At first, it worried me that in trying to attract my attention, she would 'pop the list' - in her confusion, calling out each of her kids' names in-turn, before she happened upon mine. (especially given that most of them were/are girls!) There seem to be a large-ish number of classes and modules to manage. The more of these you have, the harder it is to keep track of which-is-where. That said, if you have a multiplicity of classes and try to group them into fewer modules, the problem may not go away; unless you are able to group them by function, theme, or stage/part of the system in which they are used. When faced with my mother-in-law's problem, many people resort to a tactic such as calling-out "hey you" [varies by culture and language]. Python has a similar facility! You can turn your "views/ directory" (which presumably contains a number of modules) into a "package". Remember the __init__.py file (the "file" not the similarly-named object instantiation method!) which is normally an empty, useless-looking appendage? [no comments about my head, please!] This can be populated with a list of moduleNMs (etc), thus creating a grouping-effect, shortening the import process, and lightening your cognitive- and management-loads. Circular references: If you have a bunch of import-able modules which in-turn import other modules, it is possible to become a dog chasing its own tail. [this is loads of fun, until your teeth sink firmly into said tail. Yow, ouch! (I'm told, er, by a friend - you must understand?) ] If there is module "fred.py" and it calls a class in "barney.py" but barney can't do anything without advice from "wilma.py", then that is all fine and can become the bed-rock of your program [sorry!]. However, if wilma needs to first confirm with "betty.py", who like any responsible wife goes to fred and asks "What are you up-to now, Fred?", fred will make excuses and blame barney, who in-turn will call for help and understanding from betty, who will want to put her head together with wilma's to decide how best to sort-out their men-folk, and... Are you confused yet? So would the Python interpreter be, giving-up and throwing such code all over the floor! Accordingly, you must design and manage the structure of your application - classes and modules should be encouraged not to gossip amongst themselves. The ComSc terms here include: "encapsulation", "coupling" and "cohesion", and because this is another area where ONE precise answer for the general case does not exist, the counter-considerations of such are "decoupling" and "the Law of Demeter"... Once again, read carefully because many ComSc-level web.refs will concern themselves with language-related matters, which may not apply in Python! Hoping this non-answer helps, by leaving you with reading topics which will realise advice for the concerns you had/hadn't noted to-date. Now, it's time to get back to the (salt-)mines, if we expect to put (dino-)steaks on the ta
Re: Confusing textwrap parameters, and request for RE help
On Fri, Mar 27, 2020 at 7:44 AM Grant Edwards wrote: > > On 2020-03-26, Richard Damon wrote: > > >> [...] nobody in their right mind would actually > >> want to generate real output that way. > > > > Back in the day it was FREQUENTLY done, in part to show off, anyone > > could type with a typewriter and get jagged right margins, but with a > > computer you could get justified margins with uneven internal spacing!! > > Status! > > It would have been better phrased "nobody _should_ actually want to". > > Sure, it was fun _producing_ output like that. But for anybody who had > to read it, the novelty wore off pretty quickly. After few lines it > was just annoying. Most of us don't need any help making our writing > even more annoying. > You know what's a lot more fun? Perfect block justification, no ragged edges, no extra internal spaces. I'm not sure whether it's MORE annoying or LESS than using internal spaces, but it's certainly a lot more fun to write, since you have to compose on the fly. And if even that becomes easy, try creating a column of just the letter "e" in the middle of the paragraph. ChrisA -- https://mail.python.org/mailman/listinfo/python-list
How come logging.error writes to a file, but not logging.debug or logging.info?
Hi,
When we run
logging.basicConfig( filename = "TestLogging_" +
datetime.datetime.now().strftime("%Y%m%d_%H%M%S") + ".log" )
, and then
logging.error( "Test01\n" )
logging.debug("Test02\n")
logging.info("Test03\n")
logging.error( "Test04\n" )
, only the error log lines get sent to the file.
How do I get info() and debug() to go to the file, as well?
--
https://mail.python.org/mailman/listinfo/python-list
Re: Module import best practice
On Fri, 27 Mar 2020, DL Neil via Python-list wrote: My personal approach is to follow 'the Zen of Python' and prefer "explicit" over "implicit". (it helps beginners, as well as us old-fogies whose minds cannot retain things for very long) DL, That was my original approach. I see little point in importing 'stuff' that's not used. Agree. Hoping this non-answer helps, by leaving you with reading topics which will realise advice for the concerns you had/hadn't noted to-date. Actually, it's a very good answer. I'm not a professional coder. I'm an environmental consultant and I use a variety of tools depending on the project's requirements. Most every day I'm in emacs. use LyX for almost all writing, R and GRASS for data analyses, SQL for database work, awk, sed, shell scripts, and python as required. This means I'm constantly relearning what I forgot since the last time. This has worked well for me for almost 30 years so I'm not complaining. But now I am adding GUIs and other Real Application(TM) bits to postgres applications I run from the command line for my own use so I can give these tools to others who might benefit from them. The last database-backend application I wrote in python2 and wxPython was more than a decade ago. Now I'm working exclusively with Python3 and learning tkinter. I've much to learn. ;-) Thanks for the complete explanation and I hope your dinner didn't burn on the grill. Regards, Rich -- https://mail.python.org/mailman/listinfo/python-list
Re: How come logging.error writes to a file, but not logging.debug or logging.info?
On 26Mar2020 14:02, [email protected] wrote: When we run logging.basicConfig( filename = "TestLogging_" + datetime.datetime.now().strftime("%Y%m%d_%H%M%S") + ".log" ) , and then logging.error( "Test01\n" ) logging.debug("Test02\n") logging.info("Test03\n") logging.error( "Test04\n" ) , only the error log lines get sent to the file. How do I get info() and debug() to go to the file, as well? You do this by adjusting the logging level of your programme. The idea is that you can put logging calls all through your code at suitable levels (info, error, warning debug) and change the logging verbosity just by adjusting the logging level of the logger involved. So I often have a sniff around at startup in my programmes where I set up the logging, and default to logging.WARNING unless stderr is a terminal (inferring "interactive") and use logging.INFO. A command line switch or environment variable might be used to override these defaults. Having picked a level: root_logger = logging.getLogger() root_logger.setLevel(level) sets the level of the root logger, thus changing the verbosity. Obviously adjust if you've got a special purpose logger rather than the root logger. Cheers, Cameron Simpson -- https://mail.python.org/mailman/listinfo/python-list
Re: Module import best practice
I'm not a professional coder. I'm an environmental consultant and I use a I take it all back then... No! No need to feel apologetic, the Python community works hard to be inclusive - which I take to include levels of expertise, not merely countering the various "-isms". variety of tools depending on the project's requirements. Most every day I'm in emacs. use LyX for almost all writing, R and GRASS for data analyses, SQL for database work, awk, sed, shell scripts, and python as required. This means I'm constantly relearning what I forgot since the last time. This has worked well for me for almost 30 years so I'm not complaining. With that list, I'm having difficulty crediting your claim. It's good that you recognised programming as a tool, and made it work for you! But now I am adding GUIs and other Real Application(TM) bits to postgres applications I run from the command line for my own use so I can give these tools to others who might benefit from them. The last database-backend application I wrote in python2 and wxPython was more than a decade ago. Now I'm working exclusively with Python3 and learning tkinter. I've much to learn. ;-) Know that feeling! I try to keep a note-/lab-/log-book of learning-experiences. Of course, remembering if/where I've noted topics is quite another matter... The Python-list has gone a bit quiet. I imagine many are busy trying to encourage/support colleagues new to the work-from-home gig. (hopefully not any other reason!) Usually questions attract more, and more prompt, answers. There are others who are tk-oriented. These days I (disclaiming bias) tend to follow the browser-based philosophy and thus web front-ends/HTML5-as-a-GUI (which don't need to be hosted on a web-server). When introduced to Python GUIs (also wxPython), I found that following 'the bare minimum' rule (cf 'kitchen sink') was the better option. Indeed it was usually easier to add things later, than to try to remove components - which usually 'broke stuff' at an alarming rate. "YAGNI" applies! Plus, before you try to hide your computing skills under the proverbial bushel, one of our most active skilled members has recently faced a similar issue of trying to add GUI-usually functionality into a cmdLN app. So... Thanks for the complete explanation and I hope your dinner didn't burn on the grill. OT: the word "environment" may mean slightly (or not so slight) different things to different people/cultures. Over here it is almost synonymous with "conservation" and the tourist advertising of "Clean, green, New Zealand". Thus, I think if I started on a diet of our living-dinosaurs, the Conservation Department would, shall we say, take an apposite stance. Given the time zone (it's already Friday here - would the rest of you please try to keep up with us!) I look-forward to my dinner... Pleased to hear of your age-group - hopefully it enabled you to understand the humor (and more readily accept (grand-)dad-jokes!). Perhaps of interest, here's a combination of the two - environment and (grand-)children: the New Zealand Geographic (magazine) is:- <<< Every day of this lock-down New Zealand Geographic will send a story or a video that can be shared among your family. The first one is below, and with it some talking points to fill our days at home together. If you’re a grandparent or a Kiwi overseas, you can participate too, and join your family discussion over phone or video conferencing. >>> https://www.nzgeo.com/newsletter/together-at-home/?t=34143_9db23c969a4ba2818c82d9b1c7f0ec9f&campaign_id= -- Regards =dn -- https://mail.python.org/mailman/listinfo/python-list
