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

Re: frozenset can be altered by |=
by Jach Feng Nov. 21, 2021

Nov. 21, 2021

Marco Sulla 在 2021年11月20日星期六上午5:12:19 [UTC+8] 的信中寫道： > (venv_3_10) marco@buzz:~$ python > Python 3.10.0 (heads/3.10-dirty:f6e8b80d20, Nov 18 2021, 19:16:18) > [GCC 10.1.1 20200718] on linux > Type "help", "copyright", "credits" or "license" for more information. > >>> a = frozenset((3, 4)) > >>> a > frozenset({3, 4}) > >>> a |= {5,} > >>> a > frozenset({3, 4, 5}) There is no CONSTANT in Pyhton as other languages does. The only way to have it is using special naming convention, such as in all capital letters, to remind yourself not to re-assign it:-) --Jach

1 0

Re: Unexpected behaviour of math.floor, round and int functions (rounding)
by Ben Bacarisse Nov. 21, 2021

Nov. 21, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Sat, Nov 20, 2021 at 3:41 PM Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> > On Sat, Nov 20, 2021 at 12:43 PM Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> >> >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> >> >> > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> >> >> >> >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> >> >> >> >> > On Sat, Nov 20, 2021 at 5:08 AM ast <ast@invalid> wrote: >> >> >> >> >> >> >> >>> 0.3 + 0.3 + 0.3 == 0.9 >> >> >> >> False >> >> >> > >> >> >> > That's because 0.3 is not 3/10. It's not because floats are >> >> >> > "unreliable" or "inaccurate". It's because the ones you're entering >> >> >> > are not what you think they are. >> >> >> > >> >> >> > When will people understand this? >> >> >> > >> >> >> > (Probably never. Sigh.) >> >> >> >> >> >> Most people understand what's going on when it's explained to them. And >> >> >> I think that being initially baffled is not unreasonable. After all, >> >> >> almost everyone comes to computers after learning that 3/10 can be >> >> >> written as 0.3. And Python "plays along" with the fiction to some >> >> >> extent. 0.3 prints as 0.3, 3/10 prints as 0.3 and 0.3 == 3/10 is True. >> >> > >> >> > In grade school, we learn that not everything can be written that way, >> >> > and 1/3 isn't actually equal to 0.3333333333. >> >> >> >> Yes. We learn early on that 0.3333333333 means 3333333333/10000000000. >> >> We don't learn that 0.3333333333 is a special notation for machines that >> >> have something called "binary floating point hardware" that does not >> >> mean 3333333333/10000000000. That has to be learned later. And every >> >> generation has to learn it afresh. >> > >> > But you learn that it isn't the same as 1/3. That's my point. You >> > already understand that it is *impossible* to write out 1/3 in >> > decimal. Is it such a stretch to discover that you cannot write 3/10 >> > in binary? >> > >> > Every generation has to learn about repeating fractions, but most of >> > us learn them in grade school. Every generation learns that computers >> > talk in binary. Yet, putting those two concepts together seems beyond >> > many people, to the point that they feel that floating point can't be >> > trusted. >> >> Binary is a bit of a red herring here. It's the floating point format >> that needs to be understood. Three tenths can be represented in many >> binary formats, and even decimal floating point will have some surprises >> for the novice. > > Not completely a red herring; binary floating-point as used in Python > (IEEE double-precision) is defined as a binary mantissa and a scale, > just as "blackboard arithmetic" is generally defined as a decimal > mantissa and a scale. (At least, I don't think I've ever seen anyone > doing arithmetic on a blackboard in hex or octal.) You seem to be agreeing with me. It's the floating point part that is the issue, not the base itself. >> >> Yes, agreed, but I was not commenting on the odd (and incorrect) view >> >> that floating point operations are not reliable and well-defined, but on >> >> the reasonable assumption that a clever programming language might take >> >> 0.3 to mean what I was taught it meant in grade school. >> > >> > It does mean exactly what it meant in grade school, just as 1/3 means >> > exactly what it meant in grade school. Now try to represent 1/3 on a >> > blackboard, as a decimal fraction. If that's impossible, does it mean >> > that 1/3 doesn't mean 1/3, or that 1/3 can't be represented? >> >> As you know, it is possible, but let's say we outlaw any finite notation >> for repeated digits... Why should I convert 1/3 to this particular >> apparently unsuitable representation? I will write 1/3 and manipulate >> that number using factional notation. > > If you want that, the fractions module is there for you. Yes, I know. The only point of disagreement (as far as can see) is that literals like 0.3 appears to be confusing for beginners. You think they should know that "binary" (which may be all they know about computers and numbers) means fixed-width binary floating point (or at least might imply a format that can't represent three tenths), where I think it's not unreasonable for them to suppose that 0.3 is manipulated as the rational number it so clearly is. > And again, > grade school, we learned about ratios as well as decimals (or vulgar > fractions and decimal fractions). They have different tradeoffs. For > instance, I learned pi as both 22/7 and 3.14, because sometimes it'd > be convenient to use the rational form and other times the decimal. > >> The novice programmer might similarly expect that when they write 0.3, >> the program will manipulate that number as the faction it clearly is. >> They may well be surprised by the fact that it must get put into a >> format that can't represent what those three characters mean, just as I >> would be surprised if you insisted I write 1/3 as a finite decimal (with >> no repeat notation). > > Except that 0.3 isn't written as a fraction, it's written as a > decimal. Are you worrying about the term I used? 0.3 is a rational number. It is the way to write a particular fraction in decimal. I think the only point of disagreement is that you hope or expect that anyone writing three tenths as 0.3 should expect that that literal might be converted to some collection of bits that can't represent it. I think it's not unreasonable for a beginner to think otherwise. >> I'm not saying your analogy would not help someone understand, but you >> first have to explain why 0.3 is not treated as three tenths -- why I >> (to use your analogy) must not keep 1/3 as a proper fraction, but I must >> instead write it using a finite number of decimal digits. Neither is, >> in my view, obvious to the beginner. > > Try adding 1/3 + e; either you have to convert 1/3 to a decimal, or > find a rational approximation for e (there aren't any really good ones > but 193/71 seems promising - that's 2.7183, close enough) and then go > to the work of rational addition. No, more likely you'll go for a > finite number of decimal digits. Of course, but I'm not sure how this adds to the discussion. e is not like three tenths. Most programming languages give us a way to write what looks like exactly three tenths, but most don't give us a way write a literal that looks like it means e exactly. -- Ben.

