[RELEASE] Python 3.13.9 is now available

[Thomas Wouters]

Python 3.13.9 is now available.

https://www.python.org/downloads/release/python-3139/

3.13.9 is an expedited release containing a fix for one specific regression in 
Python 3.13.8:
 • gh-139783 : Fix 
`inspect.getsourcelines` for the case when a decorator is followed by a comment 
or an empty line.
There are no other changes in this release, compared to 3.13.8.

Enjoy the new release!
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Proposal to update Unicode handling for German sharp S (ß / ẞ) in Python’s case conversion methods

[Mashaal Al Hammdi via Python-list]

Hello friends,
Can I know what’s going on?! Please

في سبت، 18 أكتوبر، 2025 في 7:11 ص، كتب Chris Angelico via Python-list <
python-list@python.org>:

> On Sat, 18 Oct 2025 at 13:44,  wrote:
> >
> > Dear Python Developers,
> >
> > I would like to bring attention to an inconsistency and legacy behavior
> regarding the handling of the German sharp S characters in Python’s string
> case conversion methods.
> >
>
> This isn't Python's decision. The definition of Unicode case
> conversion is laid out in the Unicode standard; for U+00DF, you can
> find it in this page:
>
> https://www.unicode.org/charts/PDF/U0080.pdf
>
> > This would help align Python with current Unicode standards
>
> Do you have a reference for this? Is there a current Unicode standard
> that stipulates that U+00DF should be uppercased to U+1E9E?
>
> ChrisA
> --
> https://mail.python.org/mailman3//lists/python-list.python.org
>
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Slices by length

[Rob Cliffe via Python-list]

On 06/09/2025 17:21, MRAB wrote:

On 2025-09-06 13:47, Rob Cliffe via Python-list wrote:

I quite often find myself writing expressions of the form
      someString[x : x+n]
where n is often an int and x may be an int, a variable, or a (possibly
complicated) expression.
It would be more natural to be able to specify the slice not by its
startpoint and ENDPOINT,
but by its startpoint and LENGTH, particularly when x is a long
expression and has to be repeated or pre-stored in a variable.
I have worked with languages that had this facility, and I miss it.
The possible syntaxes are restricted by the need to avoid ambiguity with
existing valid code.
It could be for example
      someString[x ! n]
(of course, x and n could be arbitrary expressions).
One point to be decided would be whether negative n would produce
      (a) an empty string, so that s[x ! n] was always the same as s[x :
x+n]
      (b) a slice ending at x, e.g. "01234567"[4!-3] would equal "123"
(or less plausibly "321").
I don't have a strong opinion on this; there may be good reasons for
preferring one to another.
Does anybody think this is a good idea?


I'm not happy about the syntax.
How about `someString[x +: n]`?
Yes thank you, I think that's a great improvement, and of course it's 
currently not legal syntax.

Best wishes
Rob Cliffe



As for a negaitve length, it should probably return an empty string 
given that `someString[x : x+n]` returns an empty string if `n` is 
negative.


The syntax would leave open the possibility of adding `someString[x -: 
n]` in the future for option b.


On a related note, a quick search revealed that the D programming 
language lets you write `someString[x .. $]` where `$` in that context 
is the length. That lets you write `someString[x .. $ - n]`. In Python 
that could be `someString[x : $ - n]`, equivalent to `someString[x : 
len(someString) - n]`, even if `n` is 0.


--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Proposal to update Unicode handling for German sharp S (ß / ẞ) in Python’s case conversion methods

[python]

Thanks Chris for the response!

As The Unicode Standard does define an uppercase form for the German sharp S 
(U+00DF → U+1E9E), and this has been part of Unicode since version 5.1 (2008), 
with the German orthography officially adopting it in 2017. The relevant case 
mappings are clearly specified in the Unicode Character Database 
(CaseFolding.txt / SpecialCasing.txt), so Unicode itself does recognize this 
direct uppercase/lowercase relationship.

The current Python behavior (mapping "ß" → "SS") reflects older, legacy Unicode 
data — not the current standard. Languages and libraries that have updated 
their Unicode handling (like Java ≥9, ICU, Swift, etc.) already perform this 
mapping correctly ("ß".upper() → "ẞ").

So this isn’t an issue with Unicode, but rather that Python’s internal Unicode 
case conversion logic hasn’t yet been updated to reflect the more modern and 
officially standardized mapping.

In other words, this is something Python could and probably should modernize — 
aligning with Unicode’s current case conversion tables and modern German 
orthography.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Proposal to update Unicode handling for German sharp S (ß / ẞ) in Python’s case conversion methods

[Chris Angelico via Python-list]

