[issue44571] itertools: takedowhile()

[miss-islington]

miss-islington  added the comment:


New changeset 656b0bdfaae3a36d386afe3f7b991744528c3ff7 by Miss Islington (bot) 
in branch '3.10':
bpo-44571:  Add itertool recipe for a variant of takewhile() (GH-28167)
https://github.com/python/cpython/commit/656b0bdfaae3a36d386afe3f7b991744528c3ff7


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44571] itertools: takedowhile()

[Raymond Hettinger]

Change by Raymond Hettinger :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44571] itertools: takedowhile()

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 4.0 -> 5.0
pull_requests: +26600
pull_request: https://github.com/python/cpython/pull/28173

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue44571] itertools: takedowhile()

[Raymond Hettinger]

Raymond Hettinger  added the comment:


New changeset 91be41ad933e24bff26353a19f56447e17fb6367 by Raymond Hettinger in 
branch 'main':
bpo-44571:  Add itertool recipe for a variant of takewhile() (GH-28167)
https://github.com/python/cpython/commit/91be41ad933e24bff26353a19f56447e17fb6367


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Connecting python to DB2 database

[Chris Angelico]

On Sun, Sep 5, 2021 at 1:26 PM DFS  wrote:
>
> On 9/3/2021 9:50 AM, Chris Angelico wrote:
> > On Fri, Sep 3, 2021 at 11:37 PM DFS  wrote:
> >>
> >> On 9/3/2021 1:47 AM, Chris Angelico wrote:
> >>> On Fri, Sep 3, 2021 at 3:42 PM DFS  wrote:
> 
>  Having a problem with the DB2 connector
> 
>  test.py
>  
>  import ibm_db_dbi
>  connectstring =
>  'DATABASE=xxx;HOSTNAME=localhost;PORT=5;PROTOCOL=TCPIP;UID=xxx;PWD=xxx;'
>  conn = ibm_db_dbi.connect(connectstring,'','')
> 
>  curr  = conn.cursor
>  print(curr)
> >>>
> >>> According to PEP 249, what you want is conn.cursor() not conn.cursor.
> >>>
> >>> I'm a bit surprised as to the repr of that function though, which
> >>> seems to be this line from your output:
> >>>
> >>> 
> >>>
> >>> I'd have expected it to say something like "method cursor of
> >>> Connection object", which would have been an immediate clue as to what
> >>> needs to be done. Not sure why the repr is so confusing, and that
> >>> might be something to report upstream.
> >>>
> >>> ChrisA
> >>
> >>
> >> Thanks.  I must've done it right, using conn.cursor(), 500x.
> >> Bleary-eyed from staring at code too long I guess.
> >
> > Cool cool! Glad that's working.
> >
> >> Now can you get DB2 to accept ; as a SQL statement terminator like the
> >> rest of the world?   They call it "An unexpected token"...
> >>
> >
> > Hmm, I don't know that the execute() method guarantees to allow
> > semicolons. Some implementations will strip a trailing semi, but they
> > usually won't allow interior ones, because that's a good way to worsen
> > SQL injection vulnerabilities. It's entirely possible - and within the
> > PEP 249 spec, I believe - for semicolons to be simply rejected.
>
>
> The default in the DB2 'Command Line Plus' tool is semicolons aren't
> "allowed".
>

Yeah, but that's a REPL feature. In Python, the end of a command is
signalled by the end of the string; if you want a multiline command,
you have a string with multiple lines in it. Command line SQL has to
either force you to one line, or have some means of distinguishing
between "more text coming" and "here's a command, run it".

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:58 PM Greg Ewing  wrote:
>
> On 5/09/21 2:42 am, Hope Rouselle wrote:
> > Here's what I did on this case.  The REPL is telling me that
> >
> >7.23 = 2035064081618043/281474976710656
>
> If 7.23 were exactly representable, you would have got
> 723/1000.
>
> Contrast this with something that *is* exactly representable:
>
>  >>> 7.875.as_integer_ratio()
> (63, 8)
>
> and observe that 7875/1000 == 63/8:
>
>  >>> from fractions import Fraction
>  >>> Fraction(7875,1000)
> Fraction(63, 8)
>
> In general, to find out whether a decimal number is exactly
> representable in binary, represent it as a ratio of integers
> where the denominator is a power of 10, reduce that to lowest
> terms, and compare with the result of as_integer_ratio().
>

Or let Python do that work for you!

>>> from fractions import Fraction
>>> Fraction("7.875") == Fraction(7.875)
True
>>> Fraction("7.8") == Fraction(7.8)
False

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:55 PM Hope Rouselle  wrote:
>
> Julio Di Egidio  writes:
>
> > On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote:
> >> Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
> >> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote:
> >> >> On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote:
> >> >
> >> >>> 39.61
> >> >>
> >> >> Welcome to the exciting world of roundoff error:
> >> >
> >> > Welcome to the exiting world of Usenet.
> >> >
> >> > *Plonk*
> >>
> >> Pretty harsh, isn't it? He gave a concise example of the same inaccuracy
> >> right afterwards.
> >
> > And I thought you were not seeing my posts...
> >
> > Given that I have already given a full explanation, you guys, that you
> > realise it or not, are simply adding noise for the usual pub-level
> > discussion I must most charitably guess.
> >
> > Anyway, just my opinion.  (EOD.)
>
> Which is certainly appreciated --- as a rule.  Pub-level noise is pretty
> much unavoidable in investigation, education.  Being wrong is, too,
> unavoidable in investigation, education.  There is a point we eventually
> publish at the most respected journals, but that's a whole other
> interval of the time-line.  IOW, chill out! :-D (Give us a C-k and meet
> us up in the next thread.  Oh, my, you're not a Gnus user: you are a
> G2/1.0 user.  That's pretty scary.)
>

I'm not a fan of the noise level in a pub, but I have absolutely no
problem with arguing these points out. And everyone (mostly) in this
thread is being respectful. I don't mind when someone else is wrong,
especially since - a lot of the time - I'm wrong too (or maybe I'm the
only one who's wrong).

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:44 PM Hope Rouselle  wrote:
>
> Chris Angelico  writes:
>
> > On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle  wrote:
> >>
> >> Just sharing a case of floating-point numbers.  Nothing needed to be
> >> solved or to be figured out.  Just bringing up conversation.
> >>
> >> (*) An introduction to me
> >>
> >> 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}
> >>
> >> is not foreign to me. (If that helps you to perhaps instruct me on
> >> what's going on here.)
> >>
> >> (*) A presentation of the behavior
> >>
> >> >>> import sys
> >> >>> sys.version
> >> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> >> bit (AMD64)]'
> >>
> >> >>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> >> >>> sum(ls)
> >> 39.594
> >>
> >> >>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> >> >>> sum(ls)
> >> 39.61
> >>
> >> All I did was to take the first number, 7.23, and move it to the last
> >> position in the list.  (So we have a violation of the commutativity of
> >> addition.)
> >
> > It's not about the commutativity of any particular pair of operands -
> > that's always guaranteed.
>
> Shall we take this seriously?  It has to be about the commutativity of
> at least one particular pair because it is involved with the
> commutavitity of a set of pairs.  If various pairs are involved, then at
> least one is involved.  IOW, it is about the commutativity of some pair
> of operands and so it could not be the case that it's not about the
> commutativity of any.  (Lol.  I hope that's not too insubordinate.  I
> already protested against a claim for associativity in this thread and
> now I'm going for the king of the hill, for whom I have always been so
> grateful!)

No, that is not the case. Look at the specific pairs of numbers that get added.

ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]

>>> 7.23 + 8.41
15.64
>>> _ + 6.15
21.79
>>> _ + 2.31
24.098
>>> _ + 7.73
31.83
>>> _ + 7.77
39.594

And with the other list:

ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]

>>> 8.41 + 6.15
14.56
>>> _ + 2.31
16.87
>>> _ + 7.73
24.6
>>> _ + 7.77
32.375
>>> _ + 7.23
39.61

If commutativity is being violated, then there should be some
situation where you could have written "7.73 + _" instead of "_ +
7.73" or equivalent, and gotten a different result. But that is simply
not the case. What you are seeing is NOT commutativity, but the
consequences of internal rounding, which is a matter of associativity.

> Alright.  Thanks so much for this example.  Here's a new puzzle for me.
> The REPL makes me think that both 21.79 and 2.31 *are* representable
> exactly in Python's floating-point datatype because I see:
>
> >>> 2.31
> 2.31
> >>> 21.79
> 21.79
>
> When I add them, the result obtained makes me think that the sum is
> *not* representable exactly in Python's floating-point number:
>
> >>> 21.79 + 2.31
> 24.098
>
> However, when I type 24.10 explicitly, the REPL makes me think that
> 24.10 *is* representable exactly:
>
> >>> 24.10
> 24.1
>
> I suppose I cannot trust the appearance of the representation?  What's
> really going on there?  (Perhaps the trouble appears while Python is
> computing the sum of the numbers 21.79 and 2.31?)  Thanks so much!

The representation is a conversion from the internal format into
decimal digits. It is rounded for convenience of display, because you
don't want it to look like this:

>>> print(Fraction(24.10))
3391773469363405/140737488355328

Since that's useless, the repr of a float rounds it to the shortest
plausible number as represented in decimal digits. This has nothing to
do with whether it is exactly representable, and everything to do with
displaying things usefully in as many situations as possible :)

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:39 PM Alan Gauld via Python-list
 wrote:
>
> On 03/09/2021 18:37, Chris Angelico wrote:
>
>  Without DST the schools opened in the dark so all the kids
>  had to travel to school in the dark and the number of
>  traffic accidents while crossing roads jumped.
> >
> > Are you saying that you had DST in winter, or that, when summer *and*
> > DST came into effect, there was more light at dawn? Because a *lot* of
> > people confuse summer and DST, and credit DST with the natural effects
> > of the season change.
>
> OK, I see the confusion. What I should point out was that the
> experiment involved us staying on DST and not reverting to UTC
> in the winter - that unified us with most of the EU apparently...
>
> So although I'm saying DST it was really the non-reversion from
> DST to UTC that caused problems. Arguably, if we just stayed on
> UTC and didn't have DST at all there would be no issue - except
> we'd be an hour out of sync with the EU. (Post Brexit that may
> not be seen as a problem!! :-)

Oh, I see what you mean.

When I complain about DST, I'm complaining about the repeated changes
of UTC offset. Whether you either stay on UTC+0 or stay on UTC+1, it's
basically the same, doesn't make a lot of difference. "Abolishing DST"
and "staying on summer time permanently" are effectively the same.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 1:04 PM Hope Rouselle  wrote:
> The same question in other words --- what's a trivial way for the REPL
> to show me such cycles occur?
>
> >> 7.23.as_integer_ratio()
> >>> (2035064081618043, 281474976710656)
>
> Here's what I did on this case.  The REPL is telling me that
>
>   7.23 = 2035064081618043/281474976710656
>
> If that were true, then 7.23 * 281474976710656 would have to equal
> 2035064081618043.  So I typed:
>
> >>> 7.23 * 281474976710656
> 2035064081618043.0
>
> That agrees with the falsehood.  I'm getting no evidence of the problem.
>
> When take control of my life out of the hands of misleading computers, I
> calculate the sum:
>
>844424930131968
>  +5629499534213120
> 197032483697459200
> ==
> 203506408161804288
> =/= 203506408161804300
>
> How I can save the energy spent on manual verification?
>