5 16

Re: getting source code line of error?
by Ulli Horlacher Nov. 20, 2021

Nov. 20, 2021

Stefan Ram <ram(a)zedat.fu-berlin.de> wrote: > ram(a)zedat.fu-berlin.de (Stefan Ram) writes: > >except Exception as inst: > > print( traceback.format_exc() ) > > More to the point of getting the line number: As I wrote in my initial posting: I already have the line number. I am looking for the source code line! So far I use: m = re.search(r'\n\s*(.+)\n.*\n$',traceback.format_exc()) if m: print('%s %s' % (prefix,m.group(1))) -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher(a)tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

2 1

Re: Unexpected behaviour of math.floor, round and int functions (rounding)
by Ben Bacarisse Nov. 20, 2021

Nov. 20, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Sat, Nov 20, 2021 at 9:07 AM Ben Bacarisse <ben.usenet(a)bsb.me.uk> wrote: >> >> Chris Angelico <rosuav(a)gmail.com> writes: >> >> > On Sat, Nov 20, 2021 at 5:08 AM ast <ast@invalid> wrote: >> >> >> >>> 0.3 + 0.3 + 0.3 == 0.9 >> >> False >> > >> > That's because 0.3 is not 3/10. It's not because floats are >> > "unreliable" or "inaccurate". It's because the ones you're entering >> > are not what you think they are. >> > >> > When will people understand this? >> > >> > (Probably never. Sigh.) >> >> Most people understand what's going on when it's explained to them. And >> I think that being initially baffled is not unreasonable. After all, >> almost everyone comes to computers after learning that 3/10 can be >> written as 0.3. And Python "plays along" with the fiction to some >> extent. 0.3 prints as 0.3, 3/10 prints as 0.3 and 0.3 == 3/10 is True. > > In grade school, we learn that not everything can be written that way, > and 1/3 isn't actually equal to 0.3333333333. Yes. We learn early on that 0.3333333333 means 3333333333/10000000000. We don't learn that 0.3333333333 is a special notation for machines that have something called "binary floating point hardware" that does not mean 3333333333/10000000000. That has to be learned later. And every generation has to learn it afresh. > Yet somehow people > understand that computers speak binary ("have you learned to count > yet, or are you still on zeroes and ones?" -- insult to a machine > empire, in Stellaris), but don't seem to appreciate that floats are > absolutely accurate and reliable, just in binary. Yes, agreed, but I was not commenting on the odd (and incorrect) view that floating point operations are not reliable and well-defined, but on the reasonable assumption that a clever programming language might take 0.3 to mean what I was taught it meant in grade school. As an old hand, I know it won't (in most languages), and I know why it won't, and I know why that's usually the right design choice for the language. But I can also appreciate that it's by no means obvious that, to a beginner, "binary" implies the particular kind of representation that makes 0.3 not mean 3/10. After all, the rational 3/10 can be represented exactly in binary in many different ways. > But lack of knowledge is never a problem. (Or rather, it's a solvable > problem, and I'm always happy to explain things to people.) The > problem is when, following that lack of understanding, people assume > that floats are "unreliable" or "inaccurate", and that you should > never ever compare two floats for equality, because they're never > "really equal". That's what leads to horrible coding practices and > badly-defined "approximately equal" checks that cause far more harm > than a simple misunderstanding ever could on its own. Agreed. Often, the "explanations" just make things worse. -- Ben.

