🌐 Mailman 3 September 2021 - Python-list - python.org

Re: Trouble propagating logging configuration
by Loris Bennett Sept. 4, 2021

Sept. 4, 2021

"Dieter Maurer" <dieter(a)handshake.de> writes: > Loris Bennett wrote at 2021-9-1 13:48 +0200: >> ... >>Yes, but to quote from https://docs.python.org/3.6/howto/logging.html#logging-basic-tutorial: >> >> A good convention to use when naming loggers is to use a module-level >> logger, in each module which uses logging, named as follows: >> >> logger = logging.getLogger(__name__) >> >> This means that logger names track the package/module hierarchy, and >> it’s intuitively obvious where events are logged just from the logger >> name. >> >>so in this case the source layout is relevant, isn't it? > > Relevant in this case is the package/module hierarchy. > > Often the package/module hierarchy follows the source layout > **BUT** this is not necessarily the case. > > In particular, the "start" module of a script is called `__main__` > indepently of its location. > Furthermore, so called "namespace packages" consist of > decentralized (i.e. located at different places in the file system) > subpackages. > > Thus, in general, the connection between pachage/module hierarchy > and the source layout is loose. > > >>> Furthermore, the place of the configuration (and where in the >>> code it is activated) is completely irrelevant for the "inheritance". >> >>OK, so one issue is that I was getting confused by the *order* in which >>modules are being called. If I have two modules, 'foo' and 'bar', in >>the same directory, configure the logging just in 'foo' and then call >> >> >> foo.some_method() >> bar.some_method() >> >>then both methods will be logged. If I do >> >> bar.some_method() >> foo.some_method() >> >>then only the method in 'foo' will be logged. > > Usually, log configuration is considered a (global) application > (not a (local) package/module) concern: > The components (modules) decide what to log at what level > and global configuration decides what to do with those messages. > > Thus, typically, you configure the complete logging in > your main application module and then start to import modules > and call their functions. > >> ... >>If I have >> >> [loggers] >> keys=root,main,log_test >> >>in my logging configuration and initialise the logging in run.py ... > > This logging configuration is obviously not complete (thus, I cannot > check what happens in your case). > You may have made errors at other places in your configuration > which may explain your observations. > > At your place, I would look at the `logging` source code > to find out where you can see (in an interactive Python session) > which loggers have been created by your configuration and > how they are configured. For the last part you use "vars(logger)". Thanks Peter and Dieter for all the help. I have finally figured out what my problem was. If in a module 'mylibs.mylib' I have import logging logger = logging.getLogger(__name__) and in my main script have import logger import logger.config import mylibs.mylib logging.config.fileConfig("/home/loris/config") logger = logging.getLogger(__name__) then 'logger' in 'mylibs.mylib' is defined before 'logging.config.fileConfig' is called and the logger in the module is not configured. If change the order and write import logger import logger.config logging.config.fileConfig("/home/loris/config") logger = logging.getLogger(__name__) import mylibs.mylib then the 'logger' in 'mylibs.mylibs' does get configured properly. I'm still thinking what implications this has if I want to load a configuration file via a command-line option. Cheers, Loris -- This signature is currently under construction.

2 1

Re: on floating-point numbers
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

Julio Di Egidio <julio(a)diegidio.name> writes: [...] >> I, too, lost my patience there. :-) > > As if I didn't know who's trolling... I never trolled you. When we had our conversations in sci.logic, I was Boris Dorestand --- you would remember if you have very good memory. We talked for just a few days, I guess. The people trolling you there were not me. So, though that's no proof, *I* know you didn't know. :-)

1 0

Re: on floating-point numbers
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