What you've stumbled upon here is actually a neat elegance of
floating-point, and an often-forgotten fundamental of it: rounding
occurs exactly the same regardless of the scale. The number 7.23 is
represented with a certain mantissa, and multiplying it by some power
of two doesn't change the mantissa, only the exponent. So the rounding
happens exactly the same, and it comes out looking equal!

The easiest way, in Python, to probe this sort of thing is to use
either fractions.Fraction or decimal.Decimal. I prefer Fraction, since
a float is fundamentally a rational number, and you can easily see
what's happening. You can construct a Fraction from a string, and
it'll do what you would expect; or you can construct one from a float,
and it'll show you what that float truly represents.

It's often cleanest to print fractions out rather than just dumping
them to the console, since the str() of a fraction looks like a
fraction, but the repr() looks like a constructor call.

>>> Fraction(0.25)
Fraction(1, 4)
>>> Fraction(0.1)
Fraction(3602879701896397, 36028797018963968)

If it looks like the number you put in, it was perfectly
representable. If it looks like something of roughly that many digits,
it's probably not the number you started with.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Chih-Hsuan Yen]

Chih-Hsuan Yen  added the comment:

Many thanks for the fast and great fix!

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem with python

[Grant Edwards]

On 2021-09-04, Peter J. Holzer  wrote:
> On 2021-09-04 14:29:47 -0500, Igor Korot wrote:
>> Will this syntax work in python 2?
>
> Yes. It's just a redundant pair of parentheses.

Not really. With the parens, it doesn't produce the same results in
2.x unless you import the print function from the future:

 Python 3.9.6 (default, Aug  9 2021, 12:35:39)
 [GCC 10.3.0] on linux
 Type "help", "copyright", "credits" or "license" for more information.
 >>> print(1,2)
 1 2

 Python 2.7.18 (default, Jul 18 2021, 14:51:54)
 [GCC 10.3.0] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> print(1,2)
 (1, 2)

 Python 2.7.18 (default, Jul 18 2021, 14:51:54)
 [GCC 10.3.0] on linux2
 Type "help", "copyright", "credits" or "license" for more information.
 >>> from __future__ import print_function
 >>> print(1,2)
 1 2




-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help me split a string into elements

[Neil]

DFS  wrote:
> Typical cases:
>  lines = [('one\ntwo\nthree\n')]
>  print(str(lines[0]).splitlines())
>  ['one', 'two', 'three']
> 
>  lines = [('one two three\n')]
>  print(str(lines[0]).split())
>  ['one', 'two', 'three']
> 
> 
> That's the result I'm wanting, but I get data in a slightly different 
> format:
> 
> lines = [('one\ntwo\nthree\n',)]
> 
> Note the comma after the string data, but inside the paren. 
> splitlines() doesn't work on it:
> 
> print(str(lines[0]).splitlines())
> ["('one\\ntwo\\nthree\\n',)"]
> 
> 
> I've banged my head enough - can someone spot an easy fix?
> 
> Thanks

lines[0][0].splitlines()

(You have a list containing a tuple containing the string you want to
split up.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:50 PM Hope Rouselle  wrote:
>
> Christian Gollwitzer  writes:
>
> > Am 02.09.21 um 15:51 schrieb Hope Rouselle:
> >> Just sharing a case of floating-point numbers.  Nothing needed to be
> >> solved or to be figured out.  Just bringing up conversation.
> >> (*) An introduction to me
> >> 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}
> >> is not foreign to me. (If that helps you to perhaps instruct me on
> >> what's going on here.)
> >> (*) A presentation of the behavior
> >>
> > import sys
> > sys.version
> >> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> >> bit (AMD64)]'
> >>
> > ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> > sum(ls)
> >> 39.594
> >>
> > ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> > sum(ls)
> >> 39.61
> >> All I did was to take the first number, 7.23, and move it to the
> >> last
> >> position in the list.  (So we have a violation of the commutativity of
> >> addition.)
> >
> > I believe it is not commutativity, but associativity, that is
> > violated.
>
> Shall we take this seriously?  (I will disagree, but that doesn't mean I
> am not grateful for your post.  Quite the contary.)  It in general
> violates associativity too, but the example above couldn't be referring
> to associativity because the second sum above could not be obtained from
> associativity alone.  Commutativity is required, applied to five pairs
> of numbers.  How can I go from
>
>   7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>
> to
>
>   8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23?
>
> Perhaps only through various application of commutativity, namely the
> ones below. (I omit the parentheses for less typing.  I suppose that
> does not create much trouble.  There is no use of associativity below,
> except for the intented omission of parentheses.)
>
>  7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>= 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77
>= 8.41 + 6.15 + 7.23 + 2.31 + 7.73 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.23 + 7.73 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.73 + 7.23 + 7.77
>= 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23.
>

Show me the pairs of numbers. You'll find that they are not the same
numbers. Commutativity is specifically that a+b == b+a and you won't
find any situation where that is violated.

As soon as you go to three or more numbers, what you're doing is
changing which numbers get added first, which is this:

a + (b + c) != (a + b) + c

and this can most certainly be violated due to intermediate rounding.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Terry Reedy]

On 9/4/2021 2:27 PM, Igor Korot wrote:

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from distutils import sysconfig


In 3.10, distutils and d.sysconfig are deprecated, with suggestions to 
use setuptools or sysconfig modules instead.



print sysconfig.get_python_inc()

   File "", line 1
 print sysconfig.get_python_inc()
   ^
SyntaxError: invalid syntax


In interactive mode, print is not usually needed.

>>> sysconfig.get_python_inc()
'C:\\Programs\\Python310\\include'


--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Chris Angelico]

On Sun, Sep 5, 2021 at 12:48 PM Hope Rouselle  wrote:
>
> Chris Angelico  writes:
>
> > On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle  wrote:
> >>
> >> Hope Rouselle  writes:
> >>
> >> > Just sharing a case of floating-point numbers.  Nothing needed to be
> >> > solved or to be figured out.  Just bringing up conversation.
> >> >
> >> > (*) An introduction to me
> >> >
> >> > 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}
> >> >
> >> > is not foreign to me. (If that helps you to perhaps instruct me on
> >> > what's going on here.)
> >> >
> >> > (*) A presentation of the behavior
> >> >
> >>  import sys
> >>  sys.version
> >> > '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> >> > bit (AMD64)]'
> >> >
> >>  ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> >>  sum(ls)
> >> > 39.594
> >> >
> >>  ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> >>  sum(ls)
> >> > 39.61
> >> >
> >> > All I did was to take the first number, 7.23, and move it to the last
> >> > position in the list.  (So we have a violation of the commutativity of
> >> > addition.)
> >>
> >> Suppose these numbers are prices in dollar, never going beyond cents.
> >> Would it be safe to multiply each one of them by 100 and therefore work
> >> with cents only?  For instance
> >
> > Yes and no. It absolutely *is* safe to always work with cents, but to
> > do that, you have to be consistent: ALWAYS work with cents, never with
> > floating point dollars.
> >
> > (Or whatever other unit you choose to use. Most currencies have a
> > smallest-normally-used-unit, with other currency units (where present)
> > being whole number multiples of that minimal unit. Only in forex do
> > you need to concern yourself with fractional cents or fractional yen.)
> >
> > But multiplying a set of floats by 100 won't necessarily solve your
> > problem; you may have already fallen victim to the flaw of assuming
> > that the numbers are represented accurately.
>
> Hang on a second.  I see it's always safe to work with cents, but I'm
> only confident to say that when one gives me cents to start with.  In
> other words, if one gives me integers from the start.  (Because then, of
> course, I don't even have floats to worry about.)  If I'm given 1.17,
> say, I am not confident that I could turn this number into 117 by
> multiplying it by 100.  And that was the question.  Can I always
> multiply such IEEE 754 dollar amounts by 100?
>
> Considering your last paragraph above, I should say: if one gives me an
> accurate floating-point representation, can I assume a multiplication of
> it by 100 remains accurately representable in IEEE 754?

Humans usually won't give you IEEE 754 floats. What they'll usually
give you is a text string. Let's say you ask someone to type in the
prices of various items, the quantities thereof, and the shipping. You
take strings like "1.17" (or "$1.17"), and you parse that into the
integer 117.

> Hm, I think I see what you're saying.  You're saying multiplication and
> division in IEEE 754 is perfectly safe --- so long as the numbers you
> start with are accurately representable in IEEE 754 and assuming no
> overflow or underflow would occur.  (Addition and subtraction are not
> safe.)
>

All operations are equally valid. Anything that causes rounding can
cause loss of data, and that can happen with multiplication/division
as well as addition/subtraction. But yes, with the caveats you give,
everything is safe.

ChrisA
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Connecting python to DB2 database

[DFS]

On 9/3/2021 9:50 AM, Chris Angelico wrote:

On Fri, Sep 3, 2021 at 11:37 PM DFS  wrote:


On 9/3/2021 1:47 AM, Chris Angelico wrote:

On Fri, Sep 3, 2021 at 3:42 PM DFS  wrote:


Having a problem with the DB2 connector

test.py

import ibm_db_dbi
connectstring =
'DATABASE=xxx;HOSTNAME=localhost;PORT=5;PROTOCOL=TCPIP;UID=xxx;PWD=xxx;'
conn = ibm_db_dbi.connect(connectstring,'','')

curr  = conn.cursor
print(curr)


According to PEP 249, what you want is conn.cursor() not conn.cursor.

I'm a bit surprised as to the repr of that function though, which
seems to be this line from your output:



I'd have expected it to say something like "method cursor of
Connection object", which would have been an immediate clue as to what
needs to be done. Not sure why the repr is so confusing, and that
might be something to report upstream.

ChrisA



Thanks.  I must've done it right, using conn.cursor(), 500x.
Bleary-eyed from staring at code too long I guess.


Cool cool! Glad that's working.


Now can you get DB2 to accept ; as a SQL statement terminator like the
rest of the world?   They call it "An unexpected token"...



Hmm, I don't know that the execute() method guarantees to allow
semicolons. Some implementations will strip a trailing semi, but they
usually won't allow interior ones, because that's a good way to worsen
SQL injection vulnerabilities. It's entirely possible - and within the
PEP 249 spec, I believe - for semicolons to be simply rejected.



The default in the DB2 'Command Line Plus' tool is semicolons aren't 
"allowed".



db2 => connect to SAMPLE

db2 => SELECT COUNT(*) FROM STAFF;
SQL0104N  An unexpected token ";" was found following "COUNT(*) FROM STAFF".
Expected tokens may include:  "END-OF-STATEMENT".  SQLSTATE=42601

db2 => SELECT COUNT(*) FROM STAFF
1
---
 35
  1 record(s) selected.



But I should've known you can set the terminator value:

https://www.ibm.com/docs/en/db2/11.1?topic=clp-options

Option :  -t
Description:  This option tells the command line processor to use a
  semicolon (;) as the statement termination character. 
Default:  OFF


$ db2 -t

turns it on in CommandLinePlus - and the setting applies to the DB-API 
code too.

--
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Christian Gollwitzer]

Am 04.09.21 um 14:48 schrieb Hope Rouselle:

Christian Gollwitzer  writes:


Am 02.09.21 um 15:51 schrieb Hope Rouselle:

Just sharing a case of floating-point numbers.  Nothing needed to be
solved or to be figured out.  Just bringing up conversation.
(*) An introduction to me
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}
is not foreign to me. (If that helps you to perhaps instruct me on
what's going on here.)
(*) A presentation of the behavior


import sys
sys.version

'3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
bit (AMD64)]'


ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
sum(ls)

