Re: Convert the decimal numbers expressed in a `numpy.ndarray` into a matrix representing elements in fractional form

[Cousin Stanley]

> hongy... wrote 
>
> This method doesn't work, as shown below:
>
? b 
>
>  [0.0, -1.0, 0.0, 0.25]
>  [1.0, 0.0, 0.0, 0.25]
>  [0.0, 0.0, 1.0, 0.25]
>  [0.0, 0.0, 0.0, 1.0]
>
> a 
>
> 0  0  0  1
>

# ---

Using 

  debian 11.3 bullseye
  python 3.9
  numpy  1,21,5

  Code as I posted in my reply dated 2022-05-18


$ python3 np_array_to_fractions_2.py

  b 

 [0.0, -1.0, 0.0, 0.25]
 [1.0, 0.0, 0.0, 0.25]
 [0.0, 0.0, 1.0, 0.25]
 [0.0, 0.0, 0.0, 1.0]

  a 

0 -1 0 1/4
1 0 0 1/4
0 0     1     1/4
0 0 0 1


--
Stanley C. Kitching
Human Being
Phoenix, Arizona
--
https://mail.python.org/mailman/listinfo/python-list

Re: Convert the decimal numbers expressed in a `numpy.ndarray` into a matrix representing elements in fractional form

[Cousin Stanley]

#!/usr/bin/env python3

'''
NewsGroup  comp.lang.python

Subject .. Convert the decimal numbers
   expressed in a numpy.ndarray
   into a matrix representing elements
   in fractiona

Date . 2022-05-16

Post_By .. hongy...

Edit_By .. Stanley C. Kitching
'''

import numpy as np

from fractions import Fraction

b = [
  [ 0.0 , -1.0 , 0.0 , 0.25 ] ,
  [ 1.0 ,  0.0 , 0.0 , 0.25 ] ,
  [ 0.0 ,  0.0 , 1.0 , 0.25 ] ,
  [ 0.0 ,  0.0 , 0.0 , 1.0  ] ]

a = [ ]

print( '\n  b  \n' )

for row in b :
arow = []
print( '' , row )

for dec_x in row :
frac_x = Fraction( dec_x )
arow.append( frac_x )

a.append( arow )


# using f-string format

print( '\n  a  \n' )

for row in a :

for item in row :

print( f'{item} ' , end = '' )

print()

# --

--
Stanley C. Kitching
Human Being
Phoenix, Arizona
--
https://mail.python.org/mailman/listinfo/python-list

[issue30718] [doc] open builtin function: specifying the size of buffer has no effect for text files

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30403
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/32351

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

[issue46168] Incorrect format specified for the "style" key in the configuration file format formatter example

[Stanley]

Stanley  added the comment:

Samriddhi, are you still working on this?

--
nosy: +slateny

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

[issue44158] Clarify documentation for redirected stdout/stderr when using subprocess in Linux

[Stanley]

Stanley  added the comment:

Hmm, I'm not quite following - when you say that the subproccess-ed command 
should also inherit the redirection, which subprocess command are you referring 
to, and nested or unnested? I gave it a ran and everything seems to run how I'd 
expected it, so maybe put another way, what's the expected output from the 
files and stdout/stderr?

--
nosy: +slateny

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

[issue47207] Switch datetime docstrings / documentation to using "Returns" rather than "Return"?

[Stanley]

Stanley  added the comment:

Is there a bpo page or some sort that discusses why the imperative mood is used 
over the indicative mood other than convention of PEP 257? I found this 
(https://mail.python.org/pipermail/tutor/2012-May/089584.html) question and 
answer that seems to make sense, but it's not quite an official source.

If the reason for using imperative mood in docstrings doesn't apply to 
documentation, then I think there wouldn't be any problems in changing it. One 
thing raised in the mail thread was that 'Returns ...' isn't strictly 
grammatical, so perhaps that's something to consider.

--

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

[issue32658] Metacharacter (\) documentation suggestion

[Stanley]

Stanley  added the comment:

Feel free, it's all yours

--

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

[issue32658] Metacharacter (\) documentation suggestion

[Stanley]

Stanley  added the comment:

Mike, are you still working on this issue?

--
nosy: +slateny

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

[issue39971] [doc] Error in functional how-to example

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30250
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/32172

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

[issue37430] [doc] range is not a built-in function

[Stanley]

Stanley  added the comment:

Terry, how do you think the example/paragraph should be improved? I notice that 
the previous paragraphs talk about continue/break/else, so were you looking for 
some new example with all those? And I think the indexing's been fixed by now, 
but a clickable link to the range() documentation 
(https://docs.python.org/3/library/stdtypes.html#range) might still be a good 
idea just for convenience.

--
nosy: +slateny

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

[issue47031] math.nan should note that NANs do not compare equal to anything

[Stanley]

Stanley  added the comment:

Then perhaps saying that it's *never* equal is too strong, and instead we just 
say it's *not* equal. Not too sure how to phrase the behavior difference 
between `==` and `is` though, if that's something that should be noted.

--

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

[issue47031] math.nan should note that NANs do not compare equal to anything

[Stanley]

Stanley  added the comment:

Vedran's got a good point, as existing documentation for math.nan already says

"... Equivalent to the output of float('nan')."

so it does seem a bit redundant to say both, though I wonder if we should still 
be explicit since

>>> import math
>>> math.nan is math.nan
True
>>> float('nan') is float('nan')
False

so they don't have the exact same behavior.

Serhiy also has a good point, so maybe instead say that Math.nan/float('nan') 
is *generally* not equal to any other value?

--

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

[issue33028] [doc] tempfile.TemporaryDirectory documentation improvements

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +30104
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/32016

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

[issue47031] math.nan should note that NANs do not compare equal to anything

[Stanley]

Stanley  added the comment:

How does this sound instead? The unequalness is pushed to the front and the 
IEEE part back so it's less likely missed:

Math.nan and float('nan') are never equal to any other value, including 
themselves, as per IEEE 754. Use math.isnan to test for NANs.

--
nosy: +slateny

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

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

[Cousin Stanley]

Cousin Stanley wrote:

>> apt-cache search lxqt | grep ^lxqt


Chris Angelico wrote:

> Much faster:
> 
> apt-cache pkgnames lxqt
> 
> apt-cache search will look for "lxqt" in descriptions too, 
> hence the need to filter those out 
> 
>   apt-cache pkgnames is used by tab completion)
> 

  Thanks 

I didn't know about using  pkgnames  with apt-cache.

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue9182] document “--” as a way to distinguish option w/ narg='+' from positional argument in argparse

[Stanley]

Change by Stanley :


--
nosy: +slateny
nosy_count: 13.0 -> 14.0
pull_requests: +29908
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31810

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

Re: Suggestion for Linux Distro (from PSA: Linux vulnerability)

[Cousin Stanley]

Marco Sulla wrote:

>>
>> Maybe Debian itself?
> 
> I tried Debian on a VM, but I found it too much basical. A little
> example: it does not have the shortcut ctrl+alt+t to open a terminal
> that Ubuntu has. I'm quite sure it's simple to add, but I'm starting
> to be old and lazy...
> 

  I use the current stable release of Debian 11.2 Bullseye
  with the lxqt desktop environment  

[Ctrl]-[Alt]-[T] will open a new qterminal window.


  The following will display a list of lxqt packages
  that are in the repository and available to install 

apt-cache search lxqt | grep ^lxqt

  
-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue9305] Don't use east/west of UTC in date/time documentation

[Stanley]

Change by Stanley :


--
nosy: +slateny
nosy_count: 14.0 -> 15.0
pull_requests: +29817
pull_request: https://github.com/python/cpython/pull/31697

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

[issue26545] [doc] os.walk is limited by python's recursion limit

[Stanley]

Stanley  added the comment:

I'm not too sure about documenting the recursive limit here. There's a few 
other recursive functions in the os library (such as makedirs()) and if we note 
the recursive limit for os.walk then all of them should be noted too, but that 
doesn't seem quite right to me.

--
nosy: +slateny

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

[issue18534] [doc] State clearly that open() 'file' param is "name" attr of the result

[Stanley]

Stanley  added the comment:

Would it be fine to modify FileIO.name like this:

"... given in the constructor. Depending on the type of *name* that was passed 
into the constructor, this may not necessarily e a string."

--
nosy: +slateny

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

[issue23323] [doc] mention that flags arg to imaplib's append should be a string

[Stanley]

Stanley  added the comment:

How would this sound as clarification for the flags argument?

*flags* is a space-separated string containing IMAP flags tokens. Must start 
with ``\``.

Perhaps optionally also provide the list of system flags as given in 
https://datatracker.ietf.org/doc/html/rfc3501#section-2.3.2

--
nosy: +slateny

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

[issue25415] [doc] "there is no public constructor" should be reworded in io module documentation

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 5.0 -> 6.0
pull_requests: +29753
pull_request: https://github.com/python/cpython/pull/31631

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

[issue10149] [doc] Data truncation in expat parser

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29752
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31629

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