On Sun, 19 Oct 2025 at 11:03,  wrote:
>
> Thanks Chris for the response!
>
> As The Unicode Standard does define an uppercase form for the German sharp S 
> (U+00DF → U+1E9E), and this has been part of Unicode since version 5.1 
> (2008), with the German orthography officially adopting it in 2017. The 
> relevant case mappings are clearly specified in the Unicode Character 
> Database (CaseFolding.txt / SpecialCasing.txt), so Unicode itself does 
> recognize this direct uppercase/lowercase relationship.
>
> The current Python behavior (mapping "ß" → "SS") reflects older, legacy 
> Unicode data — not the current standard. Languages and libraries that have 
> updated their Unicode handling (like Java ≥9, ICU, Swift, etc.) already 
> perform this mapping correctly ("ß".upper() → "ẞ").
>

The character has indeed been a part of Unicode for a long time. But
version 17 of Unicode still specifies the same behaviour:

https://www.unicode.org/Public/17.0.0/ucd/CaseFolding.txt

00DF; F; 0073 0073; # LATIN SMALL LETTER SHARP S

This isn't just older Unicode data, it's also the current standard.

Are you sure that other languages behave this way, or did an AI
generate this email for you?

ChrisA
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python 3.14.0 (final) is here!

[Ed Leafe via Python-list]

On Oct 7, 2025, at 13:14, Abdur-Rahmaan Janhangeer via Python-list 
 wrote:
> 
> Very sad ... At least as Steve Dower suggested even if we could get an
> email from Discourse or something.

I too will miss these announcements. I understand not having to post things to 
multiple places, but forwarding an email to this list would be greatly 
appreciated.


-- Ed Leafe

-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Python 3.14.0 (final) is here!

[Hugo van Kemenade via Python-list]

Note: we also announce CPython releases at
https://discuss.python.org/tag/release and https://blog.python.org, and
are planning on only announcing at those places in the future, and not on
this mailing list. See
https://discuss.python.org/t/cpython-release-announcements/103924/1

Please see https://discuss.python.org/t/python-3-14-0-final-is-here/104210
for the 3.14.0 release notes.

Regards from a colourful autumnal Helsinki,

Your release team,
Hugo van Kemenade
Ned Deily
Steve Dower
Łukasz Langa
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Python 3.14.0 (final) is here!

[Karsten Hilbert via Python-list]

Am Wed, Oct 08, 2025 at 10:51:42AM +0200 schrieb Jean-François Bachelet via 
Python-list:

> at least a mailing list is way more frugal. and internet friendly.

And above all, PUSH rather than PULL.

Karsten
-- 
GPG  40BE 5B0E C98E 1713 AFA6  5BC0 3BEA AC80 7D4F C89B
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Slices by length

[Richard Damon]

Sent from my iPad

> On Oct 7, 2025, at 9:59 PM, Rob Cliffe via Python-list 
>  wrote:
> 
> In fairness, it is already possible to write
>  s[x:][:n]
> which gives the "right" answer if n is non-negative, and is quite readable,
> although this is slower than s[x:x+2], at least in tests that I did (and, I 
> would hazard a guess, always).
> Best wishes
> Rob Cliffe
> 

Which brings to mind a possible alternate syntax: s[x::n]
Won’t say I think it is good enough to say that is how it should be, just 
throwing a new hat in the ring.
-- 
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Slices by length

[MRAB]

On 08/10/2025 03:21, Richard Damon wrote:

Sent from my iPad


On Oct 7, 2025, at 9:59 PM, Rob Cliffe via Python-list  
wrote:

In fairness, it is already possible to write
  s[x:][:n]
which gives the "right" answer if n is non-negative, and is quite readable,
although this is slower than s[x:x+2], at least in tests that I did (and, I 
would hazard a guess, always).
Best wishes
Rob Cliffe


Which brings to mind a possible alternate syntax: s[x::n]
Won’t say I think it is good enough to say that is how it should be, just 
throwing a new hat in the ring.

That syntax already exists.
--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Slices by length

[Thomas Passin]

On 10/7/2025 2:49 PM, Rob Cliffe via Python-list wrote:



On 06/09/2025 17:21, MRAB wrote:

On 2025-09-06 13:47, Rob Cliffe via Python-list wrote:

I quite often find myself writing expressions of the form
      someString[x : x+n]
where n is often an int and x may be an int, a variable, or a (possibly
complicated) expression.
It would be more natural to be able to specify the slice not by its
startpoint and ENDPOINT,
but by its startpoint and LENGTH, particularly when x is a long
expression and has to be repeated or pre-stored in a variable.
I have worked with languages that had this facility, and I miss it.
The possible syntaxes are restricted by the need to avoid ambiguity with
existing valid code.
It could be for example
      someString[x ! n]
