Python 3.13.0a3 is now available.

[Thomas Wouters via Python-list]

We silently skipped releasing in December (it was too close to the
holidays, a lot of people were away) so by date you may have been expecting
alpha 4, but instead it’s alpha 3:
https://www.python.org/downloads/release/python-3130a3/

*This is an early developer preview of Python 3.13*
Major
new features of the 3.13 series, compared to 3.12

Python 3.13 is still in development. This release, 3.13.0a3, is the third
of six planned alpha releases.

Alpha releases are intended to make it easier to test the current state of
new features and bug fixes and to test the release process.

During the alpha phase, features may be added up until the start of the
beta phase (2024-05-07) and, if necessary, may be modified or deleted up
until the release candidate phase (2024-07-30). Please keep in mind that
this is a preview release and its use is *not* recommended for production
environments.

Many new features for Python 3.13 are still being planned and written. Work
continues apace on both the work to remove the Global Interpeter Lock
, and to improve Python performance. The
most notable changes so far:

   - In the interactive interpreter, exception tracebacks are now colorized
   by default
   .
   - Docstrings now have their leading indentation stripped
   ,
   reducing memory use and the size of .pyc files. (Most tools handling
   docstrings already strip leading indentation.)
   - PEP 594 (Removing dead batteries from the standard library)
    scheduled removals of many
   deprecated modules: aifc, audioop, chunk, cgi, cgitb, crypt, imghdr,
   mailcap, msilib, nis, nntplib, ossaudiodev, pipes, sndhdr, spwd, sunau,
   telnetlib, uu, xdrlib, lib2to3.
   - Many other removals
    of deprecated
   classes, functions and methods in various standard library modules.
   - New deprecations
   , most of
   which are scheduled for removal from Python 3.15 or 3.16.
   - C API removals 
   and deprecations .
   (Some removals present in alpha 1 have been reverted in alpha 2, as the
   removals were deemed too disruptive at this time.)

(Hey, *fellow core developer,* if a feature you find important is missing
from this list, let Thomas know .)

The next pre-release of Python 3.13 will be 3.13.0a4, currently scheduled
for 2023-02-13.
More
resources

   - Online Documentation 
   - PEP 719 , 3.13 Release
   Schedule
   - Report bugs at Issues · python/cpython · GitHub
   .
   - Help fund Python and its community
   .

Enjoy
the new releases

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.

Regards from snowy Amsterdam,

Your release team,
Thomas Wouters
Ned Deily
Steve Dower
Łukasz Langa
-- 
Thomas Wouters 
-- 
https://mail.python.org/mailman/listinfo/python-list

Re: PyTorch

[Mats Wichmann via Python-list]

On 1/17/24 09:48, Alan Zaharia via Python-list wrote:

Hello Python

I Need help. it could not be found for PyTorch. It said in the Command Prompt 
ERROR: Could not find a version that satisfies the requirement torch (from 
versions: none)
ERROR: No matching distribution found for torch,  Can you help me?


Use Python 3.11.


Or follow here:

https://github.com/pytorch/pytorch/issues/110436

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

Re: Python 3.12.1, Windows 11: shebang line #!/usr/bin/env python3 doesn't work any more

[Mats Wichmann via Python-list]

On 1/16/24 10:00, Sibylle Koczian via Python-list wrote:

Am 15.01.2024 um 23:55 schrieb Mats Wichmann via Python-list:

On 1/15/24 12:01, Thomas Passin via Python-list wrote:

On 1/15/2024 1:26 PM, Mats Wichmann via Python-list wrote:
Python from the App Store is not the same as Python from python.org:


yes. this question is about the python.org distribution. but, Windows 
natively has something called python.exe and python3.exe which is 
interfering here, IF the python.org install isn't directed to put 
itself into the path, AND if the "#!/usr/bin/env python3" form is 
used, causing a search in PATH, which is the setup Sibylle has 
described, unless I've misunderstood details.




No, you didn't misunderstand any detail. It's exactly right. My Windows 
10 box doesn't find anything for "where python", "where python3",


Be interesting to know if your WIndows 10 has those files in place, and 
it's just a missing path entry (a good thing, perhaps) that's causing it 
not to be found there.


while the new Windows 11 machine finds the Microsoft stub. "Irritating" is a 
very friendly attribute for that thing. Why must it be called 
"python.exe" and not something else like the installation files from 
python.org?


it will be replaced by the real "python.exe" from the Microsoft Store 
install, if you go ahead and install that - I guess that's why that name 
was chosen.


I'll stop using "/env" - hopefully that won't create problems with the 
scripts I use in the Linux VM. But in that case I'll know what's up.


Thank you very much!
Sibylle




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

Re: Question about garbage collection

[Left Right via Python-list]

So, here's some info about how to see what's going on with Python's
memory allocation: https://docs.python.org/3/library/tracemalloc.html
. I haven't looked into this in a long time, but it used to be the
case that you needed to compile native modules (and probably Python
itself?) so that instrumentation is possible (I think incref / decref
macros should give you a hint, because they would have to naturally
report some of that info).

Anyways.  The problem of tracing memory allocation / deallocation in
Python can be roughly split into these categories:

1. Memory legitimately claimed by objects created through Python
runtime, but not reclaimed due to programmer error. I.e. the
programmer wrote a program that keeps references to objects which it
will never use again.
2. Memory claimed through native objects obtained by means of
interacting with Python's allocator.  When working with Python C API
it's best to interface with Python allocator to deal with dynamic
memory allocation and release.  However, it's somewhat cumbersome, and
some module authors simply might not know about it, or wouldn't want
to use it because they prefer a different allocator.  Sometimes
library authors don't implement memory deallocation well.  Which
brings us to:
3. Memory claimed by any user-space code that is associated with the
Python process. This can be for example shared libraries loaded by
means of Python bindings, that is on top of the situation described
above.
4. System memory associated with the process.  Some system calls need
to allocate memory on the system side.  Typical examples are opening
files, creating sockets etc.  Typically, the system will limit the
number of such objects, and the user program will hit the numerical
limit before it hits the memory limit, but it can also happen that
this will manifest as a memory problem (one example I ran into was
trying to run conda-build and it would fail due to enormous amounts of
memory it requested, but the specifics of the failure were due to it
trying to create new sub-processes -- another system resource that
requires memory allocation).

There isn't a universal strategy to cover all these cases.  But, if
you have reasons to suspect (4), for example, you'd probably start by
using strace utility (on Linux) to see what system calls are executed.

For something like the (3), you could try to utilize Valgrind (but
it's a lot of work to set it up).  It's also possible to use jemalloc
to profile a program, but you would have to build Python with its
allocator modified to use jemalloc (I've seen an issue in the Python
bug tracker where someone wrote a script to do that, so it should be
possible).  Both of these are quite labor intensive and not trivial to
set up.

(2) could be often diagnosed with tracemalloc Python module and (1) is
something that can be helped with Python's gc module.

It's always better though to have an actual error and work from there.
Or, at least, have some monitoring data that suggests that your
application memory use increases over time.  Otherwise you could be
spending a lot of time chasing problems you don't have.
-- 
https://mail.python.org/mailman/listinfo/python-list

PyTorch

[Alan Zaharia via Python-list]

Hello Python

I Need help. it could not be found for PyTorch. It said in the Command Prompt 
ERROR: Could not find a version that satisfies the requirement torch (from 
versions: none)
ERROR: No matching distribution found for torch,  Can you help me?

Thank You,

Best,
Alan.
-- 
https://mail.python.org/mailman/listinfo/python-list