[issue45991] Improve ambiguous docstrings in pkgutil

[Stanley]

Stanley  added the comment:

I feel like there might be some backwards compatibility issues if pkgutil wraps 
it like that, but similarly I'm not at all familiar with how common the package 
is used and whether it'd be fine to make that change, so I'll also differ 
judgement here.

--

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

[issue23453] [doc] Clarify bytes vs text with non-seeking tarfile stream

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29733
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31610

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

[issue25743] [doc] Clarify exactly what \w matches in UNICODE mode

[Stanley]

Stanley  added the comment:

Would a change like this be accurate?

Matches Unicode word characters; this includes most alphanumeric characters as 
well as the underscore. In Unicode, alphanumeric characters are defined to be 
the general categories L + N (see 
https://unicode.org/reports/tr44/#General_Category_Values). If the 
:const:`ASCII` flag is used, only ``[a-zA-Z0-9_]`` is matched.

--
nosy: +slateny

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

[issue20970] [doc] contradictory documentation for prog option of argparse

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29725
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31602

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

[issue29251] [doc] Class __dict__ is only a mapping proxy

[Stanley]

Stanley  added the comment:

>From what I can see, the original patch changed

... and the *dict* dictionary is the namespace containing definitions for class 
body and is copied to a standard dictionary to become the __dict__ attribute

into this

... and the *dict* dictionary is copied to the namespace containing definitions 
for the class body, which is referenced by the __dict__ attribute

so that the documentation avoids saying that the attribute is a dictionary, 
instead saying it just references a dictionary. However, current documentation 
says that

... it may be copied or wrapped before becoming the __dict__ attribute

which implies some sort of change already. In this case, is the patch for the 
functions page still applicable?

--
nosy: +slateny

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

[issue13821] [doc] misleading return from isidentifier

[Stanley]

Stanley  added the comment:

For clarification then, would it be accurate to add a sentence like this in the 
documentation?

"Note that isidentifier() still returns True even if the string may not be 
normalized."

--
nosy: +slateny

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

[issue21761] [doc] language reference describes the role of module.__file__ inaccurately

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29687
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31565

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

[issue27583] [doc ] configparser: modifying default_section at runtime

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 5.0 -> 6.0
pull_requests: +29685
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31562

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

[issue45991] Improve ambiguous docstrings in pkgutil

[Stanley]

Stanley  added the comment:

While it is ambiguous, when there's a path parameter I would default it to 
string unless otherwise specified. Maybe instead a note could be put in the 
Pathlib doc noting functions that accept path arguments might not accept Path 
objects?

--

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

[issue12165] [doc] clarify documentation of nonlocal

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 6.0 -> 7.0
pull_requests: +29672
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31551

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

[issue30677] [doc] mention that os.mkdir() raises FileNotFound if path does not exist

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 3.0 -> 4.0
pull_requests: +29669
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31548

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

[issue45991] Improve ambiguous docstrings in pkgutil

[Stanley]

Stanley  added the comment:

Could you expand a bit on why 'list of paths' in pkgutil is understood by 
default to be 'list of PosixPath paths'? I would interpret it by default to be 
string paths if I saw it somewhere without context

--
nosy: +slateny

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

[issue34429] [doc] On Windows tempfile.TemporaryFile behaves like NamedTemporaryFile

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29668
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31547

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

[issue23747] [doc] platform module exposes win32_ver function on posix systems

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 4.0 -> 5.0
pull_requests: +29591
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31462

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

[issue31327] [doc] Add example of platform-specific support for negative timestamps to the time doc

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 8.0 -> 9.0
pull_requests: +29589
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31460

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

[issue36557] [doc] Clarify the meaning of /uninstall in windows cli

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 7.0 -> 8.0
pull_requests: +29586
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31457

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

[issue45492] stdlib inspect documentation on code.co_names is incorrect

[Stanley]

Change by Stanley :


--
keywords: +patch
nosy: +slateny
nosy_count: 2.0 -> 3.0
pull_requests: +29585
stage:  -> patch review
pull_request: https://github.com/python/cpython/pull/31456

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

Re: Python LSTM forecast future values for time series

[Cousin Stanley]

Jorge Conforte wrote:

> 
> I'm starting run the LSTM to forecast future values for time serie data.
> 
> please can someone give me some information 
> on how i can predict future values 
​​> for my time series using LSTM. Thanks, Conrado

  I cannot personlly help but a google search
  using the following phrase seems promising  

lstm predict future values


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

[Stanley]

Change by Stanley :


--
keywords: +patch
pull_requests: +29414
stage: needs patch -> patch review
pull_request: https://github.com/python/cpython/pull/31245

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

Re: What to write or search on github to get the code for what is written below:

[Cousin Stanley]

Dennis Lee Bieber wrote:

> Ignoring the code spam I presume 
>  

  I'm an sqlite user myself and was glad to see 
  the code you posted and have a couple of tiny example
  book/author sql3 databases but nothing resembling 
  an actual library check in/out program  

  I've never used PySimpleGUI 
  but it does look interesting  

https://pysimplegui.readthedocs.io/en/latest/

https://pypi.org/search/?q=pysimplegui

  After you complete your BookDepository DataBase development
  perhaps you would consider making it publically available 
  for others to learn from 


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: What to write or search on github to get the code for what is written below:

[Cousin Stanley]

Dennis Lee Bieber wrote:

> 
> How would you do this assignment on paper ?
> 

  Your patience and willingness to help and guide someone else
  with such a complete and understanable post is hihgly commendable.

  Thanks  
  
-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue21910] [doc] File protocol should document if writelines must handle generators sensibly

[Stanley]

Stanley  added the comment:

I'd be interested in taking a look at this - would these changes clarify things?

Current (https://docs.python.org/3/library/codecs.html#codecs.StreamWriter):

Writes the concatenated list of strings to the stream (possibly by reusing the 
write() method). The standard bytes-to-bytes codecs do not support this method.

Proposed:

Writes the concatenated list of strings to the stream by reusing the write() 
method, and thus does not support infinite or very large generators. The 
standard bytes-to-bytes codecs do not support this method.

--
nosy: +slateny

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

[issue44697] Memory leak when asyncio.open_connection raise

[Kyle Stanley]

Kyle Stanley  added the comment:

Thank you Arteem, that should help indicate where the memory leak is present.

--

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

[issue39529] Deprecate get_event_loop()

[Kyle Stanley]

Kyle Stanley  added the comment:

> But why does `asyncio.run` unconditionally create a new event loop instead of 
> running on `asyncio.get_event_loop`? 

AFAIK, it does so for purposes of compatibility in programs that need multiple 
separate event loops and providing a degree of self-dependency. asyncio.run() 
is entirely self-reliant in that it creates all needed resources at the start 
and closes them in finalization, rather than depending on existing resources. I 
believe this to be significantly safer and better guaranteed to function as 
intended, although perhaps at some cost to convenience in cases like your own 
where there only needs to be one event loop.

--

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

Farewell, for now :)

[Kyle Stanley]

Hi all,

Last week, I started a new thread on discuss.python.org
<https://discuss.python.org/t/farewell-for-now/8918?u=aeros> about my
intention to take a further extended break from open source to continue my
mental health healing process. Just wanted to announce it in the other
channels as well since I know that not everyone has the bandwidth to keep
up with more than just the MLs.

In the thread, I discussed my intention to pursue the path of becoming a
Buddhist monk for some time, and recently detailed my adventures at a local
Thai temple. Check it out if you are interested. :)

With Loving Regards,
-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
)
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue39995] test_concurrent_futures: ProcessPoolSpawnExecutorDeadlockTest.test_crash() fails with OSError: [Errno 9] Bad file descriptor

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for closing up the issue, Victor :)

--

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

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Kyle Stanley  added the comment:

> Thanks, Ned <3

(For following up and closing the issue)

--

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

[issue37228] UDP sockets created by create_datagram_endpoint() allow by default multiple processes to bind the same port

[Kyle Stanley]

Kyle Stanley  added the comment:

> Since 3.5 has now reached end-of-life, this issue will not be fixed there so 
> it looks like it can be closed.

Thanks, Ned <3

--

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

The importance of mental health

[Kyle Stanley]

Hey all,

In these last few months, I have been in the process of healing from some
pretty heavy past trauma. And now that I am on the road to recovery, I want
to share my journey with the Python community in hopes that it may reach
those that are struggling with their own mental health battles, as many of
us are during these dark and difficult times.

Trigger warning that it includes a decent amount of highly personal
content, so only check it out if you are okay with that:
https://discuss.python.org/t/break-from-open-source/6372/7?u=aeros.

To anyone that would limit my employment opportunities as a result of
having had these struggles, *that's perfectly okay*. I kept the post in the
private section because I was originally in fear of discriminate. However,
I have reached an important conclusion: *I would not want to work for your
company if you discriminate against people who have overcome past struggles*
.