39.594


ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
sum(ls)

39.61
All I did was to take the first number, 7.23, and move it to the
last
position in the list.  (So we have a violation of the commutativity of
addition.)


I believe it is not commutativity, but associativity, that is
violated.


Shall we take this seriously?  (I will disagree, but that doesn't mean I
am not grateful for your post.  Quite the contary.)  It in general
violates associativity too, but the example above couldn't be referring
to associativity because the second sum above could not be obtained from
associativity alone.  Commutativity is required, applied to five pairs
of numbers.  How can I go from

   7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77

to

   8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23?

Perhaps only through various application of commutativity, namely the
ones below. (I omit the parentheses for less typing.  I suppose that
does not create much trouble.  There is no use of associativity below,
except for the intented omission of parentheses.)


With the parens it will become more obvious.



  7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
= 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77


The sum is evaluated as

(((7.23 + 8.41) + 6.15 + ...)

For the first shift, you are correct that commutativity will result in

(((8.41 + 7.23) + 6.15 + ...)

But you can't go in one step to

(((8.41 + 6.15) + 7.23 + ...)

with  the commutativity law alone. Instead, a sequence of associativity 
and commutativity is required to move the 7.23 out of the first pair of 
parentheses.


And what I was trying to say, the commutative steps *are* equal in 
floating point arithmetics, whereas the associative steps are not.


Christian

--
https://mail.python.org/mailman/listinfo/python-list

Re: Select columns based on dates - Pandas

[Richard Medina]

On Friday, September 3, 2021 at 11:57:12 AM UTC-5, Martin Di Paola wrote:
> You may want to reshape the dataset to a tidy format: Pandas works 
> better with that format. 
> 
> Let's assume the following dataset (this is what I understood from your 
> message): 
> 
> In [34]: df = pd.DataFrame({ 
> ...: 'Country': ['us', 'uk', 'it'], 
> ...: '01/01/2019': [10, 20, 30], 
> ...: '02/01/2019': [12, 22, 32], 
> ...: '03/01/2019': [14, 24, 34], 
> ...: }) 
> 
> In [35]: df 
> Out[35]: 
> Country 01/01/2019 02/01/2019 03/01/2019 
> 0 us 10 12 14 
> 1 uk 20 22 24 
> 2 it 30 32 34 
> 
> Then, reshape it to a tidy format. Notice how each row now represents 
> a single measure. 
> 
> In [43]: pd.melt(df, id_vars=['Country'], var_name='Date', 
> value_name='Cases') 
> Out[43]: 
> Country Date Cases 
> 0 us 01/01/2019 10 
> 1 uk 01/01/2019 20 
> 2 it 01/01/2019 30 
> 3 us 02/01/2019 12 
> 4 uk 02/01/2019 22 
> 5 it 02/01/2019 32 
> 6 us 03/01/2019 14 
> 7 uk 03/01/2019 24 
> 8 it 03/01/2019 34 
> 
> I used strings to represent the dates but it is much handy work 
> with real date objects. 
> 
> In [44]: df2 = _ 
> In [45]: df2['Date'] = pd.to_datetime(df2['Date']) 
> 
> Now we can filter by date: 
> 
> In [50]: df2[df2['Date'] < '2019-03-01'] 
> Out[50]: 
> Country Date Cases 
> 0 us 2019-01-01 10 
> 1 uk 2019-01-01 20 
> 2 it 2019-01-01 30 
> 3 us 2019-02-01 12 
> 4 uk 2019-02-01 22 
> 5 it 2019-02-01 32 
> 
> With that you could create three dataframes, one per month. 
> 
> Thanks, 
> Martin.
> On Thu, Sep 02, 2021 at 12:28:31PM -0700, Richard Medina wrote: 
> >Hello, forum, 
> >I have a data frame with covid-19 cases per month from 2019 - 2021 like a 
> >header like this: 
> > 
> >Country, 01/01/2019, 2/01/2019, 01/02/2019, 3/01/2019, ... 01/01/2021, 
> >2/01/2021, 01/02/2021, 3/01/2021 
> > 
> >I want to filter my data frame for columns of a specific month range of 
> >march to September of 2019, 2020, and 2021 only (three data frames). 
> > 
> >Any ideas? 
> >Thank you 
> > 
> >
> >-- 
> >https://mail.python.org/mailman/listinfo/python-list
Thank you, Martin,
Is it possible to select/filter the dates (like columns from a date range) from 
the columns without reshaping them?
Thank you for your answer.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on writing a while loop for rolling two dice

[Hope Rouselle]

"Michael F. Stemper"  writes:

> On 04/09/2021 08.53, Hope Rouselle wrote:
>> Chris Angelico  writes:
>
>>> And at this point, it's looking pretty much identical to the for loop
>>> version. Ultimately, they're all the same and you can pick and choose
>>> elements from each of them.
>> I see.  That's why C must have added the do-while, but yeah --- it's
>> not
>> really worth it.
>
> Kernighan and Ritchie agree(d) with you. Per _The C Programming
> Language__:
>   Experience shows that do-while is much less used that while
>   and for.
>
> (Second edition, Section 3.6, page 63)

Special thanks for the reference!  Here's what they say on the first
edition.

  ``As might be expected, do-while is much less used than while and for,
  accounting for perhaps five percent of all loops.''  (First edition,
  section 3.6, page 59.)  

They looked into a sample and decided to remove the statistic. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Dennis Lee Bieber]

On Sat, 4 Sep 2021 22:41:12 +0200, "Peter J. Holzer" 
declaimed the following:

>Python 3 to be time well spent in 2021, especially not to someone who
>apparently just wants to report a bug to some unnamed project (whose
>maintainers may or may not care about Python2 compatibility).
>

Given the nature of the error reported by the OP... It may be closer to
state "whose maintainers may or may not care about" /Python3/
"compatibility"; the code appears to already be Python2 compatible 



-- 
Wulfraed Dennis Lee Bieber AF6VN
wlfr...@ix.netcom.comhttp://wlfraed.microdiversity.freeddns.org/

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Hope Rouselle]

Igor Korot  writes:

> Hi,
> Will this syntax work in python 2?

If you say

  print(something)

it works in both.  So, stick to this syntax.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Help me split a string into elements

[DFS]

On 9/4/2021 5:55 PM, DFS wrote:

Typical cases:
  lines = [('one\ntwo\nthree\n')]
  print(str(lines[0]).splitlines())
  ['one', 'two', 'three']

  lines = [('one two three\n')]
  print(str(lines[0]).split())
  ['one', 'two', 'three']


That's the result I'm wanting, but I get data in a slightly different 
format:


lines = [('one\ntwo\nthree\n',)]

Note the comma after the string data, but inside the paren. splitlines() 
doesn't work on it:


print(str(lines[0]).splitlines())
["('one\\ntwo\\nthree\\n',)"]


I've banged my head enough - can someone spot an easy fix?

Thanks



I got it:

lines = [('one\ntwo\nthree\n',)]
print(str(lines[0][0]).splitlines())
['one', 'two', 'three']

--
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Christian Gollwitzer  writes:

> Am 04.09.21 um 14:48 schrieb Hope Rouselle:
>> Christian Gollwitzer  writes:
>> 
>>> Am 02.09.21 um 15:51 schrieb Hope Rouselle:
 Just sharing a case of floating-point numbers.  Nothing needed to be
 solved or to be figured out.  Just bringing up conversation.
 (*) An introduction to me
 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}
 is not foreign to me. (If that helps you to perhaps instruct me on
 what's going on here.)
 (*) A presentation of the behavior

>>> import sys
>>> sys.version
 '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
 bit (AMD64)]'

>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(ls)
 39.594

>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(ls)
 39.61
 All I did was to take the first number, 7.23, and move it to the
 last
 position in the list.  (So we have a violation of the commutativity of
 addition.)