(of course, x and n could be arbitrary expressions).
One point to be decided would be whether negative n would produce
      (a) an empty string, so that s[x ! n] was always the same as s[x :
x+n]
      (b) a slice ending at x, e.g. "01234567"[4!-3] would equal "123"
(or less plausibly "321").
I don't have a strong opinion on this; there may be good reasons for
preferring one to another.
Does anybody think this is a good idea?


I'm not happy about the syntax.
How about `someString[x +: n]`?
Yes thank you, I think that's a great improvement, and of course it's 
currently not legal syntax.

Best wishes
Rob Cliffe



As for a negaitve length, it should probably return an empty string 
given that `someString[x : x+n]` returns an empty string if `n` is 
negative.


The syntax would leave open the possibility of adding `someString[x -: 
n]` in the future for option b.


On a related note, a quick search revealed that the D programming 
language lets you write `someString[x .. $]` where `$` in that context 
is the length. That lets you write `someString[x .. $ - n]`. In Python 
that could be `someString[x : $ - n]`, equivalent to `someString[x : 
len(someString) - n]`, even if `n` is 0.


Since there are at least two options, (a) and (b), the proposed syntax 
is not obvious and intuitive. So it would add to the programmer's 
cognitive load for no or little benefit.  Let's not advocate for adding 
to cognitive load.


--
https://mail.python.org/mailman3//lists/python-list.python.org

Re: Slices by length

[Rob Cliffe via Python-list]

On 07/10/2025 20:37, Thomas Passin wrote:

On 10/7/2025 2:49 PM, Rob Cliffe via Python-list wrote:



On 06/09/2025 17:21, MRAB wrote:

On 2025-09-06 13:47, Rob Cliffe via Python-list wrote:

I quite often find myself writing expressions of the form
      someString[x : x+n]
where n is often an int and x may be an int, a variable, or a 
(possibly

complicated) expression.
It would be more natural to be able to specify the slice not by its
startpoint and ENDPOINT,
but by its startpoint and LENGTH, particularly when x is a long
expression and has to be repeated or pre-stored in a variable.
I have worked with languages that had this facility, and I miss it.
The possible syntaxes are restricted by the need to avoid ambiguity 
with

existing valid code.
It could be for example
      someString[x ! n]
(of course, x and n could be arbitrary expressions).
One point to be decided would be whether negative n would produce
      (a) an empty string, so that s[x ! n] was always the same as 
s[x :

x+n]
      (b) a slice ending at x, e.g. "01234567"[4!-3] would equal "123"
(or less plausibly "321").
I don't have a strong opinion on this; there may be good reasons for
preferring one to another.
Does anybody think this is a good idea?


I'm not happy about the syntax.
How about `someString[x +: n]`?
Yes thank you, I think that's a great improvement, and of course it's 
currently not legal syntax.

Best wishes
Rob Cliffe



As for a negaitve length, it should probably return an empty string 
given that `someString[x : x+n]` returns an empty string if `n` is 
negative.


The syntax would leave open the possibility of adding `someString[x 
-: n]` in the future for option b.


On a related note, a quick search revealed that the D programming 
language lets you write `someString[x .. $]` where `$` in that 
context is the length. That lets you write `someString[x .. $ - n]`. 
In Python that could be `someString[x : $ - n]`, equivalent to 
`someString[x : len(someString) - n]`, even if `n` is 0.


Since there are at least two options, (a) and (b), the proposed syntax 
is not obvious and intuitive. So it would add to the programmer's 
cognitive load for no or little benefit.  Let's not advocate for 
adding to cognitive load.



Thanks for your answer, but I don't really agree.
It may not be obvious now that we're all used to it, but there are also 
two possible meanings for "abcd"[1:-1].  Should it be "bc" (as it is), 
or an empty string?

As for cognitive load:
    (a) Someone may think of an even better syntax which makes it more 
intiuitive.

          Maybe s[x->n]   ?  I'd welcome more suggestions.
    (b) When the slice start is a conplicated expression and the slice 
length is very simple (like a literal int), this proposal would remove 
the need to either repeat the expression or first put it in a temporary 
variable, which may well improve readability.


In fairness, it is already possible to write
     s[x:][:n]
which gives the "right" answer if n is non-negative, and is quite readable,
although this is slower than s[x:x+2], at least in tests that I did 
(and, I would hazard a guess, always).

Best wishes
Rob Cliffe
--
https://mail.python.org/mailman3//lists/python-list.python.org