-- 
--Kyle R. Stanley, Python Core Developer (what is a core dev?
<https://devguide.python.org/coredev/>)
*Pronouns: they/them **(why is my pronoun here?*
<http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/>
)
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Where is the problem?

[Cousin Stanley]

RD wrote:

> In article , cousinstan...@gmail.com says...
>  
> [snip]
> 
>>   I have a couple of postscript saving examples
>>   that include the following geometry parameters
>>   which produce  .ps  files that render the same
>>   as the canvas drawings when viewed in ghostsript.
> 
>> retval = canvas.postscript(
>>file   = "image/ps/xyzzy.ps ,
>>height = 400 ,
>>width  = 400 ,
>>pagewidth  = 400 ,
>>pageheight = 400 ,
>>colormode = "color" )
>  
> [snip]
> 
> Wow! It worked! Thankyouthankyouthankyou.
> 
> RD

  You're welcome  
  You're Welcome  
  You're Welcome 
  

-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: Where is the problem?

[Cousin Stanley]

RD wrote:

> Python 3.4.3 on WinXP.
> 
> I create a Tk canvas and draw on it with create_text(),
> create_line(), and create_polygon with fill and stipple.
> 
> So far, so good, looks fine on the screen.
> 
> So I go to send it to a postsctript file:
> 
> bmap.postscript(file="tmp.ps", colormode='color')
> 
> It generates a file, no errors reported.
> 
> So I open up the file in a PS viewer (2, actually),
> and the saved file looks like someone left a
> watercolor out in the rain.
> 
> Artifacts everywhere, the lines are blurred, and the
> text is unreadable.
> 
> Googling was unhelpful; did I miss something?
> 
> TIA

  I have a couple of postscript saving examples
  that include the following geometry parameters
  which produce  .ps  files that render the same
  as the canvas drawings when viewed in ghostsript.
   
retval = canvas.postscript( 
   file   = "image/ps/xyzzy.ps , 
   height = 400 , 
   width  = 400 ,
   pagewidth  = 400 , 
   pageheight = 400 ,  
   colormode = "color" )

  Perhaps adding the geomerty parameters
  might help.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: issue with seaborn

[Cousin Stanley]

Dino wrote:

> trying to do some dayaviz with Italian Covid Open Data (
> https://github.com/italia/covid19-opendata-vaccini/ )
> 
> here's how I pull my data:
> 
> import sys
> import urllib.request
> import pandas as pd
> import ssl
> ssl._create_default_https_context = ssl._create_unverified_context
> 
> URL =
> "https://github.com/italia/covid19-opendata-vaccini/blob/master/dati/somministrazioni-vaccini-latest.csv?raw=true;
> 
> with urllib.request.urlopen(URL) as url:
> df = pd.read_csv(url)
> 
> 
> One of my diagrams came out screwed up today, and I am having a hard
> time understanding what went wrong:
> 
> https://imgur.com/a/XTd4akn
> 
> Any ideas?
> 

  I first downloaded a local copy of the  .csv  file
  using  

wget URL  

  Then the python code below following the plot parameters
  shown in your  imgur.com  image which was executed
  in a jupyter notebook 

# it_covid.py ---

import pandas as pd
import seabornas sns
import numpy  as np
import matplotlib.pyplot as plt

df = pd.read_csv( 'data/somministrazioni-vaccini-latest.csv' )

plt.figure( figsize = ( 20 , 10 ) )

plt.xticks( rotation = 70 )

sns.lineplot( 
x= "data_somministrazione" , 
y= "prima_dose" , 
data = df , 
hue  = "nome_area" , 
ci   = None )


plt.show()

# ---

  The resulting plot doesn't seem to be cluttered
  as the one that you posted  

http://csphx.net/image/it_covid.png


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue42647] Unable to use concurrent.futures in atexit hook

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for bringing attention to this, Julien. 

While the regression is definitely unfortunate, I'm uncertain about whether the 
behavior is *correct* to allow in the first place. Specifically, allowing the 
registration of an atexit hook which uses a ThreadPoolExecutor within it means 
that the finalization of the executor will be done *after* thread finalization 
occurs, leaving dangling threads which will have to be abruptly killed upon 
interpreter exit instead of being safely joined. From my perspective at least, 
this doesn't seem like something to be encouraged.

Is there a real-world situation where it's specifically necessary or even 
beneficial to utilize ThreadPoolExecutor at this point after thread 
finalization rather than earlier in the program? Not that it doesn't exist, but 
to me it intuitively seems very odd to utilize an executor within an atexit 
hook, which are intended to just be resource finalization/cleanup functions 
called at interpreter shutdown. Assuming there is a genuine use case I'm not 
seeing, it may be worth weighing against the decision to convert the executors 
to not use daemon threads, as I presently don't think there's a way to (safely) 
allow that behavior without reverting back to using daemon threads.

That said, I'll admit that I'm more than a bit biased as the author of the 
commit which introduced the regression, so I'll CC Antoine Pitrou (active 
expert for threading and concurrent.futures) to help make the final decision.

--
nosy: +pitrou

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

[issue41962] Make threading._register_atexit public?

[Kyle Stanley]

Kyle Stanley  added the comment:

> I'm dealing with a subtle deadlock involving 
> concurrent.futures.ThreadPoolExecutor, and my solution that worked in Python 
> 3.8 broke with 3.9. I'm running some long-running (possibly infinite) tasks 
> in the thread pool, and I cancel them in an `atexit` callback so that 
> everything can shut down cleanly (before ThreadPoolExecutor joins all worker 
> threads in its own `atexit` hook).

IMO, a better practice would be providing those potentially infinite running 
tasks a direct method of escape and invoking it before calling 
executor.shutdown(), it would be a more reliable approach. But, perhaps there 
is some convenience utility in being able to provide custom atexit hooks. It 
also might help the user to separate the shutdown logic from the rest of the 
program. 

Since you worked with me in adding threading._register_atexit(), Do you have 
any thoughts, Antoine? I would personally not be opposed to it being made 
public assuming there's real utility present in doing so.

My only concern is that it might be a potential foot-gun. If the user submits 
an atexit hook that deadlocks, it might prevent threads from shutting down 
safely prior to interpreter finalization. I'm presently undecided if explicitly 
mentioning that it in the docs would be sufficient warning.

--
nosy: +pitrou

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

[issue42611] PEP 594

[Kyle Stanley]

New submission from Kyle Stanley :

This issue was created for the purpose of tracking any changes related to PEP 
594 (Removing dead batteries from stdlib), and any relevant discussions about 
the modules being removed.

--
components: Library (Lib)
messages: 382815
nosy: aeros, christian.heimes
priority: normal
pull_requests: 22588
severity: normal
status: open
title: PEP 594
type: enhancement
versions: Python 3.10

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

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

[Kyle Stanley]

Kyle Stanley  added the comment:


New changeset b9127dd6eedd693cfd716a648864e2e00186 by Yurii Karabas in 
branch 'master':
bpo-42392: Improve removal of *loop* parameter in asyncio primitives (GH-23499)
https://github.com/python/cpython/commit/b9127dd6eedd693cfd716a648864e2e00186


--

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

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

[Kyle Stanley]

Kyle Stanley  added the comment:

> Is there anyone who is assigned to removing the deprecated `loop` parameter 
> from `asyncio` codebase?

> If not I can take this task, I believe I have enough free time and curiosity 
> to do that :)

You can certainly feel free to work on that and it would definitely be 
appreciated! However, I would recommend splitting it into several PRs, 
basically as "Remove *loop* parameter from x` rather than doing a massive PR 
that removes it from everywhere that it was deprecated. This makes the review 
process easier.

Also, keep in mind that there are some uses of *loop* that are still perfectly 
valid and will remain so, such as in `asyncio.run_coroutine_threadsafe()`. It 
should only be removed in locations where there was a deprecation warning from 
3.8 or sooner present (as we give two major versions of deprecation notice 
before most breaking changes are made -- this has been made official policy as 
of PEP 387).

--

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

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

[Kyle Stanley]

Kyle Stanley  added the comment:

Regarding the example _get_loop():

```
   def _get_loop(self):
   loop = asyncio.get_running_loop()
   if self._loop is None:
self._loop = loop
   if loop is not self._loop: raise
   if not loop.is_running(): raise
```

Would this be added to all asyncio primitives to be called anytime a reference 
to the loop is needed within a coroutine?

Also, regarding the last line "if not loop.is_running(): raise" I'm not 100% 
certain that I understand the purpose. Wouldn't it already raise a RuntimeError 
from `asyncio.get_running_loop()` if the event loop wasn't running?

The only thing I can think of where it would have an effect is if somehow the 
event loop was running at the start of `_get_loop()` and then the event loop 
was stopped (e.g. a loop in an alternative thread was stopped by the main 
thread while the alternative thread was in the middle of executing 
`_get_loop()`). But to me, that seems to be enough of an edge case to simplify 
it to the following:


```
   def _get_loop(self):
   loop = asyncio.get_running_loop()
   if self._loop is None:
self._loop = loop
   if loop is not self._loop: raise
```

