Re: Seeking deeper understanding of python equality (==)

[Jonathan Kaczynski]

Thank you for your response Eryk.

I did try using gdb in my original post, but using breakpoint() left me in
the python layer (pdb), not the cpython layer (gdb) and I couldn't figure
out how to drop down.

I see you're using the kernel32 library, so I assume you're on windows. I
only have a mac and getting gdb functional on a mac seems to be onerous (
https://gist.github.com/mike-myers-tob/9a6013124bad7ff074d3297db2c98247),
so I'm performing my testing on a linux container running ubuntu.

The closest equivalent to putting kernel32.DebugBreak() in front of the x
== y line in my test script is os.kill(os.getpid(), signal.SIGTRAP).
Though, this drops me into the signal handling code in the cpython layer,
and after several dozen steps I did not reach the richcompare-related
functions. I'll make another attempt later today.

Thanks to everyone's responses, I have a great idea of what's going on,
now. I appreciate you all.

My goal now is to be able to work with the debugger, like Erik is, so that
next time I am able to perform this investigation in-full. Should I create
a new thread for this question?

Thank you,
Jonathan



On Sat, May 14, 2022 at 1:51 PM Eryk Sun  wrote:

> On 5/14/22, Jonathan Kaczynski 
> wrote:
> >
> > So, I'm still wondering how Py_TYPE(v)->tp_richcompare resolves to __eq__
> > on a user-defined class. Conversely, my understanding is, for a type
> > defined in cpython, like str, there is usually an explicitly
> > defined tp_richcompare function.
>
> Sometimes it's simplest to directly examine an object using a native
> debugger (e.g. gdb in Linux; cdb/windbg in Windows).
>
> With a debugger attached to the interpreter, create two classes, one
> that doesn't override __eq__() and one that does:
>
> >>> class C:
> ... pass
> ...
> >>> class D:
> ... __eq__ = lambda s, o: False
> ...
>
> In CPython, the id() of an object is its address in memory:
>
> >>> hex(id(C))
> '0x2806a705790'
> >>> hex(id(D))
> '0x2806a6bbfe0'
>
> Break into the attached debugger to examine the class objects:
>
> >>> kernel32.DebugBreak()
>
> (1968.1958): Break instruction exception - code 8003 (first chance)
> KERNELBASE!wil::details::DebugBreak+0x2:
> 7ffd`8818fd12 cc  int 3
>
> Class C uses the default object_richcompare():
>
> 0:000> ?? *((python310!PyTypeObject *)0x2806a705790)->tp_richcompare
>  0x7ffd`55cac288
>  _object*  python310!object_richcompare+0(
> _object*,
> _object*,
> int)
>
> Class D uses slot_tp_richcompare():
>
> 0:000> ?? *((python310!PyTypeObject *)0x2806a6bbfe0)->tp_richcompare
>  0x7ffd`55cdef1c
>  _object*  python310!slot_tp_richcompare+0(
> _object*,
> _object*,
> int)
>
> Source code of slot_tp_richcompare():
>
>
> https://github.com/python/cpython/blob/v3.10.4/Objects/typeobject.c#L7610-L7626
>
-- 
https://mail.python.org/mailman/listinfo/python-list

Request for assistance (hopefully not OT)

[o1bigtenor]

Greetings

I was having space issues in my /usr directory so I deleted some
programs thinking that the space taken was more an issue than having
older versions of the program.

So one of the programs I deleted (using rm -r) was python3.9.
Python3.10 was already installed so I thought (naively!!!) that things
should continue working.
(Python 3.6, 3.7 and 3.8 were also part of this cleanup.)

So now I have problems.

Following is the system barf that I get when I run '# apt upgrade'.

What can I do to correct this self-inflicted problem?

(running on debian testing 5.17

Setting up python2.7-minimal (2.7.18-13.1) ...
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
/usr/bin/python2.7: can't open file
'/usr/lib/python2.7/py_compile.py': [Errno 2] No such file or
directory
dpkg: error processing package python2.7-minimal (--configure):
 installed python2.7-minimal package post-installation script
subprocess returned error exit status 2
Setting up python3.9-minimal (3.9.12-1) ...
update-binfmts: warning: /usr/share/binfmts/python3.9: no executable
/usr/bin/python3.9 found, but continuing anyway as you request
/var/lib/dpkg/info/python3.9-minimal.postinst: 51: /usr/bin/python3.9: not found
dpkg: error processing package python3.9-minimal (--configure):
 installed python3.9-minimal package post-installation script
subprocess returned error exit status 127
dpkg: dependency problems prevent configuration of python3.9:
 python3.9 depends on python3.9-minimal (= 3.9.12-1); however:
  Package python3.9-minimal is not configured yet.

dpkg: error processing package python3.9 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python2.7:
 python2.7 depends on python2.7-minimal (= 2.7.18-13.1); however:
  Package python2.7-minimal is not configured yet.

dpkg: error processing package python2.7 (--configure):
 dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python3.9-dev:
 python3.9-dev depends on python3.9 (= 3.9.12-1); however:
  Package python3.9 is not configured yet.

dpkg: error processing package python3.9-dev (--configure):
 dependency problems - leaving unconfigured
. . .
Errors were encountered while processing:
 python2.7-minimal
 python3.9-minimal
 python3.9
 python2.7
 python3.9-dev
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for assistance (hopefully not OT)

[Martin Di Paola]

Try to reinstall python and only python and if you succeeds, then try to
reinstall the other tools.

For this, use "apt-get" instead of "apt"

$ sudo apt-get reinstall python3

When a system is heavily broken, be extra careful and read the output of
the programs. If "apt-get" says than in order to reinstall python it will have
to remove half of your computer, abort. Better ask than sorry.

Best of the lucks.

Martin.

On Tue, May 17, 2022 at 06:20:39AM -0500, o1bigtenor wrote:

Greetings

I was having space issues in my /usr directory so I deleted some
programs thinking that the space taken was more an issue than having
older versions of the program.

So one of the programs I deleted (using rm -r) was python3.9.
Python3.10 was already installed so I thought (naively!!!) that things
should continue working.
(Python 3.6, 3.7 and 3.8 were also part of this cleanup.)

So now I have problems.

Following is the system barf that I get when I run '# apt upgrade'.

What can I do to correct this self-inflicted problem?

(running on debian testing 5.17

Setting up python2.7-minimal (2.7.18-13.1) ...
Could not find platform independent libraries 
Could not find platform dependent libraries 
Consider setting $PYTHONHOME to [:]
/usr/bin/python2.7: can't open file
'/usr/lib/python2.7/py_compile.py': [Errno 2] No such file or
directory
dpkg: error processing package python2.7-minimal (--configure):
installed python2.7-minimal package post-installation script
subprocess returned error exit status 2
Setting up python3.9-minimal (3.9.12-1) ...
update-binfmts: warning: /usr/share/binfmts/python3.9: no executable
/usr/bin/python3.9 found, but continuing anyway as you request
/var/lib/dpkg/info/python3.9-minimal.postinst: 51: /usr/bin/python3.9: not found
dpkg: error processing package python3.9-minimal (--configure):
installed python3.9-minimal package post-installation script
subprocess returned error exit status 127
dpkg: dependency problems prevent configuration of python3.9:
python3.9 depends on python3.9-minimal (= 3.9.12-1); however:
 Package python3.9-minimal is not configured yet.

dpkg: error processing package python3.9 (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python2.7:
python2.7 depends on python2.7-minimal (= 2.7.18-13.1); however:
 Package python2.7-minimal is not configured yet.

dpkg: error processing package python2.7 (--configure):
dependency problems - leaving unconfigured
dpkg: dependency problems prevent configuration of python3.9-dev:
python3.9-dev depends on python3.9 (= 3.9.12-1); however:
 Package python3.9 is not configured yet.

dpkg: error processing package python3.9-dev (--configure):
dependency problems - leaving unconfigured
. . .
Errors were encountered while processing:
python2.7-minimal
python3.9-minimal
python3.9
python2.7
python3.9-dev
--
https://mail.python.org/mailman/listinfo/python-list

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

Re: Request for assistance (hopefully not OT)

[Chris Angelico]

On Tue, 17 May 2022 at 21:22, o1bigtenor  wrote:
>
> Greetings
>
> I was having space issues in my /usr directory so I deleted some
> programs thinking that the space taken was more an issue than having
> older versions of the program.
>
> So one of the programs I deleted (using rm -r) was python3.9.
> Python3.10 was already installed so I thought (naively!!!) that things
> should continue working.
> (Python 3.6, 3.7 and 3.8 were also part of this cleanup.)

Did you install Python 3.9 using apt? If so, you should definitely
have removed it using apt - if for no reason than to find out if
something's depending on it.

Generally, Linux systems have just one "system Python" that other
applications depend on. Any other installed version is completely
independent.

> So now I have problems.
>
> Following is the system barf that I get when I run '# apt upgrade'.
>
> What can I do to correct this self-inflicted problem?
>
> (running on debian testing 5.17

I presume 5.17 is the Linux kernel version? Depending on how
up-to-date your Debian Testing is, that should theoretically mean that
the system Python is 3.10, which would imply that it should have been
safe to remove 3.9... but only if you had done it with apt.

> Setting up python2.7-minimal (2.7.18-13.1) ...
> Could not find platform independent libraries 
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> /usr/bin/python2.7: can't open file
> '/usr/lib/python2.7/py_compile.py': [Errno 2] No such file or
> directory

Did you also use rm to get rid of Python 2.7?

> dpkg: error processing package python2.7-minimal (--configure):
>  installed python2.7-minimal package post-installation script
> subprocess returned error exit status 2
> Setting up python3.9-minimal (3.9.12-1) ...
> update-binfmts: warning: /usr/share/binfmts/python3.9: no executable
> /usr/bin/python3.9 found, but continuing anyway as you request
> /var/lib/dpkg/info/python3.9-minimal.postinst: 51: /usr/bin/python3.9: not 
> found
> dpkg: error processing package python3.9-minimal (--configure):
>  installed python3.9-minimal package post-installation script
> subprocess returned error exit status 127
> dpkg: dependency problems prevent configuration of python3.9:
>  python3.9 depends on python3.9-minimal (= 3.9.12-1); however:
>   Package python3.9-minimal is not configured yet.
>
> dpkg: error processing package python3.9 (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of python2.7:
>  python2.7 depends on python2.7-minimal (= 2.7.18-13.1); however:
>   Package python2.7-minimal is not configured yet.
>
> dpkg: error processing package python2.7 (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of python3.9-dev:
>  python3.9-dev depends on python3.9 (= 3.9.12-1); however:
>   Package python3.9 is not configured yet.
>
> dpkg: error processing package python3.9-dev (--configure):
>  dependency problems - leaving unconfigured
> . . .
> Errors were encountered while processing:
>  python2.7-minimal
>  python3.9-minimal
>  python3.9
>  python2.7
>  python3.9-dev

So, yeah, you're definitely going to need to reinstate some parts of
Python to get this going.

If you can figure out which exact Python versions you need, it might
be possible to restore them manually. Download the packages from
packages.debian.org, then try to manually install them with dpkg, and
if that fails, unpack them and put the files into the right places.

It's going to be a pain. A lot of pain. And next time, use apt to
uninstall what apt installed :)

Something else to consider, though: It might not be Python that's
taking up all the space. On my system, /usr is dominated by /usr/lib
and /usr/local/lib, and while it might look like the pythonx.y
directories there are the large part, it's actually not Python itself
that's so big: it's other libraries, installed using either apt or
pip. So when you're trying to free up space, look to see whether you
have packages installed into every version of Python you have; the
largest directories in my python3.9/site-packages are scipy, plotly,
numpy, pandas, speech_recognition, matplotlib, and Cython - all great
tools, but if you have a copy for 3.9, a copy for 3.10, a copy for
3.11, etc, it adds up fast.

"Ten minutes with a hacksaw will save you thirty with a shovel"
-- Miss Pauling, discussing the art of uninstalling something

ChrisA
-- 
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

[Peter J. Holzer]

On 2022-05-16 20:48:02 -0400, Dennis Lee Bieber wrote:
> On Mon, 16 May 2022 17:22:17 -0700 (PDT), "hongy...@gmail.com"
>  declaimed the following:
> >a=re.sub(r"'","",a)
> 
>   Explain what you believe this operation is doing, show us the input and
> the output.
> 
>   The best I can make out of that is that it is looking for single quote
> characters within whatever "a" is, and replacing them with nothing.
> Something much more understandable, without invoking a regular expression
> library (especially when neither the search nor the replacement terms are
> regular expressions) with simple string operations...
> 
>   stripped = "".join(quoted.split("'"))

Whether that's easier to understand it very much in the eye of the
beholder.

hp

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


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

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

[MRAB]

On 2022-05-17 16:21, Peter J. Holzer wrote:

On 2022-05-16 20:48:02 -0400, Dennis Lee Bieber wrote:

On Mon, 16 May 2022 17:22:17 -0700 (PDT), "hongy...@gmail.com"
 declaimed the following:
>a=re.sub(r"'","",a)

Explain what you believe this operation is doing, show us the input and
the output.

The best I can make out of that is that it is looking for single quote
characters within whatever "a" is, and replacing them with nothing.
Something much more understandable, without invoking a regular expression
library (especially when neither the search nor the replacement terms are
regular expressions) with simple string operations...

stripped = "".join(quoted.split("'"))


Whether that's easier to understand it very much in the eye of the
beholder.

As it's just a simple replacement, I would've thought that the 'obvious' 
solution would be:

a = a.replace("'", "")
--
https://mail.python.org/mailman/listinfo/python-list

[RELEASE] Python 3.9.13 is now available

[Łukasz Langa]

This is the thirteenth maintenance release of Python 3.9. Get it here:
Python 3.9.13 
According to the release calendar specified in PEP 596 
, Python 3.9.13 is the final regular 
maintenance release. Starting now, the 3.9 branch will only accept security 
fixes and releases of those will be made in source-only form until October 2025.

This is a milestone moment for me as it means that now both of my release 
series are security-only. My work as release manager enters its final stage. 
I’m not crying, you’re crying! 🥲

Compared to the 3.8 series, this last regular bugfix release is still pretty 
active at 166 commits since 3.9.12. In comparison, version 3.8.10, the final 
regular bugfix release of Python 3.8, included only 92 commits. However, it’s 
likely that it was 3.8 that was special here with the governance changes 
occupying core developers’ minds. For reference, version 3.7.8, the final 
regular bugfix release of Python 3.7, included 187 commits.

In any case, 166 commits is quite a few changes, some of which being pretty 
important fixes. Take a look at the change log 
 for details.

 
Major
 new features of the 3.9 series, compared to 3.8

Some of the new major new features and changes in Python 3.9 are:

PEP 573 , Module State Access from C 
Extension Methods
PEP 584 , Union Operators in dict
PEP 585 , Type Hinting Generics In 
Standard Collections
PEP 593 , Flexible function and 
variable annotations
PEP 602 , Python adopts a stable 
annual release cadence
PEP 614 , Relaxing Grammar 
Restrictions On Decorators
PEP 615 , Support for the IANA Time 
Zone Database in the Standard Library
PEP 616 , String methods to remove 
prefixes and suffixes
PEP 617 , New PEG parser for CPython
BPO 38379 , garbage collection does not 
block on resurrected objects;
BPO 38692 , os.pidfd_open added that allows 
process management without races and signals;
BPO 39926 , Unicode support updated to 
version 13.0.0;
BPO 1635741 , when Python is initialized 
multiple times in the same process, it does not leak memory anymore;
A number of Python builtins (range, tuple, set, frozenset, list, dict) are now 
sped up using PEP 590  vectorcall;
A number of Python modules (_abc, audioop, _bz2, _codecs, _contextvars, _crypt, 
_functools, _json, _locale, operator, resource, time, _weakref) now use 
multiphase initialization as defined by PEP 489 
;
A number of standard library modules (audioop, ast, grp, _hashlib, pwd, 
_posixsubprocess, random, select, struct, termios, zlib) are now using the 
stable ABI defined by PEP 384 .
You can find a more comprehensive list in this release’s “What’s New 
” document.

 
We
 hope you enjoy Python 3.9!

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

Your friendly release team,
Ned Deily @nad 
Steve Dower @steve.dower 
Łukasz Langa @ambv 


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

Re: Request for assistance (hopefully not OT)

[Loris Bennett]

o1bigtenor  writes:

> Greetings
>
> I was having space issues in my /usr directory so I deleted some
> programs thinking that the space taken was more an issue than having
> older versions of the program.
>
> So one of the programs I deleted (using rm -r) was python3.9.

Deleting anything from /usr via 'rm -r' which was installed via the
package manager is an extremely bad idea.  If you want to remove stuff,
use the package manager.
 
> Python3.10 was already installed so I thought (naively!!!) that things
> should continue working.
> (Python 3.6, 3.7 and 3.8 were also part of this cleanup.)

Python 3.10 may be installed, but a significant number of packages
depend on Python 3.9.  That's why you should use the package manager -
it knows all about the dependencies.

> So now I have problems.

I think you had a problem before that.  Debian testing is not an
operating system you should be using if you have a fairly good
understanding of how Debian (or Linux in general) works.

> Following is the system barf that I get when I run '# apt upgrade'.
>
> What can I do to correct this self-inflicted problem?
>
> (running on debian testing 5.17

I think you mean just 'Debian testing', which is what will become the
next version of Debian, i.e. Debian 12.  The '5.17' is just the kernel
version, not a version of Debian. 

> Setting up python2.7-minimal (2.7.18-13.1) ...
> Could not find platform independent libraries 
> Could not find platform dependent libraries 
> Consider setting $PYTHONHOME to [:]
> /usr/bin/python2.7: can't open file
> '/usr/lib/python2.7/py_compile.py': [Errno 2] No such file or
> directory
> dpkg: error processing package python2.7-minimal (--configure):
>  installed python2.7-minimal package post-installation script
> subprocess returned error exit status 2
> Setting up python3.9-minimal (3.9.12-1) ...
> update-binfmts: warning: /usr/share/binfmts/python3.9: no executable
> /usr/bin/python3.9 found, but continuing anyway as you request
> /var/lib/dpkg/info/python3.9-minimal.postinst: 51: /usr/bin/python3.9: not 
> found
> dpkg: error processing package python3.9-minimal (--configure):
>  installed python3.9-minimal package post-installation script
> subprocess returned error exit status 127
> dpkg: dependency problems prevent configuration of python3.9:
>  python3.9 depends on python3.9-minimal (= 3.9.12-1); however:
>   Package python3.9-minimal is not configured yet.
>
> dpkg: error processing package python3.9 (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of python2.7:
>  python2.7 depends on python2.7-minimal (= 2.7.18-13.1); however:
>   Package python2.7-minimal is not configured yet.
>
> dpkg: error processing package python2.7 (--configure):
>  dependency problems - leaving unconfigured
> dpkg: dependency problems prevent configuration of python3.9-dev:
>  python3.9-dev depends on python3.9 (= 3.9.12-1); however:
>   Package python3.9 is not configured yet.
>
> dpkg: error processing package python3.9-dev (--configure):
>  dependency problems - leaving unconfigured
> . . .
> Errors were encountered while processing:
>  python2.7-minimal
>  python3.9-minimal
>  python3.9
>  python2.7
>  python3.9-dev

It might be possible to fix the system.  If will probably be fairly
difficult, but you would probably learn a lot doing it.  However, if I
were you, I would just install Debian stable over your borked system and
then learn a bit more about package management.

Cheers,

Loris

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for assistance (hopefully not OT)

[Loris Bennett]

[snip (26 lines)]

> I think you had a problem before that.  Debian testing is not an
> operating system you should be using if you have a fairly good
> understanding of how Debian (or Linux in general) works.

Should be

  I think you had a problem before that.  Debian testing is not an
  operating system you should be using *unless* you have a fairly good
  understanding of how Debian (or Linux in general) works.

[snip (62 lines)]

-- 
This signature is currently under construction.
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: Request for assistance (hopefully not OT)

[Grant Edwards]

On 2022-05-17, Loris Bennett  wrote:

> It might be possible to fix the system.  If will probably be fairly
> difficult, but you would probably learn a lot doing it.  However, if I
> were you, I would just install Debian stable over your borked system and
> then learn a bit more about package management.

Other then reinstalling, the easiest way to fix a broken system like
that requires access to a similarly configured system that isn't
broken. Find one of those, and start copying binaries from the working
system to the broken system. At some point, the broken system should
start to work well enough that you can re-install the packages you
broke by removing files behind the back of the package manager.

Whether that's going to be faster/easier than backing up your
configuration and data files and reinstalling Debian is another
question. My guess is that reinstalling would probably be faster.

FWIW, this is indeed off-topic for this group. It isn't a really
Python question, it's a Debian question.

--
Grant


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

Re: Request for assistance (hopefully not OT)

[Chris Angelico]

On Wed, 18 May 2022 at 04:05, Loris Bennett  wrote:
> > So now I have problems.
>
> I think you had a problem before that.  Debian testing is not an
> operating system you should be using if you have a fairly good
> understanding of how Debian (or Linux in general) works.

I take issue with that! Debian Testing is a perfectly viable operating
system! I wouldn't use it on a server, but it's perfectly fine to use
it on a personal machine. You can generally consider Debian Testing to
be broadly as stable as Ubuntu non-LTS releases, although in my
opinion, it's actually quite a bit more dependable than them.

(Perhaps you're thinking of Debian Unstable?)

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

Re: Request for assistance (hopefully not OT)

[Chris Angelico]

On Wed, 18 May 2022 at 04:05, Loris Bennett  wrote:
>
> [snip (26 lines)]
>
> > I think you had a problem before that.  Debian testing is not an
> > operating system you should be using if you have a fairly good
> > understanding of how Debian (or Linux in general) works.
>
> Should be
>
>   I think you had a problem before that.  Debian testing is not an
>   operating system you should be using *unless* you have a fairly good
>   understanding of how Debian (or Linux in general) works.
>
> [snip (62 lines)]
>

Oh! My bad, didn't see this correction, sorry. With this adjustment,
the comment is a bit more reasonable, although I'd still say it's
generally fine to run Debian Testing on a personal desktop machine;
there are a number of distros that base themselves on Testing.

But yes, "unless" makes much more sense there.

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

Re: Request for assistance (hopefully not OT)

[Michael Torrie]

On 5/17/22 05:20, o1bigtenor wrote:
> What can I do to correct this self-inflicted problem?

Those are always the fun ones.  Reminds me of when I was first learning
Linux using Red Hat Linux 5.0 or 5.1.  This was long before nice
dependency-solving tools like apt.  I wanted to install and run
StarOffice, but it needed a newer libc (this was during the painful
transition from libc5 to glibc6).  I ended up removing libc which
*everything depends on, trying to get the glibc update installed.
Needless to say that broke the entire system. Nothing but a reinstall
could be done in those days.

Anyway, good luck. I think you can rescue it yet following the advice
others have given.
-- 
https://mail.python.org/mailman/listinfo/python-list