>>>
>>> I believe it is not commutativity, but associativity, that is
>>> violated.
>> Shall we take this seriously?  (I will disagree, but that doesn't
>> mean I
>> am not grateful for your post.  Quite the contary.)  It in general
>> violates associativity too, but the example above couldn't be referring
>> to associativity because the second sum above could not be obtained from
>> associativity alone.  Commutativity is required, applied to five pairs
>> of numbers.  How can I go from
>>7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>> to
>>8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23?
>> Perhaps only through various application of commutativity, namely
>> the
>> ones below. (I omit the parentheses for less typing.  I suppose that
>> does not create much trouble.  There is no use of associativity below,
>> except for the intented omission of parentheses.)
>
> With the parens it will become more obvious.
>
>>   7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
>> = 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77
>
> The sum is evaluated as
>
>   (((7.23 + 8.41) + 6.15 + ...)
>
> For the first shift, you are correct that commutativity will result in
>
>   (((8.41 + 7.23) + 6.15 + ...)
>
> But you can't go in one step to
>
>   (((8.41 + 6.15) + 7.23 + ...)
>
> with  the commutativity law alone. Instead, a sequence of
> associativity and commutativity is required to move the 7.23 out of
> the first pair of parentheses.
>
> And what I was trying to say, the commutative steps *are* equal in
> floating point arithmetics, whereas the associative steps are not.

Oh, I see it.  Very good point!  Lesson learned.
-- 
https://mail.python.org/mailman/listinfo/python-list

Help me split a string into elements

[DFS]

Typical cases:
 lines = [('one\ntwo\nthree\n')]
 print(str(lines[0]).splitlines())
 ['one', 'two', 'three']

 lines = [('one two three\n')]
 print(str(lines[0]).split())
 ['one', 'two', 'three']


That's the result I'm wanting, but I get data in a slightly different 
format:


lines = [('one\ntwo\nthree\n',)]

Note the comma after the string data, but inside the paren. 
splitlines() doesn't work on it:


print(str(lines[0]).splitlines())
["('one\\ntwo\\nthree\\n',)"]


I've banged my head enough - can someone spot an easy fix?

Thanks
--
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Julio Di Egidio  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. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Hope Rouselle  writes:

> Greg Ewing  writes:
>
>> On 5/09/21 2:42 am, Hope Rouselle wrote:
>>> Here's what I did on this case.  The REPL is telling me that
>>>7.23 = 2035064081618043/281474976710656
>>
>> If 7.23 were exactly representable, you would have got
>> 723/1000.
>>
>> Contrast this with something that *is* exactly representable:
>>
> 7.875.as_integer_ratio()
>> (63, 8)
>>
>> and observe that 7875/1000 == 63/8:
>>
> from fractions import Fraction
> Fraction(7875,1000)
>> Fraction(63, 8)
>>
>> In general, to find out whether a decimal number is exactly
>> representable in binary, represent it as a ratio of integers
>> where the denominator is a power of 10, reduce that to lowest
>> terms, and compare with the result of as_integer_ratio().
>
> That makes perfect sense and answers my question.  I appreciate it.

Here's my homework in high-precision.  Thoughts?  Thank you!

--8<---cut here---start->8---
def is_representable(s):
  return in_lowest_terms(rat_power_of_10(s)) == float(s).as_integer_ratio()

# >>> is_representable("1.5")
# True
# 
# >>> is_representable("0.1")
# False

def rat_power_of_10(s):
  """I assume s is a numeric string in the format ."""
  if "." not in s:
return int(s), 1
  integral, fractional = s.split(".")
  return int(integral + fractional), 10**(len(fractional))

# >>> rat_power_of_10("72.100")
# (72100, 1000)

def in_lowest_terms(rat):
  from math import gcd
  n, d = rat
  return n//gcd(n, d),  d//gcd(n, d)

# >>> in_lowest_terms( (72100, 1000) )
# (721, 10)
--8<---cut here---end--->8---
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Richard Damon  writes:

> On 9/4/21 9:40 AM, Hope Rouselle wrote:
>> Chris Angelico  writes:
>> 
>>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle  wrote:

 Hope Rouselle  writes:

> Just sharing a case of floating-point numbers.  Nothing needed to be
> solved or to be figured out.  Just bringing up conversation.
>
> (*) An introduction to me
>
> 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}
>
> is not foreign to me. (If that helps you to perhaps instruct me on
> what's going on here.)
>
> (*) A presentation of the behavior
>
 import sys
 sys.version
> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
> bit (AMD64)]'
>
 ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
 sum(ls)
> 39.594
>
 ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
 sum(ls)
> 39.61
>
> All I did was to take the first number, 7.23, and move it to the last
> position in the list.  (So we have a violation of the commutativity of
> addition.)

 Suppose these numbers are prices in dollar, never going beyond cents.
 Would it be safe to multiply each one of them by 100 and therefore work
 with cents only?  For instance
>>>
>>> Yes and no. It absolutely *is* safe to always work with cents, but to
>>> do that, you have to be consistent: ALWAYS work with cents, never with
>>> floating point dollars.
>>>
>>> (Or whatever other unit you choose to use. Most currencies have a
>>> smallest-normally-used-unit, with other currency units (where present)
>>> being whole number multiples of that minimal unit. Only in forex do
>>> you need to concern yourself with fractional cents or fractional yen.)
>>>
>>> But multiplying a set of floats by 100 won't necessarily solve your
>>> problem; you may have already fallen victim to the flaw of assuming
>>> that the numbers are represented accurately.
>> 
>> Hang on a second.  I see it's always safe to work with cents, but I'm
>> only confident to say that when one gives me cents to start with.  In
>> other words, if one gives me integers from the start.  (Because then, of
>> course, I don't even have floats to worry about.)  If I'm given 1.17,
>> say, I am not confident that I could turn this number into 117 by
>> multiplying it by 100.  And that was the question.  Can I always
>> multiply such IEEE 754 dollar amounts by 100?
>> 
>> Considering your last paragraph above, I should say: if one gives me an
>> accurate floating-point representation, can I assume a multiplication of
>> it by 100 remains accurately representable in IEEE 754?
>> 
>
> Multiplication by 100 might not be accurate if the number you are
> starting with is close to the limit of precision, because 100 is
> 1.1001 x 64 so multiplying by 100 adds about 5 more 'bits' to the
> representation of the number. In your case, the numbers are well below
> that point.

Alright.  That's clear now.  Thanks so much!

 --8<---cut here---start->8---
>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(map(lambda x: int(x*100), ls)) / 100
 39.6

>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(map(lambda x: int(x*100), ls)) / 100
 39.6
 --8<---cut here---end--->8---

 Or multiplication by 100 isn't quite ``safe'' to do with floating-point
 numbers either?  (It worked in this case.)
>>>
>>> You're multiplying and then truncating, which risks a round-down
>>> error. Try adding a half onto them first:
>>>
>>> int(x * 100 + 0.5)
>>>
>>> But that's still not a perfect guarantee. Far safer would be to
>>> consider monetary values to be a different type of value, not just a
>>> raw number. For instance, the value $7.23 could be stored internally
>>> as the integer 723, but you also know that it's a value in USD, not a
>>> simple scalar. It makes perfect sense to add USD+USD, it makes perfect
>>> sense to multiply USD*scalar, but it doesn't make sense to multiply
>>> USD*USD.
>> 
>> Because of the units?  That would be USD squared?  (Nice analysis.)
>> 
 I suppose that if I multiply it by a power of two, that would be an
 operation that I can be sure will not bring about any precision loss
 with floating-point numbers.  Do you agree?
>>>
>>> Assuming you're nowhere near 2**53, yes, that would be safe. But so
>>> would multiplying by a power of five. The problem isn't precision loss
>>> from the multiplication - the problem is that your input numbers
>>> aren't what you think they are. That number 7.23, for instance, is
>>> really
>> 
>> Hm, I think I see what you're saying.  You're saying multiplication and
>> division in IEEE 754 is perfectly safe --- so long as the numbers 

Re: on floating-point numbers

[Hope Rouselle]

Greg Ewing  writes:

> On 5/09/21 2:42 am, Hope Rouselle wrote:
>> Here's what I did on this case.  The REPL is telling me that
>>7.23 = 2035064081618043/281474976710656
>
> If 7.23 were exactly representable, you would have got
> 723/1000.
>
> Contrast this with something that *is* exactly representable:
>
 7.875.as_integer_ratio()
> (63, 8)
>
> and observe that 7875/1000 == 63/8:
>
 from fractions import Fraction
 Fraction(7875,1000)
> Fraction(63, 8)
>
> In general, to find out whether a decimal number is exactly
> representable in binary, represent it as a ratio of integers
> where the denominator is a power of 10, reduce that to lowest
> terms, and compare with the result of as_integer_ratio().

That makes perfect sense and answers my question.  I appreciate it.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Julio Di Egidio  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
> 
>
> Here is some more introductory stuff:
> 
> 

Rozman's was pretty concise and nice.  Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Greg Ewing]

On 5/09/21 2:42 am, Hope Rouselle wrote:

Here's what I did on this case.  The REPL is telling me that

   7.23 = 2035064081618043/281474976710656


If 7.23 were exactly representable, you would have got
723/1000.

Contrast this with something that *is* exactly representable:

>>> 7.875.as_integer_ratio()
(63, 8)

and observe that 7875/1000 == 63/8:

>>> from fractions import Fraction
>>> Fraction(7875,1000)
Fraction(63, 8)

In general, to find out whether a decimal number is exactly
representable in binary, represent it as a ratio of integers
where the denominator is a power of 10, reduce that to lowest
terms, and compare with the result of as_integer_ratio().

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: on writing a while loop for rolling two dice

[Hope Rouselle]

"Peter J. Holzer"  writes:

> On 2021-09-02 11:28:21 -0300, Hope Rouselle wrote:
>> dn  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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Julio Di Egidio  writes:

> On Thursday, 2 September 2021 at 16:51:24 UTC+2, Christian Gollwitzer wrote:
>> Am 02.09.21 um 16:49 schrieb Julio Di Egidio:
>> > On Thursday, 2 September 2021 at 16:41:38 UTC+2, Peter Pearson wrote: 
>> >> On Thu, 02 Sep 2021 10:51:03 -0300, Hope Rouselle wrote: 
>> > 
>> >>> 39.61 
>> >> 
>> >> Welcome to the exciting world of roundoff error: 
>> > 
>> > Welcome to the exiting world of Usenet. 
>> > 
>> > *Plonk*
>> 
>> Pretty harsh, isn't it? He gave a concise example of the same inaccuracy 
>> right afterwards. 
>
> And I thought you were not seeing my posts...
>
> Given that I have already given a full explanation, you guys, that you
> realise it or not, are simply adding noise for the usual pub-level
> discussion I must most charitably guess.
>
> Anyway, just my opinion.  (EOD.)

Which is certainly appreciated --- as a rule.  Pub-level noise is pretty
much unavoidable in investigation, education.  Being wrong is, too,
unavoidable in investigation, education.  There is a point we eventually
publish at the most respected journals, but that's a whole other
interval of the time-line.  IOW, chill out! :-D (Give us a C-k and meet
us up in the next thread.  Oh, my, you're not a Gnus user: you are a
G2/1.0 user.  That's pretty scary.)

By the way, how's sci.logic going?  I, too, lost my patience there. :-)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on writing a while loop for rolling two dice

[Hope Rouselle]

Chris Angelico  writes:

> On Fri, Sep 3, 2021 at 4:33 AM Hope Rouselle  wrote:
>> 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.
>
> It's on the cusp. When you ask someone to express the concept of "do
> this until this happens", obviously that's a while loop; but as soon
> as you introduce the iteration counter, it becomes less obvious, since
> "iterate over counting numbers until this happens" is a quite viable
> way to express this. However, if the students don't know
> itertools.count(), they'll most likely put in an arbitrary limit (like
> "for c in range(1)"), which you can call them out for.
>
>> 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.
>
> That may be the case, but in Python, I almost never write "while
> True". Consider the two while loops in this function:
>
> https://github.com/Rosuav/shed/blob/master/autohost_manager.py#L92
>
> Thanks to Python's flexibility and efficient compilation, these loops
> are as descriptive as those with actual conditions, while still
> behaving exactly like "while True". (The inner loop, "more pages",
> looks superficially like it should be a for loop - "for page in
> pages:" - but the data is coming from successive API calls, so it
> can't know.)

That's pretty nice.  I did suggest the same to my students, showing your
code to them, actually.  The course explicitly avoided talking about
regular values being considered True, but now I couldn't keep the truth
from them.

>> 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.
>
> You're overlaying two loops here. One is iterating "c" up from zero,
> the other is calling a function and testing its results. It's up to
> you which of these should be considered the more important, and which
> is a bit of extra work added onto it. With the counter as primary, you
> get something like this:
>
> for c in itertools.count():
> x, y = roll()
> if x == y: return c, x, y
>
> With the roll comparison as primary, you get this:
>
> c, x, y = 0, 0, 1
> while x != y:
> x, y = roll()
> c += 1
> return c, x, y
>
> Reworking the second into a do-while style (Python doesn't have that,
> so we have to write it manually):
>
> c = 0
> while "x and y differ":
> x, y = roll()
> c += 1
> if x == y: break
> return c, x, y
>
> And at this point, it's looking pretty much identical to the for loop
> version. Ultimately, they're all the same and you can pick and choose
> elements from each of them.

I see.  That's why C must have added the do-while, but yeah --- it's not
really worth it.  (An educational investigation.  Thank you.)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Richard Damon]

On 9/4/21 9:40 AM, Hope Rouselle wrote:
> Chris Angelico  writes:
> 
>> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle  wrote:
>>>
>>> Hope Rouselle  writes:
>>>
 Just sharing a case of floating-point numbers.  Nothing needed to be
 solved or to be figured out.  Just bringing up conversation.

 (*) An introduction to me

 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}

 is not foreign to me. (If that helps you to perhaps instruct me on
 what's going on here.)

 (*) A presentation of the behavior

>>> import sys
>>> sys.version
 '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
 bit (AMD64)]'

>>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>> sum(ls)
 39.594

>>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>> sum(ls)
 39.61

 All I did was to take the first number, 7.23, and move it to the last
 position in the list.  (So we have a violation of the commutativity of
 addition.)
>>>
>>> Suppose these numbers are prices in dollar, never going beyond cents.
>>> Would it be safe to multiply each one of them by 100 and therefore work
>>> with cents only?  For instance
>>
>> Yes and no. It absolutely *is* safe to always work with cents, but to
>> do that, you have to be consistent: ALWAYS work with cents, never with
>> floating point dollars.
>>
>> (Or whatever other unit you choose to use. Most currencies have a
>> smallest-normally-used-unit, with other currency units (where present)
>> being whole number multiples of that minimal unit. Only in forex do
>> you need to concern yourself with fractional cents or fractional yen.)
>>
>> But multiplying a set of floats by 100 won't necessarily solve your
>> problem; you may have already fallen victim to the flaw of assuming
>> that the numbers are represented accurately.
> 
> Hang on a second.  I see it's always safe to work with cents, but I'm
> only confident to say that when one gives me cents to start with.  In
> other words, if one gives me integers from the start.  (Because then, of
> course, I don't even have floats to worry about.)  If I'm given 1.17,
> say, I am not confident that I could turn this number into 117 by
> multiplying it by 100.  And that was the question.  Can I always
> multiply such IEEE 754 dollar amounts by 100?
> 
> Considering your last paragraph above, I should say: if one gives me an
> accurate floating-point representation, can I assume a multiplication of
> it by 100 remains accurately representable in IEEE 754?
> 

Multiplication by 100 might not be accurate if the number you are
starting with is close to the limit of precision, because 100 is
1.1001 x 64 so multiplying by 100 adds about 5 more 'bits' to the
representation of the number. In your case, the numbers are well below
that point.

>>> --8<---cut here---start->8---
>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>> sum(map(lambda x: int(x*100), ls)) / 100
>>> 39.6
>>>
>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>> sum(map(lambda x: int(x*100), ls)) / 100
>>> 39.6
>>> --8<---cut here---end--->8---
>>>
>>> Or multiplication by 100 isn't quite ``safe'' to do with floating-point
>>> numbers either?  (It worked in this case.)
>>
>> You're multiplying and then truncating, which risks a round-down
>> error. Try adding a half onto them first:
>>
>> int(x * 100 + 0.5)
>>
>> But that's still not a perfect guarantee. Far safer would be to
>> consider monetary values to be a different type of value, not just a
>> raw number. For instance, the value $7.23 could be stored internally
>> as the integer 723, but you also know that it's a value in USD, not a
>> simple scalar. It makes perfect sense to add USD+USD, it makes perfect
>> sense to multiply USD*scalar, but it doesn't make sense to multiply
>> USD*USD.
> 
> Because of the units?  That would be USD squared?  (Nice analysis.)
> 
>>> I suppose that if I multiply it by a power of two, that would be an
>>> operation that I can be sure will not bring about any precision loss
>>> with floating-point numbers.  Do you agree?
>>
>> Assuming you're nowhere near 2**53, yes, that would be safe. But so
>> would multiplying by a power of five. The problem isn't precision loss
>> from the multiplication - the problem is that your input numbers
>> aren't what you think they are. That number 7.23, for instance, is
>> really
> 
> Hm, I think I see what you're saying.  You're saying multiplication and
> division in IEEE 754 is perfectly safe --- so long as the numbers you
> start with are accurately representable in IEEE 754 and assuming no
> overflow or underflow would occur.  (Addition and subtraction are not
> safe.)
> 

Addition and Subtraction are 

Re: on floating-point numbers

[Hope Rouselle]

Christian Gollwitzer  writes:

> Am 02.09.21 um 15:51 schrieb Hope Rouselle:
>> Just sharing a case of floating-point numbers.  Nothing needed to be
>> solved or to be figured out.  Just bringing up conversation.
>> (*) An introduction to me
>> 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}
>> is not foreign to me. (If that helps you to perhaps instruct me on
>> what's going on here.)
>> (*) A presentation of the behavior
>> 
> import sys
> sys.version
>> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
>> bit (AMD64)]'
>> 
> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
> sum(ls)
>> 39.594
>> 
> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
> sum(ls)
>> 39.61
>> All I did was to take the first number, 7.23, and move it to the
>> last
>> position in the list.  (So we have a violation of the commutativity of
>> addition.)
>
> I believe it is not commutativity, but associativity, that is
> violated. 

Shall we take this seriously?  (I will disagree, but that doesn't mean I
am not grateful for your post.  Quite the contary.)  It in general
violates associativity too, but the example above couldn't be referring
to associativity because the second sum above could not be obtained from
associativity alone.  Commutativity is required, applied to five pairs
of numbers.  How can I go from

  7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77

to 

  8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23?

Perhaps only through various application of commutativity, namely the
ones below. (I omit the parentheses for less typing.  I suppose that
does not create much trouble.  There is no use of associativity below,
except for the intented omission of parentheses.)

 7.23 + 8.41 + 6.15 + 2.31 + 7.73 + 7.77
   = 8.41 + 7.23 + 6.15 + 2.31 + 7.73 + 7.77
   = 8.41 + 6.15 + 7.23 + 2.31 + 7.73 + 7.77
   = 8.41 + 6.15 + 2.31 + 7.23 + 7.73 + 7.77
   = 8.41 + 6.15 + 2.31 + 7.73 + 7.23 + 7.77
   = 8.41 + 6.15 + 2.31 + 7.73 + 7.77 + 7.23.
   
> Even for floating point, a+b=b+a except for maybe some extreme cases
> like denormliazed numbers etc.
>
> But in general (a+b)+c != a+ (b+c)
>
> Consider decimal floating point with 2 digits.
> a=1
> b=c=0.04
>
> Then you get LHS;
>  (1 + 0.04) + 0.04 = 1 + 0.04 = 1
>
> RHS:
>
> 1 + (0.04 + 0.04) = 1 + 0.08 = 1.1
>
> Your sum is evaluated like (((a + b) + c) + ) and hence, if you
> permute the numbers, it can be unequal. If you need better accuracy, 
> there is the Kahan summation algorithm and other alternatives:
> https://en.wikipedia.org/wiki/Kahan_summation_algorithm

Thanks!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Chris Angelico  writes:

> On Fri, Sep 3, 2021 at 4:58 AM Hope Rouselle  wrote:
>>
>> Hope Rouselle  writes:
>>
>> > Just sharing a case of floating-point numbers.  Nothing needed to be
>> > solved or to be figured out.  Just bringing up conversation.
>> >
>> > (*) An introduction to me
>> >
>> > 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}
>> >
>> > is not foreign to me. (If that helps you to perhaps instruct me on
>> > what's going on here.)
>> >
>> > (*) A presentation of the behavior
>> >
>>  import sys
>>  sys.version
>> > '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
>> > bit (AMD64)]'
>> >
>>  ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>>  sum(ls)
>> > 39.594
>> >
>>  ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>>  sum(ls)
>> > 39.61
>> >
>> > All I did was to take the first number, 7.23, and move it to the last
>> > position in the list.  (So we have a violation of the commutativity of
>> > addition.)
>>
>> Suppose these numbers are prices in dollar, never going beyond cents.
>> Would it be safe to multiply each one of them by 100 and therefore work
>> with cents only?  For instance
>
> Yes and no. It absolutely *is* safe to always work with cents, but to
> do that, you have to be consistent: ALWAYS work with cents, never with
> floating point dollars.
>
> (Or whatever other unit you choose to use. Most currencies have a
> smallest-normally-used-unit, with other currency units (where present)
> being whole number multiples of that minimal unit. Only in forex do
> you need to concern yourself with fractional cents or fractional yen.)
>
> But multiplying a set of floats by 100 won't necessarily solve your
> problem; you may have already fallen victim to the flaw of assuming
> that the numbers are represented accurately.

Hang on a second.  I see it's always safe to work with cents, but I'm
only confident to say that when one gives me cents to start with.  In
other words, if one gives me integers from the start.  (Because then, of
course, I don't even have floats to worry about.)  If I'm given 1.17,
say, I am not confident that I could turn this number into 117 by
multiplying it by 100.  And that was the question.  Can I always
multiply such IEEE 754 dollar amounts by 100?

Considering your last paragraph above, I should say: if one gives me an
accurate floating-point representation, can I assume a multiplication of
it by 100 remains accurately representable in IEEE 754?

>> --8<---cut here---start->8---
>> >>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>> >>> sum(map(lambda x: int(x*100), ls)) / 100
>> 39.6
>>
>> >>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>> >>> sum(map(lambda x: int(x*100), ls)) / 100
>> 39.6
>> --8<---cut here---end--->8---
>>
>> Or multiplication by 100 isn't quite ``safe'' to do with floating-point
>> numbers either?  (It worked in this case.)
>
> You're multiplying and then truncating, which risks a round-down
> error. Try adding a half onto them first:
>
> int(x * 100 + 0.5)
>
> But that's still not a perfect guarantee. Far safer would be to
> consider monetary values to be a different type of value, not just a
> raw number. For instance, the value $7.23 could be stored internally
> as the integer 723, but you also know that it's a value in USD, not a
> simple scalar. It makes perfect sense to add USD+USD, it makes perfect
> sense to multiply USD*scalar, but it doesn't make sense to multiply
> USD*USD.

Because of the units?  That would be USD squared?  (Nice analysis.)

>> I suppose that if I multiply it by a power of two, that would be an
>> operation that I can be sure will not bring about any precision loss
>> with floating-point numbers.  Do you agree?
>
> Assuming you're nowhere near 2**53, yes, that would be safe. But so
> would multiplying by a power of five. The problem isn't precision loss
> from the multiplication - the problem is that your input numbers
> aren't what you think they are. That number 7.23, for instance, is
> really

Hm, I think I see what you're saying.  You're saying multiplication and
division in IEEE 754 is perfectly safe --- so long as the numbers you
start with are accurately representable in IEEE 754 and assuming no
overflow or underflow would occur.  (Addition and subtraction are not
safe.)

 7.23.as_integer_ratio()
> (2035064081618043, 281474976710656)
>
> ... the rational number 2035064081618043 / 281474976710656, which is
> very close to 7.23, but not exactly so. (The numerator would have to
> be ...8042.88 to be exactly correct.) There is nothing you can do at
> this point to regain the precision, although a bit of multiplication
> and rounding can cheat it and make it appear as if you did.
>
> Floating point is a very useful 

Re: on the popularity of loops while and for

[Hope Rouselle]

"Peter J. Holzer"  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.''
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Hope Rouselle]

Chris Angelico  writes:

> On Fri, Sep 3, 2021 at 4:29 AM Hope Rouselle  wrote:
>>
>> Just sharing a case of floating-point numbers.  Nothing needed to be
>> solved or to be figured out.  Just bringing up conversation.
>>
>> (*) An introduction to me
>>
>> 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}
>>
>> is not foreign to me. (If that helps you to perhaps instruct me on
>> what's going on here.)
>>
>> (*) A presentation of the behavior
>>
>> >>> import sys
>> >>> sys.version
>> '3.8.10 (tags/v3.8.10:3d8993a, May 3 2021, 11:48:03) [MSC v.1928 64
>> bit (AMD64)]'
>>
>> >>> ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
>> >>> sum(ls)
>> 39.594
>>
>> >>> ls = [8.41, 6.15, 2.31, 7.73, 7.77, 7.23]
>> >>> sum(ls)
>> 39.61
>>
>> All I did was to take the first number, 7.23, and move it to the last
>> position in the list.  (So we have a violation of the commutativity of
>> addition.)
>
> It's not about the commutativity of any particular pair of operands -
> that's always guaranteed. 