Julio Di Egidio <julio(a)diegidio.name> writes: > On Thursday, 2 September 2021 at 15:52:02 UTC+2, Hope Rouselle wrote: > >> I don't understand floating-point numbers from the inside out, but I do >> know how to work with base 2 and scientific notation. So the idea of >> expressing a number as >> >> mantissa * base^{power} > > That's the basic idea, but the actual (ISO) floating-point *encoding* > is more complicated than that. > >> is not foreign to me. (If that helps you to perhaps instruct me on >> what's going on here.) > > This is the "classic": > DAVID GOLDBER > What Every Computer Scientist Should Know About Floating-Point Arithmetic > <http://perso.ens-lyon.fr/jean-michel.muller/goldberg.pdf> > > Here is some more introductory stuff: > <https://en.wikipedia.org/wiki/Floating-point_arithmetic> > <https://www.phys.uconn.edu/~rozman/Courses/P2200_15F/downloads/floating-poi…> Rozman's was pretty concise and nice. Thank you.

1 0

Re: on writing a while loop for rolling two dice
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

"Peter J. Holzer" <hjp-python(a)hjp.at> writes: > On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote: >> dn <PythonList(a)DancesWithMice.info> writes: >> > On 29/08/2021 08.46, Hope Rouselle wrote: >> >> Here's my solution: >> >> >> >> --8<---------------cut here---------------start------------->8--- >> >> def how_many_times(): >> >> x, y = 0, 1 >> >> c = 0 >> >> while x != y: >> >> c = c + 1 >> >> x, y = roll() >> >> return c, (x, y) >> > >> >> >> >> Why am I unhappy? I'm wish I could confine x, y to the while loop. >> >> The introduction of ``x, y = 0, 1'' must feel like a trick to a >> >> novice. How would you write this? > [...] >> But perhaps we may agree that while rolling dice until a certain >> success, we want to roll them while something happens or doesn't happen. >> One of the two. So while-True is a bit of a jump. Therefore, in this >> case, the easier and more natural option is to say while-x-not-equal-y. >> >> But this approach seems to force me into initializing x, y with >> different values. > > You can get around this by using NaN: > > def how_many_times(): > c, x, y = 0, math.nan, math.nan > while x != y: > c = c + 1 > x, y = roll() > return c, x, y > > Not sure if this is an improvement. Now you have to explain to your > students why math.nan != math.nan. > > When I need a guaranteed unique value I often just use object(): > > def how_many_times(): > c, x, y = 0, object(), object() > while x != y: > c = c + 1 > x, y = roll() > return c, x, y > > Of course now you are back to two different values, but they look the > same. Which may be better or worse for your students. Plus x and y are > now bound to objects of different types during their lifetime, which may > be a bit dicey. Lol. I would argue that it's quite appropriate to the event (``of rolling dice'' --- clarity-obsession). :D Pretty nice alternatives. Thank you so much.

1 0

Re: on perhaps unloading modules?
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

Dennis Lee Bieber <wlfraed(a)ix.netcom.com> writes: > On Sun, 22 Aug 2021 16:28:12 -0300, Hope Rouselle <hrouselle(a)jevedi.com> > declaimed the following: > > >>That's wild. :-) Was this created by Brian Kernighan? It's hard to >>believe. Oh, I think he wrote AMPL, wasn't it? A Mathematical >>Programming Language, or something like that. > > Kenneth Iverson, early 1960s for release, though he started in the late > 50s (so a decade before Kernighan). I believe it started life as a notation > for publishing reports, not as an actual implemented language. > > <https://en.wikipedia.org/wiki/APL_(programming_language)#Development_into_a…> > {Hmmm, supposed to have influenced Matlab, S, and Wolfram/Mathematica} > > One of the quirks is that one reads APL from right to left... cf: > <https://en.wikipedia.org/wiki/APL_(programming_language)#Pick_6_lottery_num…> > > You do not want to look down at the one-liner for Conway's Game of > Life. I really do not. But I did. That's really wild. Dramatic. Speechless.

1 0

Re: on the popularity of loops while and for
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

"Peter J. Holzer" <hjp-python(a)hjp.at> writes: > On 2021-08-29 10:04:47 +0100, Barry wrote: >> > I'd like get a statistic of how often each loop is used in practice. >> > >> > I was trying to take a look at the Python's standard libraries --- those >> > included in a standard installation of Python 3.9.6, say --- to see >> > which loops are more often used among while and for loops. Of course, >> > since English use the preposition ``for'' a lot, that makes my life >> > harder. Removing comments is easy, but removing strings is harder. So >> > I don't know yet what I'll do. >> > >> > Have you guys ever measured something like that in a casual or serious >> > way? I'd love to know. Thank you! >> >> I am interesting in why you think that choice of while vs. for is >> about popularity? >> >> Surely the choice is made in most cases by the algorithm? > > The context here is an introductory course for Python. So there is not > "the algorithm", there are all the algorithms that a novice is likely > to encounter. > > For me it makes absolute sense to base the contents of the course on > popularity. Constructs which a novice programmer is very likely to use > or encounter in other people's code should be covered more thoroughly > than constructs that will be used only rarely. Some are so rare that > they can be safely omitted. The while loop is certainly not in that > category, but it probably makes sense to spend less time on it than on > the for loop. ``A man after my own heart.''

1 0

urgent
by Hari Sept. 4, 2021

Sept. 4, 2021

i was download ur python software but it is like boring user interface for me like young student to learn ,can u have any updates?

5 6

Re: urgent
by Michael F. Stemper Sept. 4, 2021

Sept. 4, 2021

On 31/08/2021 18.02, Barry wrote: > The big problem with >>> is that it means a third level quote in email clients. > So when people cut-n-paste REPL output it’s formatted badly by email clients. > A prompt that avoided that issue would be nice. A little bit of piping fixes that: username@hostname$ cat text username@hostname$ python3 Python 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import sys # in the original, this line will be messed up >>> sys.exit(0) # this one, too username@hostname$ sed 's/^>>> /REPL> /' < text username@hostname$ python3 Python 3.5.2 (default, Jan 26 2021, 13:30:48) [GCC 5.4.0 20160609] on linux Type "help", "copyright", "credits" or "license" for more information. REPL> import sys # in the original, this line will be messed up REPL> sys.exit(0) # this one, too username@hostname$ -- Michael F. Stemper What happens if you play John Cage's "4'33" at a slower tempo?

2 1

Re: on the popularity of loops while and for
by Barry Sept. 4, 2021

Sept. 4, 2021

> On 28 Aug 2021, at 22:42, Hope Rouselle <hrouselle(a)jevedi.com> wrote: > > I'd like get a statistic of how often each loop is used in practice. > > I was trying to take a look at the Python's standard libraries --- those > included in a standard installation of Python 3.9.6, say --- to see > which loops are more often used among while and for loops. Of course, > since English use the preposition ``for'' a lot, that makes my life > harder. Removing comments is easy, but removing strings is harder. So > I don't know yet what I'll do. > > Have you guys ever measured something like that in a casual or serious > way? I'd love to know. Thank you! I am interesting in why you think that choice of while vs. for is about popularity? Surely the choice is made in most cases by the algorithm? If you have an iterator then you use for. Of course you can use while instead of for but in code review that will get queried. Barry > -- > https://mail.python.org/mailman/listinfo/python-list

2 1

Re: on writing a while loop for rolling two dice
by Hope Rouselle Sept. 4, 2021

Sept. 4, 2021

dn <PythonList(a)DancesWithMice.info> writes: > On 29/08/2021 08.46, Hope Rouselle wrote: >> Here's my solution: >> >> --8<---------------cut here---------------start------------->8--- >> def how_many_times(): >> x, y = 0, 1 >> c = 0 >> while x != y: >> c = c + 1 >> x, y = roll() >> return c, (x, y) > >> >> Why am I unhappy? I'm wish I could confine x, y to the while loop. The >> introduction of ``x, y = 0, 1'' must feel like a trick to a novice. How >> would you write this? > >> ram(a)zedat.fu-berlin.de (Stefan Ram) writes: >>> """Rolls two dice until both yield the same value. >>> Returns the number of times the two dice were rolled >>> and the final value yielded.""" >>> roll_count = 0 >>> while True: >>> outcome = roll_two_dice() >>> roll_count += 1 >>> if outcome[ 0 ]== outcome[ 1 ]: break >>> return roll_count, outcome[ 0 ] >> >> You totally convinced me. Thanks. > > On the other hand... > whilst you expressed concern about the apparently disconnected 'set up' > necessary before the loop, this solution adds a "True/Forever" and a > "Break" construct, which some may deem not that much better (if at all) > > The idea of abrogating the while-condition but then adding another > (disconnected) condition to break, seems to hold equal potential for > confusion. or the type of dissatisfaction which motivated the original > question! Pretty well observed! Hats to you. > Looking at that from the inside-out, the loop's contents perform two > functions: the rolling and counting (per Statement of Requirements), but > also a loop-controlling element. Thus the reader's question: "what does > this loop do?" is conflated with "how many times does it do it?". Well put. > Let's go completely off-the-rails, why not use a never-ending range() to > fuel a for-loop 'counter', and within that loop perform the dice-roll(s) > and decide if it is time to 'break'. The range replaces the "True". The > for-loops index or 'counter' will deliver the desired result. > > Neat? No! > Readable? No! > An improvement over the while-True? Definitely not! > Yet, the mechanism is the same AND offers a built-in counter. Hmmm... Yeah. Here's a little context. I came across this by processing a list of exercises. (I'm teaching a course --- you know that by now, I guess.) So the first thing I observed was the equal volume of work dedicated to while loops and for loops --- so I decided to compared which appeared more often in a certain sample of well-written Python code. It turns out the for loop was much more frequent. Students have been reporting too much work in too little time, so I decided to reduce the number of exercises involving while loops. When I began to look at the exercises, to see which ones I'd exclude, I decided to exclude them all --- lol! --- except for one. The one that remained was this one about rolling dice until a satisfying result would appear. (All other ones were totally more naturally written with a for loop.) So if I were to also write this with a for-loop, it'd defeat the purpose of the course's moment. Besides, I don't think a for-loop would improve the readability here. But I thought your protest against the while-True was very well put: while-True is not too readable for a novice. Surely what's readable or more-natural /to someone/ is, well, subjective (yes, by definition). But perhaps we may agree that while rolling dice until a certain success, we want to roll them while something happens or doesn't happen. One of the two. So while-True is a bit of a jump. Therefore, in this case, the easier and more natural option is to say while-x-not-equal-y. But this approach seems to force me into initializing x, y with different values. > Returning to the concern: > > x, y = 0, 1 > c = 0 > > The first line is purely to ensure that the loop executes at least once, > ie the two assigned-values are not 'real'. Hence the disquiet! > > Initiating the counter is unavoidable (@Chris' suggestion notwithstanding). > > However, remember that Python (like decent DBs) has a concept (and an > idiom) of a value to be used when we don't (yet) know what the value > is/should be! Further that Python allows such a value to be used in > comparisons: > >>>> None != None > False >>>> None == None > True > > Leading to: > > c, x, y = 0, None, None > while ... > > > Which solution reverts to the original loop-contents. which seem more > obvious and thus more readable. (YMMV!) > > Simplicity over 'being clever'... I don't see it. You seem to have found what we seem to agree that it would be the more natural way to write the strategy. But I can't see it. It certainly isn't --8<---------------cut here---------------start------------->8--- def how_many_times_1(): c, x, y = 0, None, None while x != y: c = c + 1 x, y = roll() return c, x, y --8<---------------cut here---------------end--------------->8--- nor --8<---------------cut here---------------start------------->8--- def how_many_times_2(): c, x, y = 0, None, None while x == y: c = c + 1 x, y = dados() return c, x, y --8<---------------cut here---------------end--------------->8--- What do you have in mind? I couldn't see it.

3 2