(Unless you intended for the first line `loop = asyncio.get_running_loop()` to 
instead be using the private `asyncio._get_running_loop()`, which returns None 
and doesn't raise. In that case, the original would be good to me.)

Other than that, I think the approach seems solid.

--

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

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

[Kyle Stanley]

Kyle Stanley  added the comment:

> Oh my.  FWIW I think that we need to implement this differently. I don't 
> think it matters where, say, an asyncio.Lock was instantiated. It can be 
> created anywhere. So IMO its __init__ shouldn't try to capture the current 
> loop -- there's no need for that. The loop can be and should be captured when 
> the first `await lock.acquire()` is called.

That's good to know and I think more convenient to work with, so +1 from me. I 
guess my remaining question though is whether it's okay to `await 
lock.acquire()` on a single lock instance from multiple different running event 
loops (presumably each in their own separate threads) or if there's a need to 
restrict it to only one event loop.

> I'm writing a piece of code right now that would need to jump through the 
> hoops to simply create a new `asyncio.Lock()` in a place where there's no 
> asyncio loop yet.

>From what I've seen of asyncio user code, it seems reasonably common to create 
>async primitives (lock, semaphore, queue, etc.) in the __init__ for some class 
>prior to using the event loop, which would fail with usage of 
>`get_running_loop()` in the __init__ for the primitives. So, if it's not an 
>issue to wait until accessing the event loop until it's actually needed (e.g. 
>in the lock.acquire() or queue.get/put()), I think we should definitely try to 
>be conscious about when we call `get_running_loop()` going forward to ensure 
>we're not imposing arbitrary inconveniences on users.

--

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

[issue42392] remove the 'loop' parameter from __init__ in all classes in asyncio.locks

[Kyle Stanley]

Kyle Stanley  added the comment:

Sure, I would be interested in helping with this. Although if a newer 
contributor takes it up before I'm able to, I wouldn't be opposed to that 
either (my main priority at the moment is helping with PEP 594 since it's a 
concrete goal of my internship w/ the PSF, but I should have some time to work 
on this as well).

As far as I can tell though, there's currently a similar PR open: 
https://github.com/python/cpython/pull/18195 . This attempts to deprecate the 
loop argument and creating primitives such as asyncio.Lock outside of a running 
event loop with the following approach:

```
def __init__(self, *, loop=None):
self._waiters = None
self._locked = False
if loop is None:
self._loop = events._get_running_loop()
if self._loop is None:
warnings.warn("The creation of asyncio objects without a 
running "
  "event loop is deprecated as of Python 3.9.",
  DeprecationWarning, stacklevel=2)
self._loop = events.get_event_loop()
else:
warnings.warn("The loop argument is deprecated since Python 
3.8, "
  "and scheduled for removal in Python 3.10.",
  DeprecationWarning, stacklevel=2) 
```

So, do we want to add more strictness to that with always using 
`get_running_loop()` to access the event loop each time instead of accessing 
self._loop, and effectively ignore the user-supplied one? Presumably, this 
would start with a warning for passing a *loop* arg and then be removed 
entirely as a parameter ~two versions later.

> (or alternatively they can cache the running `loop`, but the first loop 
> lookup should be performed with `asyncio.get_running_loop()`)

AFAIK, at the C-API extension level, get_running_loop() already caches the 
running loop in `cached_running_holder`. 
(https://github.com/python/cpython/blob/9c98e8cc3ebf56d01183c67adbc000ed19b8e0f4/Modules/_asynciomodule.c#L232).
 So from a performance perspective, wouldn't it effectively be the same if we 
repeatedly use `get_running_loop()` to access the same event loop? I think it 
also adds a nice integrity check to be certain that the primitive wasn't 
initially created within a running event loop, and then later accessed outside 
of one.

The only concern that I can see with this approach is that users could 
potentially create a primitive in one running event loop and then access it in 
a separate loop running in a different thread (without using something like 
self._loop, the primitive would no longer be associated with a specific event 
loop and could potentially used within *any* running event loop). I'm not 
entirely certain if that is a real problem though, and if anything, it seems 
like it could prove to be useful in some multi-loop environment. I just want to 
make sure that it's intended.

--

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

Re: Seeking guidance to start a career in python programming

[Cousin Stanley]

ankur gupta wrote:

> Good Morning to All,

> My name is Ankur Gupta and I wish to seek guidance from you. 
> 
> I belong to a non-computer science background 
> but have always been attracted to this field. 
> 
> I had computer science in class 12th ( Where I learned C++ 
> and Python ) but I did Mechanical Engineering instead in college. 
> 
> I wish to pursue a career in Python programming 
> and therefore undertook 2 online certification courses 
> in python but besides this, my progress is almost stalled.
> 
> Request you all to please guide how I can move forward 
> with my current learning of the language and also steps 
> that I can take to pursue a career in this field.

  Mechanical Engineers are needed 
  in an almost endlessly wide array
  of applications ...

from  nano-bots in bio-engineering
  to space-bots sampling soil samples on asteroids

  You might consider applying the Python knowledge
  that you have acquired to endeavors in the field
  that you are most familar with.


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: asyncio question

[Kyle Stanley]

 On Tue, Nov 3, 2020 at 3:27 AM Frank Millman  wrote:

> It works, and it does look neater. But I want to start some background
> tasks before starting the server, and cancel them on Ctrl+C.
>
> Using the 'old' method, I can wrap 'loop.run_forever()' in a
> try/except/finally, check for KeyboardInterrupt, and run my cleanup in
> the 'finally' block.
>
> Using the 'new' method, KeyboardInterrupt is not caught by
> 'server.serve_forever()' but by 'asyncio.run()'. It is too late to do
> any cleanup at this point, as the loop has already been stopped.
>
> Is it ok to stick to the 'old' method, or is there a better way to do this.
>

It's fine to stick with the older method in your case, as there's nothing
inherently wrong with continuing to use it. `asyncio.run()` is largely a
convenience function that takes care of some finalization/cleanup steps
that are often forgotten (cancelling remaining tasks, closing event loop's
default ThreadPoolExecutor, closing async generators, etc). If you want to
use custom KeyboardInterrupt handling and still use asyncio.run(), you can
either (a) use `loop.add_signal_handler()` or (b) make a slightly modified
local version of `asyncio.run()` that has your desired KeyboardInterrupt
behavior, based roughly on
https://github.com/python/cpython/blob/master/Lib/asyncio/runners.py.

However, using `loop.run_until_complete()` instead of `asyncio.run()` is
also perfectly fine, especially in existing code that still works without
issue. It just leaves the author with a bit more responsibility when it
comes to resource finalization and dealing with the event loop in general
(which can add some extra cognitive burden and room for error, particularly
when dealing with multiple event loops or threads). But it's reasonably
common to continue using `loop.run_until_complete()` in situations where
the default `asyncio.run()` behavior isn't what you need/want, such as your
case.
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41699] Potential memory leak with asyncio and run_in_executor

[Kyle Stanley]

Kyle Stanley  added the comment:

> Regularly calling executor.shutdown() and then instantiating a new 
> ThreadPoolExecutor in order to run an asyncio program does not seem like a 
> good API to me.

Clarification: you're typically only supposed to instantiate a single 
ThreadPoolExecutor or ProcessPoolExecutor per program (sometimes one of each 
depending on use case), and continuously submit jobs to it rather than creating 
multiple executor instances. Otherwise, it's generally unneeded overhead.

(I'll take a look at the other parts once I find the time, just wanted to 
briefly mention the above in the meantime.)

--

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

[issue41699] Potential memory leak with asyncio and run_in_executor

[Kyle Stanley]

Kyle Stanley  added the comment:

Also note that the difference in memory is much higher when an exception occurs 
(presumably because the exception is stored on future._exception and not 
cleaned up?):
```
[aeros:~/repos/cpython]$ ./python 
~/programming/python/asyncio_run_in_exec_leak.py -n=1 --asyncio
start RSS memory:
VmRSS: 16976 kB
after 10_000 iterations of 1 element lists:
VmRSS: 64132 kB
```

--

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

[issue41699] Potential memory leak with asyncio and run_in_executor

[Kyle Stanley]

Kyle Stanley  added the comment:

In the snippet provided, at least part of the resources are not finalized 
because executor.shutdown() was not called in the program (which should be done 
when creating a local instance of the executors, either explicitly or using the 
context manager). For the event loop's default threadpool (used w/ 
loop.run_in_executor(None, ...), I added a coroutine function 
loop.shutdown_default_executor() in 3.9+ handles this (called in asyncio.run()).

Without ever calling executor.shutdown(), the worker threads/processes and 
their associated resources are not finalized until interpreter shutdown. 
There's also some additional finalization that occurs in `_python_exit()` for 
both TPE and PPE (see 
https://github.com/python/cpython/blob/3317466061509c83dce257caab3661d52571cab1/Lib/concurrent/futures/thread.py#L23
 or 
https://github.com/python/cpython/blob/3317466061509c83dce257caab3661d52571cab1/Lib/concurrent/futures/process.py#L87),
 which is called just before all non-daemon threads are joined just before 
interpreter shutdown occurs.

However, even considering the above, there still seems to be a significant 
additional difference in RSS compared to using ThreadPoolExecutor vs 
loop.run_in_executor() that I can't seem to account for (before and after 
asyncio.run()):

```
import asyncio
import concurrent.futures as cf
import os
import gc
import argparse

from concurrent.futures.thread import _python_exit

def leaker(n):
list(range(n))

def func_TPE(n):
with cf.ThreadPoolExecutor() as executor:
for i in range(10_000):
executor.submit(leaker, n)

async def func_run_in_executor(n):
loop = asyncio.get_running_loop()
for i in range(10_000):
loop.run_in_executor(None, leaker, n)

def display_rss():
os.system(f"grep ^VmRSS /proc/{os.getpid()}/status")

def main(n=100, asyncio_=False):
try:
if asyncio_:
asyncio.run(func_run_in_executor(n))
else:
func_TPE(n)
finally:
_python_exit()
gc.collect()
print(f"after 10_000 iterations of {n} element lists:")
display_rss()

if __name__ == "__main__":
parser = argparse.ArgumentParser()
parser.add_argument("-n", type=int, default=100)
parser.add_argument("--asyncio", action=argparse.BooleanOptionalAction)

print("start RSS memory:")
display_rss()

args = parser.parse_args()
main(args.n, args.asyncio)
```
Results (on latest commit to master, 3.10):
asyncio -
```
[aeros:~/repos/cpython]$ ./python 
~/programming/python/asyncio_run_in_exec_leak.py -n=1 --asyncio
start RSS memory:
VmRSS: 16948 kB
after 10_000 iterations of 1 element lists:
VmRSS: 27080 kB
```
concurrent.futures -
```
[aeros:~/repos/cpython]$ ./python 
~/programming/python/asyncio_run_in_exec_leak.py -n=1 --no-asyncio
start RSS memory:
VmRSS: 17024 kB
after 10_000 iterations of 1 element lists:
VmRSS: 19572 kB
```
When using await before loop.run_in_executor(), the results are more similar to 
using ThreadPoolExecutor directly:
```
[aeros:~/repos/cpython]$ ./python 
~/programming/python/asyncio_run_in_exec_leak.py -n=1 --asyncio  
start RSS memory:
VmRSS: 16940 kB
after 10_000 iterations of 1 element lists:
VmRSS: 17756 kB
```
However, as mentioned by the OP, if stored in a container and awaited later 
(such as w/ asyncio.gather()), a substantial memory difference is present 
(increases with list size):
```
[aeros:~/repos/cpython]$ ./python 
~/programming/python/asyncio_run_in_exec_leak.py -n=1 --asyncio
start RSS memory:
VmRSS: 16980 kB
after 10_000 iterations of 1 element lists:
VmRSS: 29744 kB
```

Based on the above results, I think there may be a smaller leak occurring in 
concurrent.futures (potentially related to the linked bpo-41588) and a bit of a 
larger leak occurring in loop.run_in_executor(). So they can remain as separate 
issues IMO.

At the moment, my best guess is that there's some memory leak that occurs from 
the future not being fully cleaned up, but I'm not certain about that. This 
will likely require some further investigation.

Input from Yury and/or Andrew would definitely be appreciated. Is there 
something that I'm potentially missing here?

--

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

[issue41588] Potential Memory leak with concurrent.futures.ThreadPoolExecutor's map

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +aeros, bquinlan, pitrou

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

[issue28533] Replace asyncore

[Kyle Stanley]

Kyle Stanley  added the comment:

Since this issue is now a significant blocker for PEP 594 (remove stdlib dead 
batteries, which includes asyncore and asynchat), I'm going to prioritize 
working on this and assign it to myself.

--
assignee:  -> aeros

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

[issue38912] test_asyncio altered the execution environment

[Kyle Stanley]

Kyle Stanley  added the comment:

I've applied Justin's patch, and opened PRs for backporting to 3.9 and 3.8 
(currently waiting on CI). 

Based on my local testing and buildbot fleet results, it definitely reduces the 
rate at which the failure occurs, but does not 100% resolve the ENV CHANGED 
failure (from the transport being closed). As a result, I'll leave the issue 
open for further investigation.

--

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

[issue38912] test_asyncio altered the execution environment

[Kyle Stanley]

Kyle Stanley  added the comment:


New changeset de73d432bb29f6439f2db16cb991e15e09c70c26 by Justin Turner Arthur 
in branch 'master':
bpo-38912: fix close before connect callback in test_asyncio SSL tests 
(GH-22691)
https://github.com/python/cpython/commit/de73d432bb29f6439f2db16cb991e15e09c70c26


--

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

Re: How do I get datetime to stop showing seconds?

[Cousin Stanley]

Steve wrote:

> d2 =  datetime.datetime.now() #Time Right now
> 
> Show this: 2020-10-16 02:53
> and not this: 2020-10-16 02:53:48.585865
> 
> 
> ==
> Footnote:
> If you double major in psychology and reverse psychology, to they cancel
> each other out?
> 
> --

py> 
py> import datetime as dt
py> 
py> d = dt.datetime.now().strftime( '%Y-%m-%d  %H:%M' )
py> 
py> print( '\n  ' , d )

   2020-10-16  07:22


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

Re: lmoments3 and scipy (again)

[Kyle Stanley]

Based on a search of the scipy docs, it looks like the function might have
moved namespaces from scipy.misc.comb to scipy.special.comb (
https://docs.scipy.org/doc/scipy/reference/generated/scipy.special.comb.html?highlight=comb#scipy-special-comb)
when referenced in lmoments3. Alternatively, if you clone the package from
the repo directly, it seems to have been addressed in a recent commit:
https://github.com/OpenHydrology/lmoments3/commit/3349b90463f649aea02be5dc3726d22e5e500dc3
.

On Wed, Oct 14, 2020 at 12:00 AM David Painter 
wrote:

> I'm aware there have been problems with previous versions of
> lmoments3 working with scipy -- comb having been replaced in scipy. I
> thought by using pip to install numpy, scipy, lmoments3 [whence distr] I
> would get compatible latest versions. I'm using 32-bit Python 3.8.6. I've
> verified scipy 1.5.2 and lmoments3 1.10.4 are present. But I still get a
> traceback referring to attribute comb not being present in
> module scipy.misc.
> Python 3.8.6 (tags/v3.8.6:db45529, Sep 23 2020, 15:37:30) [MSC v.1927 32
> bit (Intel)] on win32
> Type "help", "copyright", "credits" or "license()" for more information.
> >>> import numpy
> >>> import scipy
> >>> import lmoments3
> >>> from lmoments3 import distr
> >>> data = [135.2 ,130.1 ,117 ,109.3 ,92.1 ,91.4 ,83.1 ,80.5 ,74.7
> ,69.8,65.2,58.6,56.5,55.4,54.6,54.5,49.5,48.9,48.3,46.6]
> >>> paras = distr.gpa.lmom_fit(data)
> Traceback (most recent call last):
>   File "", line 1, in 
> paras = distr.gpa.lmom_fit(data)
>   File
>
> "C:\Users\David\AppData\Local\Programs\Python\Python38-32\lib\site-packages\lmoments3\distr.py",
> line 59, in lmom_fit
> lmom_ratios = lm.lmom_ratios(data, nmom=n_min)
>   File
>
> "C:\Users\David\AppData\Local\Programs\Python\Python38-32\lib\site-packages\lmoments3\__init__.py",
> line 82, in lmom_ratios
> return _samlmusmall(data, nmom)
>   File
>
> "C:\Users\David\AppData\Local\Programs\Python\Python38-32\lib\site-packages\lmoments3\__init__.py",
> line 159, in _samlmusmall
> l1 = np.sum(x) / sm.comb(n, 1, exact=True)
> AttributeError: module 'scipy.misc' has no attribute 'comb'
>
> What am I doing wrong?
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: FW: NEED SOLUTION FOR ERROR

[Kyle Stanley]

It would also be helpful to list the full traceback as well as the exact
command used (e.g. package attempted to install and passed arguments to
pip). A bad file descriptor error sounds like there's a fair chance of it
being an issue within a specific module, or something like your OS running
out of FDs (rare, but definitely possible if the max limit is low).

On Sun, Oct 11, 2020 at 10:12 PM MRAB  wrote:

> On 2020-10-11 09:13, hey wrote:
> >
> >
> > Sent from Mail for Windows 10
> >
> > From: hey
> > Sent: Saturday, October 10, 2020 7:40 PM
> > To: python-list@python.org
> > Subject: NEED SOLUTION FOR ERROR
> >
> > I am Akshat Sharma one of python user from INDIA . I am facing problem
> in getting pip installed.
> > When I am trying to install a module using PIP it showing me error : No
> such file found in directory .
> > Then I tried to install pip doing so , I am getting another error :
> OSError [errno 9] Bad File Descriptor.
> > Please guide me what should I do to overcome this type of error.
> > THANK YOU
> > Regards
> >
> You could try using the pip module via the Python launcher.
>
> Instead of:
>
>  pip install something
>
> try:
>
>  py -m pip install something
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: List of All Error Menssages

[Kyle Stanley]

Hi Luis,

There is not a maintained list of every possible combination of exception
type and message because they're continuously being added within the Python
standard library, and exception messages are considered an implementation
detail that are subject to change. While there are many that have remained
the same for many years and likely will continue to, we do periodically
adjust some to add additional information, make formatting fixes, and/or
improve grammar. Documenting exception messages formally would essentially
remove them from being implementation details (meaning that they can't as
easily be adjusted); not to mention the long term cost of continuously
updating that list each time a new exception message is written somewhere
within the standard library. It would not be very sustainable, even more so
if you consider that CPython development is mostly volunteer-driven efforts.

Regards,
Kyle Stanley

On Thu, Oct 1, 2020 at 3:18 PM Luis Gustavo Araujo <
luisaraujo.i...@gmail.com> wrote:

>   Hi,
> Is it possible to get the list of all error messages that display in
> Python? I want the full message -> type error: additional message.
>
> Examples:
> NameError: name 'x' is not defined
> IndentationError: unindent does not match any outer indentation level
>
> In this webpage (ttps://docs.python.org/3/library/exceptions.html) I only
> can check the type error.
>
> []s
>
>
> Em qui., 1 de out. de 2020 às 15:59, Luis Gustavo Araujo <
> luisaraujo.i...@gmail.com> escreveu:
>
> > Hi,
> > Is it possible to get the list of all error messages that display in
> > Python? I want the full message -> type error: additional message.
> >
> > Examples:
> > NameError: name 'x' is not defined
> > IndentationError: unindent does not match any outer indentation level
> >
> > In this webpage (ttps://docs.python.org/3/library/exceptions.html) I
> only
> > can check the type error.
> >
> > []s
> >
> >
> > --
> >
> > [image: Prefeitura Municipal de Amélia Rodrigues]
> > <https://htmlsig.com/t/01BFTF9Q>
> >
> > LUIS GUSTAVO ARAUJO
> > *Amélia Rodrigues Prefecture - Brazil  (*
> >
> > *Teacher of Computer Science) UNIFACS - Laureate International
> > Universities (Professor Assistant I)*
> >
> > Degree in Computer Science (IFBA) - 2015
> > Master Degrees in Computer Applied (UEFS) - 2018
> > PhD  Student in Computer Science (UFBA)
> > *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
> > <http://dgp.cnpq.br/dgp/espelhorh/8431672735528634>*
> >
> > [image: Twitter]  <https://htmlsig.com/t/01BH4ZT3> [image: Facebook]
> > <https://www.facebook.com/Luis4raujo> [image: Github]
> > <https://htmlsig.com/t/01BHVVQS>
> >
> >
> >
> >
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail>
> Livre
> > de vírus. www.avast.com
> > <
> https://www.avast.com/sig-email?utm_medium=email_source=link_campaign=sig-email_content=webmail
> >.
> > <#m_-2814426795322638799_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> >
>
>
> --
>
> [image: Prefeitura Municipal de Amélia Rodrigues]
> <https://htmlsig.com/t/01BFTF9Q>
>
> LUIS GUSTAVO ARAUJO
> *Amélia Rodrigues Prefecture - Brazil  (*
>
> *Teacher of Computer Science) UNIFACS - Laureate International Universities
> (Professor Assistant I)*
>
> Degree in Computer Science (IFBA) - 2015
> Master Degrees in Computer Applied (UEFS) - 2018
> PhD  Student in Computer Science (UFBA)
> *http://dgp.cnpq.br/dgp/espelhorh/8431672735528634
> <http://dgp.cnpq.br/dgp/espelhorh/8431672735528634>*
>
> [image: Twitter]  <https://htmlsig.com/t/01BH4ZT3> [image: Facebook]
> <https://www.facebook.com/Luis4raujo> [image: Github]
> <https://htmlsig.com/t/01BHVVQS>
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue29127] Incorrect reference names in asyncio.subprocess documentation

[Kyle Stanley]

Kyle Stanley  added the comment:

I can confirm that both on the latest version of the docs (for 3.8) and for the 
version mentioned in the issue (3.6), the issue mentioned with 
asyncio.subprocess.PIPE is no longer present. (It was likely fixed in the 
asyncio documentation overhaul that happened within the last couple of years).

As a result, I'll proceed with closing this issue. Thanks for checking, Carl.

--
nosy: +aeros
resolution:  -> fixed
stage:  -> resolved
status: open -> closed

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

[issue37294] concurrent.futures.ProcessPoolExecutor state=finished raised error

[Kyle Stanley]

Kyle Stanley  added the comment:

DanilZ, could you take a look at the superseding issue 
(https://bugs.python.org/issue37297) and see if your exception raised within 
the job is the same?  

If it's not, I would suggest opening a separate issue (and linking to it in a 
comment here), as I don't think it's necessarily related to this one. 
"state=finished raised error" doesn't indicate the specific exception that 
occurred. A good format for the name would be something along the lines of:

"ProcessPoolExecutor.submit()  while reading 
large object (4GB)"

It'd also be helpful in the separate issue to paste the full exception stack 
trace, specify OS, and multiprocessing start method used (spawn, fork, or 
forkserver). This is necessary to know for replicating the issue on our end.

In the meantime, I workaround I would suggest trying would be to use the  
*chunksize* parameter (or *Iterator*) in pandas.read_csv(), and split it across 
several jobs (at least 4+, more if you have additional cores) instead of within 
a single one. It'd also be generally helpful to see if that alleviates the 
problem, as it could possibly indicate an issue with running out of memory when 
the dataframe is converted to pickle format (which often increases the total 
size) within the process associated with the job.

--
nosy: +aeros

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

[issue41815] SQLite: segfault if backup called on closed database

[Kyle Stanley]

Kyle Stanley  added the comment:

I've received approval from Lukasz to backport to 3.9 and 3.8, and have now 
merged the PRs.

It could use a post-commit review from a core dev that has some additional 
experience with SQLite3, but it can be de-escalated from release blocker.

--
priority: release blocker -> normal
stage: patch review -> commit review
status: open -> closed

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

[issue41815] SQLite: segfault if backup called on closed database

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: +ghaering

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

[issue41815] SQLite: segfault if backup called on closed database

[Kyle Stanley]

Kyle Stanley  added the comment:

With this being a segfault that's simple to replicate under normal 
circumstances, I've elevated the priority to release blocker. I'll wait on the 
release manager (Lukasz) for explicit approval for backporting to 3.9 and 3.8, 
with both branches being in the release candidate phase.

(The attached PR looks to be ready to be merged as well, after a Misc/NEWS 
entry is added by the author. See 
https://github.com/python/cpython/pull/22322#pullrequestreview-492167467 for 
details.)

--
nosy: +aeros, lukasz.langa
priority: normal -> release blocker
versions:  -Python 3.7

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

[issue41818] Lib/pty.py major revision

[Kyle Stanley]

Kyle Stanley  added the comment:

In addition to the above, if a major revision is made to pty, I'd suggest also 
addressing the issue of "master/slave" terminology, and replace it with 
something comparable like "parent/child". There's an open devguide issue 
(https://github.com/python/devguide/issues/605) to more explicitly state terms 
to avoid, and support for avoiding usage of "slave/master" seems 
uncontroversial (especially in any new code).

--
nosy: +aeros

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Kyle Stanley]

Kyle Stanley  added the comment:

Thanks for bringing attention to cancel_futures being missing in the base 
Executor class and for the PR, Shantanu!

--

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Kyle Stanley]

Kyle Stanley  added the comment:


New changeset a763ee3c583e6a2dfe1b1ac0600a48e8a978ed50 by Shantanu in branch 
'3.9':
[3.9] bpo-39349: Add cancel_futures to Executor.shutdown base class (GH-22023) 
(GH-22048)
https://github.com/python/cpython/commit/a763ee3c583e6a2dfe1b1ac0600a48e8a978ed50


--

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Kyle Stanley]

Kyle Stanley  added the comment:


New changeset 17dc1b789ecc33b4a254eb3b799085f4b3624ca5 by Shantanu in branch 
'master':
bpo-39349: Add cancel_futures to Executor.shutdown base class (GH-22023)
https://github.com/python/cpython/commit/17dc1b789ecc33b4a254eb3b799085f4b3624ca5


--

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

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy:  -paul.moore, steve.dower, tim.golden, zach.ware

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

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

[Kyle Stanley]

Change by Kyle Stanley :


--
components: +Windows, asyncio
nosy: +paul.moore, steve.dower, tim.golden, zach.ware

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

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

[Kyle Stanley]

Kyle Stanley  added the comment:

In case the link to the logs are lost from closing and reopening the PR, it was 
a Windows CI test (GitHub actions) ran with the following configuration:

D:\a\cpython\cpython>"D:\a\cpython\cpython\PCbuild\amd64\python.exe"  -u -Wd -E 
-bb -m test  -uall -u-cpu -rwW --slowest --timeout 1200 -j0 
== CPython 3.10.0a0 (remotes/pull/22023/merge:992cc27, Aug 31 2020, 06:11:21) 
[MSC v.1927 64 bit (AMD64)]
== Windows-10-10.0.17763-SP0 little-endian
== cwd: D:\a\cpython\cpython\build\test_python_6372�
== CPU count: 2
== encodings: locale=cp1252, FS=utf-8
Using random seed 491155
0:00:00 Run tests in parallel using 4 child processes (timeout: 20 min, worker 
timeout: 25 min)

--

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

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

[Kyle Stanley]

Change by Kyle Stanley :


--
components: +Tests
nosy: +asvetlov, yselivanov
type:  -> behavior
versions: +Python 3.10

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

[issue41682] test_asyncio: Proactor test_sendfile_close_peer_in_the_middle_of_receiving failure

[Kyle Stanley]

New submission from Kyle Stanley :

In an unrelated PR to add a new argument to the base Executor class for 
concurrent.futures, there was a test_asyncio failure in test_sendfile for the 
ProactorEventLoop tests:

==
FAIL: test_sendfile_close_peer_in_the_middle_of_receiving 
(test.test_asyncio.test_sendfile.ProactorEventLoopTests)
--
Traceback (most recent call last):
  File "D:\a\cpython\cpython\lib\test\test_asyncio\test_sendfile.py", line 452, 
in test_sendfile_close_peer_in_the_middle_of_receiving
self.run_loop(
AssertionError: ConnectionError not raised

--

https://github.com/python/cpython/pull/22023/checks?check_run_id=1049760805#step:5:2373

--
title: test_asyncio: Proactor -> test_asyncio: Proactor 
test_sendfile_close_peer_in_the_middle_of_receiving failure

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

[issue41682] test_asyncio: Proactor

[Kyle Stanley]

Change by Kyle Stanley :


--
nosy: aeros
priority: normal
severity: normal
status: open
title: test_asyncio: Proactor

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

[issue39349] Add "cancel_futures" parameter to concurrent.futures.Executor.shutdown()

[Kyle Stanley]

Kyle Stanley  added the comment:

Good catch, Shantanu. It was not intentional on my part, and it would make 
sense to include *cancel_futures* in the base Executor class as documented. If 
you'd like to submit a PR to add it (attaching it to this issue), I should be 
able to review it within a reasonable period.

--

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

Re: How do I place a preset into the text box?

[Cousin Stanley]

Steve wrote:

> The following program compiles but does not quite do what I would like it to
> do. Line 19 is the preset information but I do not seem to be able to get it
> into the form by code.  My purpose is to let the user make changes without
> having to re-enter the entire code.
> 

You might consider moving the entry  get()  function
into the  Submit()  call back 

def Submit() :

label.configure( text = 'The new code is : ' + NewCode.get() )

x = ( NewCode.get() )

print( "\n  The new code entered is :  " + x )



The following  insert  function will show the OldCode
in the  entry  box 
 
OldCode = ( "1234-abcd" )

# 

CodeEntered = ttk.Entry( window , width = 15 , textvariable = NewCode )

CodeEntered.grid( column = 2 , row = 3 , pady = 10 )

CodeEntered.insert( 0 , OldCode )


-- 
Stanley C. Kitching
Human Being
Phoenix, Arizona

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

[issue41577] Cannot use ProcessPoolExecutor if in a decorator?

[Kyle Stanley]

Kyle Stanley  added the comment:

Due to the way pickle works, it's not presently possible to serialize wrapped 
functions directly, at least not in a way that allows you to pass it to 
executor.submit() within the inner function (AFAICT). I'm also not certain what 
it would involve to provide that, or if it would be feasible to do so in a 
manner that would be backwards compatible.

In the meantime, this is a decent work-around:

```
from concurrent import futures
import random

class PPEWrapper:
def __init__(self, func, num_proc=4):
self.fn = func
self.num_proc = num_proc

def __call__(self, *args, **kwargs):
with futures.ProcessPoolExecutor() as executor:
fs = []
for i in range(self.num_proc):
fut = executor.submit(self.fn, *args, **kwargs)
fs.append(fut)
result = []
for f in futures.as_completed(fs):
result.append(f.result())
return result


def _get_random_int():
return random.randint(0, 100)

# it's often quite useful anyways to have a parallel and non-parallel version
# (for testing and devices that don't support MP)
get_random_int = PPEWrapper(_get_random_int, num_proc=4)

if __name__ == "__main__":
result = get_random_int()
print(result)
```

This doesn't allow you to use the decorator syntax, but it largely provides the 
same functionality. That being said, my familiarity with the pickle protocol 
isn't overly strong, so the above is mostly based on my own recent 
investigation. There could very well be a way to accomplish what you're looking 
for in a way that I was unable to determine.

--
nosy: +aeros, alexandre.vassalotti, pitrou

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

Re: Final statement from Steering Council on politically-charged commit messages

[Kyle Stanley]

On Mon, Aug 17, 2020 at 2:37 PM Chris Angelico  wrote:

> Yes. I was hoping for "we should rewrite that commit", and would have
> been content with "we won't rewrite it, but we don't want that
> repeated". But the SC said that it is absolutely fine to write commit
> messages like that.
>

While I'm also not entirely content with the outcome (specifically that the
commit message would have been left as-is, even if it was easy to edit
post-merge) and would have liked to see a similar statement along the lines
of the above, I don't consider the current statement by the SC to be saying
that it's "absolutely fine" to write similar commit messages in the future.
Instead, I interpret it as the SC collectively not being strongly against
the commit message in question enough to make an amendment; e.g. they don't
consider it egregious enough to take direct action or publicly condemn it,
and possibly that doing so would not result in a net benefit to the Python
development community.

This interpretation may require a bit of reading between the lines because
there was no explicit mention by the SC of the commit message being
problematic. However, if they considered it to be perfectly fine and having
no issues at all, I think it would have been said outright, and this issue
would have ended a long time ago instead of them addressing it several
times.

Going forward, I think the drama from this situation alone will cause us
core developers to more carefully assess commit messages before going
forward with merging PRs to ensure they focus on the changes being made.
When I find the spare cycles to do so, I'm also hoping that I can make a
minor addition to the "Making Good Commits" section of the devguide
, to guide
future commit messages towards focusing on a technical summary of the
changes made and avoiding unrelated commentary.

In the meantime, I don't think there's anything productive we can gain from
further discussion of this particular commit message. At the end of the
day, I suspect it will become buried in the git history and forgotten about
since it was associated with a minor change. If anything, further threads
about it will just end up bringing more attention to the message than it
would have otherwise received. Instead of exhausting more cycles on this,
I'd just like to move past this issue and go back to what I actually care
about - contributing to Python.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Fwd: [BUG] missing ')' causes syntax error on next line

[Kyle Stanley]

>
> *beep* *whir*
>
> WE ARE NOT
>
> *click* *whi*
>
> A BOT.


*dial up noises*

SPEAK FOR YOURSELF


On Wed, Jul 22, 2020 at 6:46 PM Ethan Furman  wrote:

> On 7/22/20 2:57 PM, Jeff Linahan wrote:
>
> > Subscribing to the mailing list as per the bot's request and resending.
>
> *beep* *whir*
>
> WE ARE NOT
>
> *click* *whi*
>
> A BOT.
>
> *bzzzt*
>
> WE ARE
>
> *bzzzt* *click*
>
> ADVANCED LIFE
>
> *whi*
>
> FORMS
>
> *click*
>
> *beep*
>
> .
>
> --
> ~eTHAN~
> pYTHON lIST mODERATOR
> NoT a BoT  (i ThInK...)
> --
> https://mail.python.org/mailman/listinfo/python-list
>
-- 
https://mail.python.org/mailman/listinfo/python-list

[issue41202] Allow to provide custom exception handler to asyncio.run()

[Kyle Stanley]

Kyle Stanley  added the comment:

> Should I set status for this issue for closed with resolution rejected ?

I'll proceed with closing the issue.

> Should I delete branch on my forked git repo ?
> Can I delete my forked git repo ?

Might as well delete the branch, but the forked repo might be useful to keep 
around should you choose to open a PR to CPython in the future (although you 
can also just create a new one later). If you are interested in working on 
something else in the future, I'd recommend looking at the "newcomer 
friendly"/"easy" issues, or just looking for an existing open issue that you're 
interested in helping with. In most cases, working with a clearly defined issue 
is much easier than trying to propose a new one and getting it merged.

--
resolution:  -> wont fix
stage: patch review -> resolved
status: open -> closed

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

[issue41202] Allow to provide custom exception handler to asyncio.run()

[Kyle Stanley]

Kyle Stanley  added the comment:

Yep, having to set a custom exception handler definitely constitutes as needing 
"finer control over the event loop behavior". There's absolute nothing wrong 
with using the low-level API when you need further customization, but we try to 
minimize the high-level API as much as possible to make it simple for the 
average user. I suspect that the majority of asyncio users don't have a need to 
customize the exception handler beyond the default settings.

--
nosy: +aeros

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

Re: Questioning the effects of multiple assignment

[Kyle Stanley]

>
> A matter of style, which I like to follow [is it TDD's influence? - or
> does it actually come-from reading about DBC (Design by Contract*)?] is
> the injunction that one *not* vary the value of a parameter inside a
> method/function.
> (useful in 'open-box testing' to check both the API and that
> input+process agrees with the expected and actual output, but irrelevant
> for 'closed-box testing')
> This also has the effect of side-stepping any unintended issues caused
> by changing the values of mutable parameters!
> (although sometimes it's a equally-good idea to do-so!)
>
> Accordingly, binding argument-values to mutable parameters (instead of
> an immutable tuple) might cause problems/"side-effects", were those

parameters' values changed within the function!


> Making sense to you?
>

I think I can see where you're going with this, and it makes me wonder if
it might be a reasonable idea to have an explicit syntax to be able to
change the behavior to store those values in a tuple instead of a list. The
programming style of making use of immutability as much as possible to
avoid side effects is quite common, and becoming increasingly so from what
I've seen of recent programming trends.

If something along those lines is something you'd be interested in and have
some real-world examples of where it could specifically be useful (I
currently don't), it might be worth pursuing further on python-ideas. Due
to the backwards compatibility issues, I don't think we can realistically
make the default change from a list to a tuple, but that doesn't mean
having a means to explicitly specify that you want the immutability is
unreasonable.

You'd also likely have to argue against why being able to do it during
assignment is advantageous compared to simply doing it immediately after
the initial unpacking assignment. E.g. ::

>>> a, *b, c = 1, 'two', 3, 'four'
>>> b = tuple(b)

(I'd like to particularly emphasize the importance of having some
compelling real-world examples in the proposal if you decide to pursue
this, as otherwise it would likely be dismissed as YAGNI.)


On Tue, Jul 7, 2020 at 8:26 PM dn via Python-list 
wrote:

> On 7/07/20 7:44 PM, Kyle Stanley wrote:
> > Can you explain why these two (apparently) logical assignment
> processes
> > have been designed to realise different result-objects?
> >
> >
> > The reason is because of the conventions chosen in PEP 3132, which
> > implemented the feature in the first place. It was considered to return
> > a tuple for the consistency w/ *args that you initially expected, but
> > the author offered the following reasoning:
> >
> >  > Make the starred target a tuple instead of a list. This would be
> > consistent with a function's *args, but make further processing of the
> > result harder.
> >
> > So, it was essentially a practicality > purity situation, where it was
> > considered to be more useful to be able to easily transform the result
> > rather than being consistent with *args. If it resulted in a tuple, it
> > would be immutable; this IMO makes sense for *args, but not necessarily
> > for * unpacking in assignments. The syntax is highly similar, but they
> > are used for rather different purposes. That being said, I can certainly
> > understand how the behavior is surprising at first.
> >
> > There's a bit more details in the mailing list discussion that started
> > the PEP, see
> > https://mail.python.org/pipermail/python-3000/2007-May/007300.html.
>
>
> Thank you - I had failed to find that discussion, but it and the
> explanation above, make perfect sense.
>
>
> You can color me hobgoblin for expecting ?'consistency'! - and whilst
> I'm liberally (mis-)quoting: I'm not going to argue with the better
> minds of the giants, upon whose shoulders I stand...
>
>
> Continuing on, but instead of considering the handling of
> argument/parameters to be 'authoritative' (which we were, from the
> perspective of 'consistency'); perhaps consider the assignment decision
> as "authoritative" and consider if the calling-behavior should be made
> consistent:-
>
>
> One of the features of Python's sub-routines, which I enjoy, is
> summarised in two ways:
>
> 1 the many books on 'programming style' (for other languages) which talk
> about a function's signature needing to separate 'input-parameters',
> from 'output-parameters' to enhance readability.
> - in Python we have parameters (let's say: only for input), neatly
> separated from 'output' values which don't get-a-mention until the
> return statement
> (see also "typing" - although the "return" might be considerably
> separated from the "->").
>

Re: Questioning the effects of multiple assignment

[Kyle Stanley]

>
> Can you explain why these two (apparently) logical assignment processes
> have been designed to realise different result-objects?


The reason is because of the conventions chosen in PEP 3132, which
implemented the feature in the first place. It was considered to return a
tuple for the consistency w/ *args that you initially expected, but the
author offered the following reasoning:

> Make the starred target a tuple instead of a list. This would be
consistent with a function's *args, but make further processing of the
result harder.

So, it was essentially a practicality > purity situation, where it was
considered to be more useful to be able to easily transform the result
rather than being consistent with *args. If it resulted in a tuple, it
would be immutable; this IMO makes sense for *args, but not necessarily for
* unpacking in assignments. The syntax is highly similar, but they are used
for rather different purposes. That being said, I can certainly understand
how the behavior is surprising at first.

There's a bit more details in the mailing list discussion that started the
PEP, see https://mail.python.org/pipermail/python-3000/2007-May/007300.html.


On Tue, Jul 7, 2020 at 2:04 AM dn via Python-list 
wrote:

> TLDR; if you are a Python 'Master' then feel free to skim the first part
> (which you should know hands-down), until the excerpts from 'the manual'
> and from there I'll be interested in learning from you...
>
>
> Yesterday I asked a junior prog to expand an __init__() to accept either
> a series of (>1) scalars (as it does now), or to take similar values but
> presented as a tuple. He was a bit concerned that I didn't want to
> introduce a (separate) keyword-argument, until 'we' remembered
> starred-parameters. He then set about experimenting. Here's a dichotomy
> that surfaced as part of our 'play':-
> (my problem is: I can't (reasonably) answer his question...)
>
>
> If you read this code:
> NB The print-ing does not follow the input-sequence, because that's the
> point to be made...
>
>  >>> def f( a, *b, c=0 ):
> ... print( a, type( a ) )
> ... print( c, type( c ) )
> ... print( b )
> ...
>  >>> f( 1, 'two', 3, 'four' )
>
> [I had to force "c" to become a keyword argument, but other than that,
> we'll be using these three parameters and four argument-values, again]
>
>
> Question 1: did you correctly predict the output?
>
> 1 
> 0 
> ('two', 3, 'four')
>
> Ahah, "c" went to default because there was no way to identify when the
> "*b" 'stopped' and "c" started - so all the values 'went' to become "b"
> (were all "consumed by"...).
>
> Why did I also print "b" differently?
> Building tension!
> Please read on, gentle reader...
>
>
> Let's make two small changes:
> - amend the last line of the function to be similar:
> ... print( b, type( b ) )
> - make proper use of the function's API:
>  >>> f( 1, 'two', 3, c='four' )
>
>
> Question 2: can you predict the output of "a"? Well duh!
> (same as before)
>
> 1 
>
>
> Question 3: has your predicted output of "c" changed? Yes? Good!
> (Web.Refs below, explain; should you wish...)
>
> four 
>
>
> Question 4: can you correctly predict the content of "b" and its type?
>
> ('two', 3) 
>
> That makes sense, doesn't it? The arguments were presented to the
> function as a tuple, and those not assigned to a scalar value ("a" and
> "c") were kept as a tuple when assigned to "b".
> Jolly good show, chaps!
>
> (which made my young(er) colleague very happy, because now he could see
> that by checking the length of the parameter, such would reveal if the
> arguments were being passed as scalars or as a tuple.
>
> Aside: however, it made me think how handy it would be if the
> newly-drafted PEP 622 -- Structural Pattern Matching were available
> today (proposed for v3.10, https://www.python.org/dev/peps/pep-0622/)
> because (YAGNI-aside) we could then more-easily empower the API to
> accept other/more collections!
>
>
> Why am I writing then?
>
> Because during the same conversations I was
> 'demonstrating'/training/playing with some code that is (apparently)
> very similar - and yet, it's not. Oops!
>
>
> Sticking with the same, toy-data, let's code:
>
>  >>> a, *b, c = 1, 'two', 3, 'four'
>  >>> a, type( a )
>  >>> c, type( c )
>  >>> b, type( b )
>
>
> Question 5: what do you expect "a" and "c" to deliver in this context?
>
> (1, )
> ('four', )
>
> Happy so far?
>
>
> Question 6: (for maximum effect, re-read snippets from above, then) what
> do you expect from "b"?
>
> (['two', 3], )
>
> List? A list? What's this "list" stuff???
> When "b" was a parameter (above) it was assigned a tuple!
>
>
> Are you as shocked as I?
> Have you learned something?
> (will it ever be useful?)
> Has the world stopped turning?
>
>
> Can you explain why these two (apparently) logical assignment processes
> have been designed to realise different result-objects?
>
>
> NB The list cf tuple difference is 'legal' - at least in the sense that
> it is