Shall we take this seriously?  It has to be about the commutativity of
at least one particular pair because it is involved with the
commutavitity of a set of pairs.  If various pairs are involved, then at
least one is involved.  IOW, it is about the commutativity of some pair
of operands and so it could not be the case that it's not about the
commutativity of any.  (Lol.  I hope that's not too insubordinate.  I
already protested against a claim for associativity in this thread and
now I'm going for the king of the hill, for whom I have always been so
grateful!)

> What you're seeing here is the results of intermediate rounding. Try
> this:

Indeed.  Your post here is really great, as usual.  It offers a nice
tool for investigation.  Thank you so much.

 def sum(stuff):
> ... total = 0
> ... for thing in stuff:
> ... total += thing
> ... print(thing, "-->", total)
> ... return total
> ...
 ls = [7.23, 8.41, 6.15, 2.31, 7.73, 7.77]
 sum(ls)
> 7.23 --> 7.23
> 8.41 --> 15.64
> 6.15 --> 21.79
> 2.31 --> 24.098

Alright.  Thanks so much for this example.  Here's a new puzzle for me.
The REPL makes me think that both 21.79 and 2.31 *are* representable
exactly in Python's floating-point datatype because I see:

>>> 2.31
2.31
>>> 21.79
21.79

When I add them, the result obtained makes me think that the sum is
*not* representable exactly in Python's floating-point number:

>>> 21.79 + 2.31
24.098

However, when I type 24.10 explicitly, the REPL makes me think that
24.10 *is* representable exactly:

>>> 24.10
24.1

I suppose I cannot trust the appearance of the representation?  What's
really going on there?  (Perhaps the trouble appears while Python is
computing the sum of the numbers 21.79 and 2.31?)  Thanks so much!
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[Greg Ewing]

On 3/09/21 8:11 pm, Christian Gollwitzer wrote:
Unless you have special numbers like NaN or signed zeros etc., a+b=b+a 
and a*b=b*a holds also for floats.


The only exception I'm aware of is for NaNs, and it's kind of pendantic:
you can't say that x + NaN == NaN + x, but only because NaNs never
compare equal. You still get a NaN either way, so for all practical
purposes it's commutative.

--
Greg
--
https://mail.python.org/mailman/listinfo/python-list

Re: on perhaps unloading modules?

[Hope Rouselle]

Dennis Lee Bieber  writes:

> On Sun, 22 Aug 2021 16:28:12 -0300, Hope Rouselle 
> 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.
>
> 
> {Hmmm, supposed to have influenced Matlab, S, and Wolfram/Mathematica}
>
>   One of the quirks is that one reads APL from right to left... cf:
> 
>
>   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.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Alan Gauld via Python-list]

On 03/09/2021 18:37, Chris Angelico wrote:

 Without DST the schools opened in the dark so all the kids
 had to travel to school in the dark and the number of
 traffic accidents while crossing roads jumped.
> 
> Are you saying that you had DST in winter, or that, when summer *and*
> DST came into effect, there was more light at dawn? Because a *lot* of
> people confuse summer and DST, and credit DST with the natural effects
> of the season change.

OK, I see the confusion. What I should point out was that the
experiment involved us staying on DST and not reverting to UTC
in the winter - that unified us with most of the EU apparently...

So although I'm saying DST it was really the non-reversion from
DST to UTC that caused problems. Arguably, if we just stayed on
UTC and didn't have DST at all there would be no issue - except
we'd be an hour out of sync with the EU. (Post Brexit that may
not be seen as a problem!! :-)

-- 
Alan G
Author of the Learn to Program web site
http://www.alan-g.me.uk/
http://www.amazon.com/author/alan_gauld
Follow my photo-blog on Flickr at:
http://www.flickr.com/photos/alangauldphotos


-- 
https://mail.python.org/mailman/listinfo/python-list

CPython / Decimal and bit length of value.

[Nacnud Nac via Python-list]

Hi,
Is there a quick way to get the number of bits required to store the value in a 
Decimal class? 
What obvious thing am I missing? I'm working with really large integers, say, 
in the order of 5_000_000 of ASCII base 10 digits. 
It seems the function mpd_sizeinbase would be a nice thing to be able to 
call.
It'd be nice to just be able to tell the "size of data", or something like 
that, that was stored in the *data? I note there is len "field" in the 
structure mpd_t
Sorry for the dumb question
Thanks,Duncan

-- 
https://mail.python.org/mailman/listinfo/python-list

Re: on floating-point numbers

[jak]

Il 03/09/2021 14:45, Chris Angelico ha scritto:

I believe the definition of "accurate" here is that, if you take all
of the real numbers represented by those floats, add them all together
with mathematical accuracy, and then take the nearest representable
float, that will be the exact value that fsum will return. In other
words, its accuracy is exactly as good as the final result can be.


yup, I agree and this is the because of the link.
--
https://mail.python.org/mailman/listinfo/python-list

How to include insertion order in dict equality

[Terry Reedy]

In https://bugs.python.org/issue45093, Michael Rans suggested adding a 
dict method that would include the insertion order in comparing dicts 
for equality. He wanted this for testing.  The proposal is rejected 
because there are already multiple good methods.  To make them more 
visible and searchable, I list them here.


Steven D'Aprano:
d1 == d2 and all(k1 == k2 for k1, k2 in zip(d1, d2))

Sethiy Storchaka:
list(d1.items()) == list(d2.items())
# When using unittest, produces nicer report on failure.

Raymond Hettinger:
assert OrderedDict(d) == OrderedDict(e)

--
Terry Jan Reedy

--
https://mail.python.org/mailman/listinfo/python-list

Re: on writing a while loop for rolling two dice

[Michael F. Stemper]

On 04/09/2021 08.53, Hope Rouselle wrote:

Chris Angelico  writes:



And at this point, it's looking pretty much identical to the for loop
version. Ultimately, they're all the same and you can pick and choose
elements from each of them.


I see.  That's why C must have added the do-while, but yeah --- it's not
really worth it.


Kernighan and Ritchie agree(d) with you. Per _The C Programming
Language__:
  Experience shows that do-while is much less used that while
  and for.

(Second edition, Section 3.6, page 63)

--
Michael F. Stemper
Outside of a dog, a book is man's best friend.
Inside of a dog, it's too dark to read.
--
https://mail.python.org/mailman/listinfo/python-list

[issue34722] Non-deterministic bytecode generation

[Chih-Hsuan Yen]

Chih-Hsuan Yen  added the comment:

issue37596 merged a fix to enable deterministic frozensets. I think this issue 
can be closed?

Regarding my last comment msg347820 - it seems similar to one of 
https://bugs.python.org/issue34033 or https://bugs.python.org/issue34093. I 
followed those tickets instead.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue34093] Reproducible pyc: FLAG_REF is not stable.

[Chih-Hsuan Yen]

Change by Chih-Hsuan Yen :


--
nosy: +yan12125

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24612] not operator expression raising a syntax error

[Andre Roberge]

Change by Andre Roberge :


--
nosy: +aroberge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[Python-announce] [RELEASE] Python 3.7.12 and 3.6.15 security updates now available

[Ned Deily]

Python 3.7.12 and 3.6.15, the lastest security fix rollups for Python 3.7 and 
Python 3.6, are now available. You can find the release files, links to the 
changelogs, and more information here:

   https://www.python.org/downloads/release/python-3712/
   https://www.python.org/downloads/release/python-3615/

These releases are source code only; Windows and macOS binary installers are 
not provided for security fix releases.

Note that Python 3.9 is now the latest feature release series of Python 3. You 
should consider upgrading to 3.9 as soon as practical. Get the latest release 
of 3.9.x here:

   https://www.python.org/downloads/

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

   https://www.python.org/psf-landing/

--
  Ned Deily
  n...@python.org -- []



signature.asc
Description: Message signed with OpenPGP
___
Python-announce-list mailing list -- python-announce-list@python.org
To unsubscribe send an email to python-announce-list-le...@python.org
https://mail.python.org/mailman3/lists/python-announce-list.python.org/
Member address: arch...@mail-archive.com

[issue45104] Error in __new__ docs

[Kevin Shweh]

New submission from Kevin Shweh :

The data model docs for __new__ say "If __new__() is invoked during object 
construction and it returns an instance or subclass of cls, then the new 
instance’s __init__() method will be invoked..."

"instance or subclass of cls" is incorrect - if for some reason __new__ returns 
a subclass of cls, __init__ will not be invoked, unless the subclass also 
happens to be an instance of cls (which can happen with metaclasses).

This should probably say something like "instance of cls (including subclass 
instances)", or "instance of cls or of a subclass of cls", or just "instance of 
cls".

--
assignee: docs@python
components: Documentation
messages: 401065
nosy: Kevin Shweh, docs@python
priority: normal
severity: normal
status: open
title: Error in __new__ docs
versions: Python 3.10, Python 3.11, Python 3.8, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[RELEASE] Python 3.7.12 and 3.6.15 security updates now available

[Ned Deily]

Python 3.7.12 and 3.6.15, the lastest security fix rollups for Python 3.7 and 
Python 3.6, are now available. You can find the release files, links to the 
changelogs, and more information here:

   https://www.python.org/downloads/release/python-3712/
   https://www.python.org/downloads/release/python-3615/

These releases are source code only; Windows and macOS binary installers are 
not provided for security fix releases.

Note that Python 3.9 is now the latest feature release series of Python 3. You 
should consider upgrading to 3.9 as soon as practical. Get the latest release 
of 3.9.x here:

   https://www.python.org/downloads/

Thanks to all of the many volunteers who help make Python Development and these 
releases possible! Please consider supporting our efforts by volunteering 
yourself or through organization contributions to the Python Software 
Foundation.

   https://www.python.org/psf-landing/

--
  Ned Deily
  n...@python.org -- []



signature.asc
Description: Message signed with OpenPGP
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue24893] Tk occasionally mispositions Text() insert cursor on mouse click.

[Terry J. Reedy]

Terry J. Reedy  added the comment:

https://stackoverflow.com/questions/69038343/mouse-pointer-misaligned-when-using-python-in-idle-on-mac
 reports same issue with 3.9.5.  I have requested details to be posted here.

--
status: pending -> open

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24612] not operator expression raising a syntax error

[Pablo Galindo Salgado]

Change by Pablo Galindo Salgado :


--
keywords: +patch
pull_requests: +26599
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28170

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24612] not operator expression raising a syntax error

[Pablo Galindo Salgado]

Pablo Galindo Salgado  added the comment:

I think the best outcome here is to refine the syntax error. Making it behave a 
bit better is going to be quite a pain because of how unary "-" and "not" work 
on the priority level in the grammar.

I also don't think that facilitating the concatenation of operators without 
parentheses is a good idea (for readability reasons). 

I will prepare a PR to improve the syntax error

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45103] IDLE: make configdialog font page survive font failures

[Terry J. Reedy]

New submission from Terry J. Reedy :

There were reports on a previous issue that attempting to display some 
characters from some linux fonts in some distributions resulted in crashing 
Python.  The crash reports mentioned XWindows errors about particular 
characters being too complex or something.  I did not open an issue for this 
because it seemed beyond the ability of tkinter/IDLE to predict and handle.

https://stackoverflow.com/questions/68996159/idle-settings-window-wont-appear 
reported that requesting the IDLE settings window resulting in IDLE hanging.  
The user used my print debug suggestion to determine that the problem was in 
configdialog.py at
self.fontpage = FontPage(note, self.highpage)

The user first thought the issue was with a chess font, and then determined 
that the problem font was the phaistos font from 
https://ctan.org/pkg/phaistos?lang=en.  The font has the symbols from the 
Cretan Linear A script on the Disk of Phaistos. This issue is about

1. Try to reproduce the issue by downloading and installing Phaistos.otf (right 
click on the file and click Install).