3 3

No right operator in tp_as_number?
by Marco Sulla Nov. 20, 2021

Nov. 20, 2021

I checked the documentation: https://docs.python.org/3/c-api/typeobj.html#number-structs and it seems that, in the Python C API, the right operators do not exist. For example, there is nb_add, that in Python is __add__, but there's no nb_right_add, that in Python is __radd__ Am I missing something?

2 1

Re: Unexpected behaviour of math.floor, round and int functions (rounding)
by Ben Bacarisse Nov. 19, 2021

Nov. 19, 2021

Chris Angelico <rosuav(a)gmail.com> writes: > On Sat, Nov 20, 2021 at 5:08 AM ast <ast@invalid> wrote: >> >>> 0.3 + 0.3 + 0.3 == 0.9 >> False > > That's because 0.3 is not 3/10. It's not because floats are > "unreliable" or "inaccurate". It's because the ones you're entering > are not what you think they are. > > When will people understand this? > > (Probably never. Sigh.) Most people understand what's going on when it's explained to them. And I think that being initially baffled is not unreasonable. After all, almost everyone comes to computers after learning that 3/10 can be written as 0.3. And Python "plays along" with the fiction to some extent. 0.3 prints as 0.3, 3/10 prints as 0.3 and 0.3 == 3/10 is True. The language (a language, not Python) could tell you that you were not getting the value you asked for. Every 0.3 could come with a warning that 0.3 can not be represented exactly as a floating point value. To avoid the warning, the programmer would write ~0.3 meaning, exactly, the binary (or whatever the base really is) floating point number closest to 0.3. -- Ben.

2 1

Unexpected behaviour of math.floor, round and int functions (rounding)
by René Silva Valdés Nov. 19, 2021

Nov. 19, 2021

Hello, I would like to report the following issue: Working with floats i noticed that: int(23.99999999999999/12) returns 1, and int(23.999999999999999/12) returns 2 This implies that int() function is rounding, which doesn't appear to be expected (documentation doesn't say anything about it). Looking further i noticed that 0.5+0.49999999999999994 returns 1. This seems to be related to double numbers' operations in C language, where 0.49999999999999994 is the greatest floating-point value less than 0.5. Counting on this several examples can be deduced, like: round(0+0.49999999999999994) returns 0, and round(1+0.49999999999999994) returns 2 This seems to be a known issue in Java (see reference) Reference: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=6430675 I hope this information is helpful, thanks in advance for reading this, Kind regards, René

4 3

Re: import question
by lucas Nov. 19, 2021

Nov. 19, 2021

ok. all good advice. thank you for that. and with all that I've decided what to do. I'm going to close off any server-side python access so that I don't expose my server or the file system to vulnerabilities and/or wonton attacks. I am building a site for education and what I will configure is allow students to setup and save their projects on the server but only direct them to program in client-side Brython, which is a javascript translation of python for browsers, hence "Brython" or "browser python". my server will provide the javascript files for Brython and its standard libraries and any processing of the student's projects will be directly on the client-side. this way there is no access to the server or cpu or memory management problems. the server will simply server html and Brython-based text, i.e., static pages, to the client browser and the browser will process and interact with the Brython directly. overall, the server will stay secure and the students can learn python through Brython. sound, right? Lucas

2 1

getting source code line of error?
by Ulli Horlacher Nov. 19, 2021

Nov. 19, 2021

I am trying to get the source code line of the last error. I know traceback.format_exc() but this contains much more information, e.g.: Traceback (most recent call last): File "./error.py", line 18, in main x=1/0 ZeroDivisionError: division by zero I could extract the source code line with re.search(), but is there an easier way? I have: exc_type,exc_str,exc_tb = sys.exc_info() fname = exc_tb.tb_frame.f_code.co_filename line = exc_tb.tb_lineno print('%s in %s line %d' % (exc_str,fname,line)) But I also want to output the line itself, not only its number. -- Ullrich Horlacher Server und Virtualisierung Rechenzentrum TIK Universitaet Stuttgart E-Mail: horlacher(a)tik.uni-stuttgart.de Allmandring 30a Tel: ++49-711-68565868 70569 Stuttgart (Germany) WWW: http://www.tik.uni-stuttgart.de/

2 1

import question
by lucas Nov. 19, 2021

Nov. 19, 2021

hello one and all, are there any other ways to import a module or package other then the "import" or "from...import..." statements? i ask because i'm allowing programming on my web2py website and i don't want any accessing packages like os or sys. thank you in advance and have a great day, lucas

5 7