[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Sun, Nov 14, 2021 at 10:06 PM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > I'm not saying *Python* can't remove anything. I'm saying downstream, > *GNU Mailman* has users it *may* want to support. > So a project (not to pick on Mailman) may want to support its users running old

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sun, Nov 14, 2021 at 4:53 PM Steven D'Aprano wrote: > Out of all the approximately thousand bazillion ways to write obfuscated > Python code, which may or may not be malicious, why are Unicode > confusables worth this level of angst and concern? > I for one am not full of angst nor

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Christopher Barker writes: > On Sun, Nov 14, 2021 at 8:19 AM Stephen J. Turnbull < > stephenjturnb...@gmail.com> wrote: > > > > But do > > > we need to support running the same code on 3.5 to 3.10? > > > > Need? No. Want to not raise a big middle finger to our users? > > Note that I

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Mon, Nov 15, 2021 at 7:58 AM Victor Stinner wrote: > > On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith wrote: > > On second thought, I guess the existing policy already does this. Maybe > > we should make it more than 2 versions for deprecations? I've written > > libraries where I support 4 or

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Out of all the approximately thousand bazillion ways to write obfuscated Python code, which may or may not be malicious, why are Unicode confusables worth this level of angst and concern? I looked up "Unicode homoglyph" on CVE, and found a grand total of seven hits:

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Sun, Nov 14, 2021 at 6:34 PM Eric V. Smith wrote: > On second thought, I guess the existing policy already does this. Maybe > we should make it more than 2 versions for deprecations? I've written > libraries where I support 4 or 5 released versions. Although maybe I > should just trim that

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 11/14/21 2:36 PM, David Mertz, Ph.D. wrote: On Sun, Nov 14, 2021, 2:14 PM Christopher Barker It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL LETTER E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH ACUTE}", which are different

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sun, Nov 14, 2021, 2:14 PM Christopher Barker > It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL LETTER >> E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH ACUTE}", >> which are different ways of writing the same thing. >> > > Why does someone that wants to use, .e.g.

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 11/14/21 2:07 PM, Christopher Barker wrote: Why does someone that wants to use, .e.g. "é" in an identifier have to be able to represent it two different ways in a code file? The issue here is that fundamentally, some editors will produce composed characters and some decomposed characters

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sun, 14 Nov 2021, 19:07 Christopher Barker, wrote: > On Sun, Nov 14, 2021 at 10:27 AM MRAB wrote: > >> Unfortunately, it goes too far, because it's unlikely that we want "ᵖ" >> ("\N{MODIFIER LETTER SMALL P}') to be equivalent to "P" ("\N{LATIN >> CAPITAL LETTER P}". >> > > Is it possible to

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sun, Nov 14, 2021 at 10:27 AM MRAB wrote: > > So why does Python apply NFKC normalization to variable names?? > It's probably to deal with "é" vs "é", i.e. "\N{LATIN SMALL LETTER > E}\N{COMBINING ACUTE ACCENT}" vs "\N{LATIN SMALL LETTER E WITH ACUTE}", > which are different ways of

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

Indeed, normative annex https://www.unicode.org/reports/tr31/tr31-35.html section 5 says: "if the programming language has case-sensitive identifiers, then Normalization Form C is appropriate" (vs NFKC for a language with case-insensitive identifiers) so to follow the standard we should have used

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On 2021-11-14 17:17, Christopher Barker wrote: On Sat, Nov 13, 2021 at 2:03 PM > wrote: def 횑퓮햑풍표(): __     try: 픥e헅핝횘︴ = "Hello" 함픬r퓵ᵈ﹎ = "World"     ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!")     except 퓣핪ᵖｅ햤헿ᵣ햔횛 as

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On Sun, Nov 14, 2021 at 8:19 AM Stephen J. Turnbull < stephenjturnb...@gmail.com> wrote: > > But do > > we need to support running the same code on 3.5 to 3.10? > > Need? No. Want to not raise a big middle finger to our users? Note that I said 3.5, not 3.6 -- 3.5 is no longer supported. If

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

ptmcg＠austin.rr.com wrote: > ... add a cautionary section on homoglyphs, specifically citing > “A” (LATIN CAPITAL LETTER A) and “Α” (GREEK CAPITAL LETTER ALPHA) > as an example problem pair. There is a unicode tech report about confusables, but it is never clear where to stop. Are I (upper

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 11/14/2021 11:39 AM, Eric V. Smith wrote: For things that really are removed (and I won't get in to the reasons for why something must be removed), I think a useful stance is "we won't remove anything that would make it hard to support a single code base across all supported python

[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)

On Sat, Nov 13, 2021 at 2:03 PM wrote: > def 횑퓮햑풍표(): > > try: > > 픥e헅핝횘︴ = "Hello" > > 함픬r퓵ᵈ﹎ = "World" > > ᵖ햗퐢혯퓽(f"{헵ｅ퓵픩º_}, {햜ₒ풓lⅆ︴}!") > > except 퓣핪ᵖｅ햤헿ᵣ햔횛 as ⅇ헑c: > > 풑rℹₙₜ("failed: {}".핗헼ʳᵐªｔ(ᵉ퐱퓬)) > Wow. Just Wow. So why does Python apply NFKC

[Python-Dev] Re: Do we need to remove everything that's deprecated?

On 11/12/2021 5:55 AM, Petr Viktorin wrote: If deprecation now means "we've come up with a new way to do things, and you have two years to switch", can we have something else that means "there's now a better way to do things; the old way is a bit worse but continues to work as before"? I

[Python-Dev] Re: Do we need to remove everything that's deprecated?

Christopher Barker writes: > On Sat, Nov 13, 2021 at 12:01 AM Stephen J. Turnbull > > > What I think would make a difference is a six-like tool for making > > "easy changes" like substituting aliases and maybe marking other stuff > > that requires human brains to make the right changes. >