2. If successful, trace the problem to a specific line within the FontPage 
class.

3. Determine whether Python code can prevent the hang or if it is completely in 
other code.  (Either way, perhaps report to tcl/tk.)

... To remove, "open Control Panel -> Fonts then locate and select Phaistos 
Regular font then proceed with clicking Delete button."

I did not select 'test needed' because we cannot routinely install new fonts 
and I am not sure of how to do an automated test if we could.
However, I would add a note as to how to do a manual test.

font.otf = OpenTypeFont, used on Windows, Linux, macOS.
https://fileinfo.com/extension/otf
It might be good test on other systems after Windows.

--
messages: 401062
nosy: terry.reedy
priority: normal
severity: normal
stage: needs patch
status: open
title: IDLE: make configdialog font page survive font failures
type: behavior
versions: Python 3.11

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45042] Many multiprocessing tests are silently skipped since 3.9

[miss-islington]

miss-islington  added the comment:


New changeset e5976dd2e6e966183da59df99978ebcb4b3a32df by Miss Islington (bot) 
in branch '3.10':
bpo-45042: Now test classes decorated with `requires_hashdigest` are not 
skipped (GH-28060)
https://github.com/python/cpython/commit/e5976dd2e6e966183da59df99978ebcb4b3a32df


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45042] Many multiprocessing tests are silently skipped since 3.9

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +26598
pull_request: https://github.com/python/cpython/pull/28169

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Peter J. Holzer]

On 2021-09-04 21:48:14 +0200, Peter J. Holzer wrote:
> On 2021-09-02 08:32:36 +0100, Alan Gauld via Python-list wrote:
> > On 31/08/2021 22:32, Chris Angelico wrote:
> > > If we could abolish DST world-wide, life would be far easier. All the
> > > rest of it would be easy enough to handle.
> > We tried that in the UK for 2 years back in the '70s and very
> > quickly reverted to DST when they realized that the number
> > of fatalities among young children going to school doubled
> > during those two years.
> 
> That makes no sense. With DST the clocks are changed in summer, and they
> are set forward, so it's darker at the same time in the morning.
> 
> Maybe you are talking about switching to DST for the whole year or just
> moving to CET? That would have the effect of it being noticably darker
> in the morning in winter.

Found it. Between 1968-02-18 and 1971-10-30 was continuously on
UTC+0100 (probably to be in the same timezone as Germany and France
(which didn't have DST at that time).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45042] Many multiprocessing tests are silently skipped since 3.9

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset dd7b816ac87e468e2fa65ce83c2a03fe1da8503e by Nikita Sobolev in 
branch 'main':
bpo-45042: Now test classes decorated with `requires_hashdigest` are not 
skipped (GH-28060)
https://github.com/python/cpython/commit/dd7b816ac87e468e2fa65ce83c2a03fe1da8503e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem with python

[Peter J. Holzer]

On 2021-09-04 21:07:11 +0100, Rob Cliffe via Python-list wrote:
> Well, up to a point.
> In Python 2 the output from
>     print 1, 2
> is '1 2'
> In Python 3 if you add brackets:
>     print(1, 2)
> the output is the same.
> But if you transplant that syntax back into Python 2, the output from
>     print(1, 2)
> is '(1, 2)'.  The brackets have turned two separate items into a single
> tuple.

Yes. I was just talking about that specific case with a single function
call. I do not consider explaining the differences between Python 2 and
Python 3 to be time well spent in 2021, especially not to someone who
apparently just wants to report a bug to some unnamed project (whose
maintainers may or may not care about Python2 compatibility).

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45042] Many multiprocessing tests are silently skipped since 3.9

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +26597
pull_request: https://github.com/python/cpython/pull/28168

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[miss-islington]

miss-islington  added the comment:


New changeset fecd17fbcb68138c6535130dfca2173472d669cd by Miss Islington (bot) 
in branch '3.9':
bpo-45030: Fix integer overflow in __reduce__ of the range iterator (GH-28000)
https://github.com/python/cpython/commit/fecd17fbcb68138c6535130dfca2173472d669cd


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[miss-islington]

miss-islington  added the comment:


New changeset ed9f927527e100b6d1d5758fdd9fc20b313af226 by Miss Islington (bot) 
in branch '3.10':
bpo-45030: Fix integer overflow in __reduce__ of the range iterator (GH-28000)
https://github.com/python/cpython/commit/ed9f927527e100b6d1d5758fdd9fc20b313af226


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
resolution:  -> fixed
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 2ad114ddffbeeef1d20f26571b85a66974295667 by Miss Islington (bot) 
in branch '3.10':
[3.10] bpo-45097: Add more tests for shutdown_asyncgens() (GH-28154) (GH-28159)
https://github.com/python/cpython/commit/2ad114ddffbeeef1d20f26571b85a66974295667


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Trouble propagating logging configuration

[Peter J. Holzer]

On 2021-09-02 09:06:53 +0200, Loris Bennett wrote:
> 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.

That normally shouldn't make any difference, since any functions in
mylibs.mylib would be called only after the logger is initialized.

Does your mylibs.mylib contain code which is run on import (other than
class, function and variable definitions)?

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue44571] itertools: takedowhile()

[Raymond Hettinger]

Change by Raymond Hettinger :


--
keywords: +patch
pull_requests: +26596
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28167

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem with python

[Rob Cliffe via Python-list]

Well, up to a point.
In Python 2 the output from
    print 1, 2
is '1 2'
In Python 3 if you add brackets:
    print(1, 2)
the output is the same.
But if you transplant that syntax back into Python 2, the output from
    print(1, 2)
is '(1, 2)'.  The brackets have turned two separate items into a single 
tuple.
If you want Python 2- and 3-compatibility you must find a work-around 
such as

    print('%d %d' % (1,2))
    print('%s %s' % (1,2))
    print(str(1) + ' ' + str(2))

Similarly
    'print' in Python 2 outputs a blank line.
    'print()' in Python 3 outputs a blank line.  In python 2 it prints 
a line containing a blank tuple: '()'.

A 2/3-compatible way of outputting a blank line is
    print('')

Best wishes
Rob Cliffe




On 04/09/2021 20:50, Peter J. Holzer wrote:

On 2021-09-04 14:29:47 -0500, Igor Korot wrote:

Will this syntax work in python 2?

Yes. It's just a redundant pair of parentheses.

 hp




--
https://mail.python.org/mailman/listinfo/python-list

[issue45102] unittest: add tests for skipping and errors in cleanup

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
keywords: +patch
pull_requests: +26595
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28166

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45102] unittest: add tests for skipping and errors in cleanup

[Serhiy Storchaka]

New submission from Serhiy Storchaka :

The proposed PR adds tests for skipping and errors in cleanup: after success, 
after failure, and in combination with the expectedFailure decorator.

--
components: Library (Lib)
messages: 401056
nosy: ezio.melotti, michael.foord, rbcollins, serhiy.storchaka
priority: normal
severity: normal
status: open
title: unittest: add tests for skipping and errors in cleanup
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Re: Problem with python

[Peter J. Holzer]

On 2021-09-04 14:29:47 -0500, Igor Korot wrote:
> Will this syntax work in python 2?

Yes. It's just a redundant pair of parentheses.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: The sqlite3 timestamp conversion between unixepoch and localtime can't be done according to the timezone setting on the machine automatically.

[Peter J. Holzer]

On 2021-09-02 08:32:36 +0100, Alan Gauld via Python-list wrote:
> On 31/08/2021 22:32, Chris Angelico wrote:
> > If we could abolish DST world-wide, life would be far easier. All the
> > rest of it would be easy enough to handle.
> We tried that in the UK for 2 years back in the '70s and very
> quickly reverted to DST when they realized that the number
> of fatalities among young children going to school doubled
> during those two years.

That makes no sense. With DST the clocks are changed in summer, and they
are set forward, so it's darker at the same time in the morning.

Maybe you are talking about switching to DST for the whole year or just
moving to CET? That would have the effect of it being noticably darker
in the morning in winter.

hp

-- 
   _  | Peter J. Holzer| Story must make more sense than reality.
|_|_) ||
| |   | h...@hjp.at |-- Charles Stross, "Creative writing
__/   | http://www.hjp.at/ |   challenge!"


signature.asc
Description: PGP signature
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Igor Korot]

Hi,
Will this syntax work in python 2?

Thank you.

On Sat, Sep 4, 2021 at 1:52 PM dn via Python-list
 wrote:
>
> On 05/09/2021 06.27, Igor Korot wrote:
> > Hi, ALL,
> >
> > [code]
> > igor@WaylandGnome ~/bakefile $ python
> > Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> > [GCC 10.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
>  from distutils import sysconfig
>  print sysconfig.get_python_inc()
> >   File "", line 1
> > print sysconfig.get_python_inc()
> >   ^
> > SyntaxError: invalid syntax
> 
> > [/code]
> >
> > What is the proper way to fix this?
>
> Remember that in Python3 print became a function:
>
>  print( sysconfig.get_python_inc() )
>
> --
> Regards,
> =dn
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Igor Korot]

Thx guys.
I submitted a bug report for the project that uses it.

On Sat, Sep 4, 2021 at 1:42 PM Joel Goldstick  wrote:
>
> On Sat, Sep 4, 2021 at 2:29 PM Igor Korot  wrote:
> >
> > Hi, ALL,
> >
> > [code]
> > igor@WaylandGnome ~/bakefile $ python
> > Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> > [GCC 10.3.0] on linux
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> from distutils import sysconfig
> > >>> print sysconfig.get_python_inc()
> >   File "", line 1
> > print sysconfig.get_python_inc()
>
>  print( sysconfig.get_python_inc())
>
> Since python3 print is a function.
> >   ^
> > SyntaxError: invalid syntax
> > >>>
> > [/code]
> >
> > What is the proper way to fix this?
> >
> > Thank you.
> > --
> > https://mail.python.org/mailman/listinfo/python-list
>
>
>
> --
> Joel Goldstick
> --
> https://mail.python.org/mailman/listinfo/python-list
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[dn via Python-list]

On 05/09/2021 06.27, Igor Korot wrote:
> Hi, ALL,
> 
> [code]
> igor@WaylandGnome ~/bakefile $ python
> Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> [GCC 10.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
 from distutils import sysconfig
 print sysconfig.get_python_inc()
>   File "", line 1
> print sysconfig.get_python_inc()
>   ^
> SyntaxError: invalid syntax

> [/code]
> 
> What is the proper way to fix this?

Remember that in Python3 print became a function:

 print( sysconfig.get_python_inc() )

-- 
Regards,
=dn
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Mats Wichmann]

On 9/4/21 12:27 PM, Igor Korot wrote:

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.

from distutils import sysconfig
print sysconfig.get_python_inc()

   File "", line 1
 print sysconfig.get_python_inc()
   ^
SyntaxError: invalid syntax



[/code]

What is the proper way to fix this?


print is a function in Python 3.

print(sysconfig.get_python_inc())

Try:

>>> help(print)

for a quick check.

--
https://mail.python.org/mailman/listinfo/python-list

Re: Problem with python

[Joel Goldstick]

On Sat, Sep 4, 2021 at 2:29 PM Igor Korot  wrote:
>
> Hi, ALL,
>
> [code]
> igor@WaylandGnome ~/bakefile $ python
> Python 3.9.6 (default, Aug  8 2021, 17:26:32)
> [GCC 10.3.0] on linux
> Type "help", "copyright", "credits" or "license" for more information.
> >>> from distutils import sysconfig
> >>> print sysconfig.get_python_inc()
>   File "", line 1
> print sysconfig.get_python_inc()

 print( sysconfig.get_python_inc())

Since python3 print is a function.
>   ^
> SyntaxError: invalid syntax
> >>>
> [/code]
>
> What is the proper way to fix this?
>
> Thank you.
> --
> https://mail.python.org/mailman/listinfo/python-list



-- 
Joel Goldstick
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45101] Small inconsistency in usage message between the python and shell script versions of python-config

[Kien Dang]

Change by Kien Dang :


--
keywords: +patch
pull_requests: +26594
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/28162

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue24612] not operator expression raising a syntax error

[Irit Katriel]

Irit Katriel  added the comment:

Reproduced on 3.11:

>>> 0 + not 0
  File "", line 1
0 + not 0
^^^
SyntaxError: invalid syntax
>>> - not 0
  File "", line 1
- not 0
  ^^^
SyntaxError: invalid syntax

--
nosy: +iritkatriel, pablogsal
versions: +Python 3.11 -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45101] Small inconsistency in usage message between the python and shell script versions of python-config

[Kien Dang]

New submission from Kien Dang :

`python-config` outputs a usage instruction message in case either the `--help` 
option or invalid arguments are provided.

However there is a small different in the output I/O between the python and 
shell script versions of `python-config`. In the python version, the message 
always prints to `stderr`.

https://github.com/python/cpython/blob/bc1c49fa94b2abf70e6937373bf1e6b5378035c5/Misc/python-config.in#L15-L18

def exit_with_usage(code=1):
print("Usage: {0} [{1}]".format(
sys.argv[0], '|'.join('--'+opt for opt in valid_opts)), file=sys.stderr)
sys.exit(code)

while in the shell script version it always prints to `stdout`.

https://github.com/python/cpython/blob/bc1c49fa94b2abf70e6937373bf1e6b5378035c5/Misc/python-config.sh.in#L5-L9

exit_with_usage ()
{
echo "Usage: $0 
--prefix|--exec-prefix|--includes|--libs|--cflags|--ldflags|--extension-suffix|--help|--abiflags|--configdir|--embed"
exit $1
}

This inconsistency does not affect most users of `python-config`, who runs the 
script interactively. However it might cause issues when run programmatically.

--
components: Demos and Tools
messages: 401054
nosy: kiendang
priority: normal
severity: normal
status: open
title: Small inconsistency in usage message between the python and shell script 
versions of python-config
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue16731] [doc] xxlimited/xxmodule docstrings ambiguous

[Irit Katriel]

Change by Irit Katriel :


--
title: xxlimited/xxmodule docstrings ambiguous -> [doc] xxlimited/xxmodule 
docstrings ambiguous
versions: +Python 3.11 -Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Problem with python

[Igor Korot]

Hi, ALL,

[code]
igor@WaylandGnome ~/bakefile $ python
Python 3.9.6 (default, Aug  8 2021, 17:26:32)
[GCC 10.3.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from distutils import sysconfig
>>> print sysconfig.get_python_inc()
  File "", line 1
print sysconfig.get_python_inc()
  ^
SyntaxError: invalid syntax
>>>
[/code]

What is the proper way to fix this?

Thank you.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue45034] Improve struct.pack out of range error messages

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Go ahead, with the understanding that there is no guaranteed acceptance of the 
change, even with a good patch.  There may be reasons for the status quo that 
neither Steven nor I are aware of.  I don't think that either of the listed 
experts, added as nosy, are very active.  In any case,  revised or new tests 
will be needed.

--
nosy: +mark.dickinson, meador.inge

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45100] Teach help about typing.overload()

[Raymond Hettinger]

New submission from Raymond Hettinger :

Python's help() function does not display overloaded function signatures.

For example, this code:

from typing import Union

class Smudge(str):

@overload
def __getitem__(self, index: int) -> str:
...

@overload
def __getitem__(self, index: slice) -> 'Smudge':
...

def __getitem__(self, index: Union[int, slice]) -> Union[str, 'Smudge']:
'Return a smudged character or characters.' 
if isinstance(index, slice):
start, stop, step = index.indices(len(self))
values = [self[i] for i in range(start, stop, step)]
return Smudge(''.join(values))
c = super().__getitem__(index)
return chr(ord(c) ^ 1)


Currently gives this help:

__getitem__(self, index: Union[int, slice]) -> Union[str, 
ForwardRef('Smudge')]
Return a smudged character or characters.


What is desired is:

__getitem__(self, index: int) -> str
__getitem__(self, index: slice) -> ForwardRef('Smudge')
Return a smudged character or characters.

The overload() decorator is sufficient for informing a static type checker but 
insufficient for informing a user or editing tool.

--
messages: 401052
nosy: rhettinger
priority: normal
severity: normal
status: open
title: Teach help about typing.overload()

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[miss-islington]

Change by miss-islington :


--
pull_requests: +26593
pull_request: https://github.com/python/cpython/pull/28161

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 2.0 -> 3.0
pull_requests: +26592
pull_request: https://github.com/python/cpython/pull/28160

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45030] Integer overflow in __reduce__ of the range iterator

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset 936f6a16b9ef85bd56b18a247b962801e954c30e by Serhiy Storchaka in 
branch 'main':
bpo-45030: Fix integer overflow in __reduce__ of the range iterator (GH-28000)
https://github.com/python/cpython/commit/936f6a16b9ef85bd56b18a247b962801e954c30e


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset c2970fdec52788b6d9ff419ab7e31f255d87433d by Serhiy Storchaka in 
branch 'main':
bpo-45097: Add more tests for shutdown_asyncgens() (GH-28154)
https://github.com/python/cpython/commit/c2970fdec52788b6d9ff419ab7e31f255d87433d


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[miss-islington]

Change by miss-islington :


--
nosy: +miss-islington
nosy_count: 5.0 -> 6.0
pull_requests: +26591
pull_request: https://github.com/python/cpython/pull/28159

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:


New changeset c967bd523caabb05bf5988449487d7c1717f3ac6 by Serhiy Storchaka in 
branch '3.9':
[3.9] bpo-45097: Remove incorrect deprecation warnings in asyncio. (GH-28153)
https://github.com/python/cpython/commit/c967bd523caabb05bf5988449487d7c1717f3ac6


--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45086] f-string unmatched ']'

[Greg Kuhn]

Greg Kuhn  added the comment:

I see, thank you all for the detailed investigation and explanation!!

Agreed Terry, anyone who reads the error should be able to parse it themselves 
and see what the errors is. Pointing the user to the error site is the most 
important piece.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

[jack1142]

New submission from jack1142 :

The documentation here:
https://docs.python.org/3.10/library/asyncio-task.html#asyncio.Task

Says that `loop` parameter was removed but it's still part of the signature. It 
gets even more confusing when the deprecation right below it is saying that 
*not* passing it when there is no running event loop is deprecated :)

I could make a PR removing this information but I'm not sure whether there 
should be also some information put about it being deprecated in 3.8 but not 
actually getting removed in 3.10?

--
assignee: docs@python
components: Documentation
messages: 401047
nosy: docs@python, jack1142
priority: normal
severity: normal
status: open
title: asyncio.Task's documentation says that loop arg is removed when it's not
type: behavior
versions: Python 3.10

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45099] asyncio.Task's documentation says that loop arg is removed when it's not

[jack1142]

Change by jack1142 :


--
components: +asyncio
nosy: +asvetlov, yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45086] f-string unmatched ']'

[Terry J. Reedy]

Terry J. Reedy  added the comment:

Thank you Eric.  I can see now that the actual process is a somewhat 
complicated mix of the simple options 1 and 2 I imagined above.  It is like 
option 2, except that everything between '{' and '}' is partially parsed enough 
to create a format object.  This is required to ignore quoted braces

>>> f'{"}"'
SyntaxError: f-string: expecting '}'

and detect valid '!' and ':' markers.  In that partial parsing, unmatched 
fences are detected and reported, while other syntax errors are not.  If my 
option 1 above were true, the first example below would instead report the 'a 
a' error.

>>> f'{a a'
SyntaxError: f-string: expecting '}'
>>> f'{a a]'
SyntaxError: f-string: unmatched ']'
>>> f'{a a}'
SyntaxError: f-string: invalid syntax. Perhaps you forgot a comma?

The second plausibly could, but outside of the f-string context, the error is 
the same.
>>> a a]
SyntaxError: unmatched ']'
 
Greg, the fuller answer to your question is that the interpreter is only 
*required* to report that there is an error and some indication of where.  
"SyntaxError: invalid syntax" is the default.  It may have once been all that 
was ever reported.

A lot of recent effort has gone into adding detail into what is wrong and what 
the fix might be.  But both additions sometimes involve choices that may not 
meet a particular person's expectation.  Another person, expecting linear 
rather than nested parsing, might look at the first example above and ask 
whether the interpreter should be complaining about the 'a a' syntax error 
instead of the following lack of '}' f-string error.  And I would not call it a 
bug if it were to do so in the future.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue37596] Reproducible pyc: frozenset is not serialized in a deterministic order

[Brandt Bucher]

Change by Brandt Bucher :


--
stage: patch review -> resolved
status: open -> closed

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Change by Serhiy Storchaka :


--
pull_requests: +26590
pull_request: https://github.com/python/cpython/pull/28154

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45098] asyncio.CancelledError should contain more information on cancellations

[Sam Bull]

New submission from Sam Bull :

There are awkward edge cases caused by race conditions when cancelling tasks 
which make it impossible to reliably cancel a task.

For example, in the async-timeout library there appears to be no way to avoid 
suppressing an explicit t.cancel() if that cancellation occurs immediately 
after the timeout.

In the alternative case where a cancellation happens immediately before the 
timeout, the solutions feel dependant on the internal details of how 
asynico.Task works and could easily break if the behaviour is tweaked in some 
way.

What we really need to know is how many times a task was cancelled as a cause 
of the CancelledError and ideally were the cancellations caused by us.

The solution I'd like to propose is that the args on the exception contain all 
the messages of every cancel() call leading up to that exception, rather than 
just the first one.

e.g. In these race conditions e.args would look like (None, SENTINEL), where 
SENTINEL was sent in our own cancellations. From this we can see that the task 
was cancelled twice and only one was caused by us, therefore we don't want to 
suppress the CancelledError.

For more details to fully understand the problem:
https://github.com/aio-libs/async-timeout/pull/230
https://github.com/aio-libs/async-timeout/issues/229#issuecomment-908502523
https://github.com/aio-libs/async-timeout/pull/237

--
components: asyncio
messages: 401045
nosy: asvetlov, dreamsorcerer, yselivanov
priority: normal
severity: normal
status: open
title: asyncio.CancelledError should contain more information on cancellations
type: behavior
versions: Python 3.10, Python 3.11, Python 3.9

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue45097] "The loop argument is deprecated" reported when user code does not use it

[Serhiy Storchaka]

Serhiy Storchaka  added the comment:

There are several calls of gather() and sleep() with the loop argument from the 
asyncio library. Since all deprecation warnings were silenced in tests it was 
unnoticed.

PR 28153 fixes the asyncio library, enables deprecation warnings in tests, 
fixes tests producing warnings and add several new tests for uncovered code. 
New tests will be ported to master later.

--
nosy: +lukasz.langa
priority: normal -> release blocker

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com