[Python-Dev] Re: Retiring this mailing list ?
Hello everyone, the python-dev mailing list has now been put into read-only mode and archived. The discussions have moved on to Discourse. Please follow-up there: https://discuss.python.org/c/core-dev/23 Thanks to everyone who participated in discussions on this list over the years. The archives will remain available for reference and software archeologists: https://mail.python.org/archives/list/python-dev@python.org/ Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 25 2023) Python Projects, Coaching and Support ...https://www.egenix.com/ Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ On 13.11.2023 11:17, Marc-Andre Lemburg wrote: Hello everyone, for quite a while now, core discussions have moved to Discourse and people are obviously enjoying things there: https://discuss.python.org/c/core-dev/23 The Discourse mailing list mode works reasonably well, so is a suitable replacement for this mailing list. Posts to this list are now mostly spam, mailer error reports and the occasional release postings: https://mail.python.org/archives/list/python-dev@python.org/latest (you can't see much of the spam, since we filter most of it) Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) Thanks, ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/GUU3JS5W6KOCGXV3JJRHT2UTDJTXRLY7/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Retiring this mailing list ?
On 13.11.2023 16:47, Guido van Rossum wrote:
But how would Tim Peters keep himself entertained in his retirement?
Oh, he's on Discourse as well :-) and I'm sure he'd appreciate not
having to moderate this list anymore (he's one of the other 3 maintainers).
Seriously, let’s kill it. I thought it was already deprecated.
I'll wait until next week and then get the process of archiving the list
going.
--Guido (mobile)
On Mon, Nov 13, 2023 at 02:19 Marc-Andre Lemburg wrote:
Hello everyone,
for quite a while now, core discussions have moved to Discourse and
people are obviously enjoying things there:
https://discuss.python.org/c/core-dev/23
The Discourse mailing list mode works reasonably well, so is a
suitable
replacement for this mailing list.
Posts to this list are now mostly spam, mailer error reports and the
occasional release postings:
https://mail.python.org/archives/list/python-dev@python.org/latest
(you can't see much of the spam, since we filter most of it)
Question: Should we retire and archive this mailing list ?
(I'm asking as one of the maintainers of the ML)
Thanks,
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 13
2023)
>>> Python Projects, Coaching and Support ... https://www.egenix.com/
>>> Python Product Development ... https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and
costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/
Code of Conduct: http://python.org/psf/codeofconduct/
___
Python-Dev mailing list --python-dev@python.org
To unsubscribe send an email topython-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived
athttps://mail.python.org/archives/list/python-dev@python.org/message/ZMDHUGHVBAK3KBY6V4CMPCXIWU6PD5RE/
Code of Conduct:http://python.org/psf/codeofconduct/
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 16 2023)
Python Projects, Coaching and Support ...https://www.egenix.com/
Python Product Development ...https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/UEOM2F523L3ZYFJKU7BENBKY5NTPHTXM/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Retiring this mailing list ?
On 14.11.2023 19:21, Steve Holden wrote: On Mon, 13 Nov 2023 at 10:18, Marc-Andre Lemburg wrote: [...] Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) [...] Hi Marc-Andre, Maybe just require senders to be members of the python.org <http://python.org> domain, and retain the release announcements? Well, the point is to reduce maintenance and keeping the ML alive would not lower this effort, since we get quite a bit of spam to the list. Kind regards, Steve PS: Your mail triggered a visit to https://www.python.org/community/lists/ - it seems it could use some updates. For example, comp.lang.python-announce is a news URL, which in this day and age will baffle most visitors! At the very least the page could point to the Discourse list. Yes, the page could use some editing. c.l.p.a does have a corresponding ML associated with it. It's probably better to point to that instead of the newsgroup. If you have suggestions for edits, please forward them offline. I can then put them up there. Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 15 2023) Python Projects, Coaching and Support ...https://www.egenix.com/ Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/RMQEC3Z3POPSYIYAGWSUME6QSFGY4TOW/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Retiring this mailing list ?
Hello everyone, for quite a while now, core discussions have moved to Discourse and people are obviously enjoying things there: https://discuss.python.org/c/core-dev/23 The Discourse mailing list mode works reasonably well, so is a suitable replacement for this mailing list. Posts to this list are now mostly spam, mailer error reports and the occasional release postings: https://mail.python.org/archives/list/python-dev@python.org/latest (you can't see much of the spam, since we filter most of it) Question: Should we retire and archive this mailing list ? (I'm asking as one of the maintainers of the ML) Thanks, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 13 2023) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/PDRLCB6CNLQAFVGPTLXL5QV6SVQDPCCV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Summary of Python tracker Issues
On 17.06.2022 20:48, Patrick Reader wrote:
> As a "temporary" solution to this problem, could the moderators just ban
> sta...@bugs.python.org from the list?
I've set the ML account to discard, so we should not be seeing
these messages anymore.
It would still be good to disable the script. The message headers
say that it's coming from roundup.psfhosted.org. Perhaps I can
ask Ee whether he knows where this is run.
> On 17/06/2022 19:08, Python tracker wrote:
>> ACTIVITY SUMMARY (2022-06-10 - 2022-06-17)
>> Python tracker at https://bugs.python.org/
>>
>> To view or respond to any of the issues listed below, click on the issue.
>> Do NOT respond to this message.
>>
>> Issues counts and deltas:
>> open 7146 ( +0)
>> closed 51841 ( +0)
>> total 58987 ( +0)
>>
>> Open issues with patches: 2890
>>
>>
>> Most recent 15 issues with no replies (15)
>> ==
>>
>> #47258: Python 3.10 hang at exit in drop_gil() (due to resource warnin
>> https://bugs.python.org/issue47258
>>
>> #47256: re: limit the maximum capturing group to 1,073,741,823, reduce
>> https://bugs.python.org/issue47256
>>
>> #47253: LOAD_GLOBAL instruction with wrong source position
>> https://bugs.python.org/issue47253
>>
>> #47252: socket.makefile documentation is missing data regarding the 'b
>> https://bugs.python.org/issue47252
>>
>> #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
>> https://bugs.python.org/issue47251
>>
>> #47244: email.utils.formataddr does not respect double spaces
>> https://bugs.python.org/issue47244
>>
>> #47242: Annoying white bar in IDLE (line 457 in sidebar.py)
>> https://bugs.python.org/issue47242
>>
>> #47241: [C API] Move the PyCodeObject structure to the internal C API
>> https://bugs.python.org/issue47241
>>
>> #47238: Python threading.Event().wait() depends on the system time
>> https://bugs.python.org/issue47238
>>
>> #47236: Document types.CodeType.replace() changes about co_exceptionta
>> https://bugs.python.org/issue47236
>>
>> #47228: Document that na??ve datetime objects represent local time
>> https://bugs.python.org/issue47228
>>
>> #47222: subprocess.Popen() should allow capturing output and sending i
>> https://bugs.python.org/issue47222
>>
>> #47219: asyncio with two interpreter instances
>> https://bugs.python.org/issue47219
>>
>> #47218: adding name to lzmafile
>> https://bugs.python.org/issue47218
>>
>> #47217: adding name to BZ2File
>> https://bugs.python.org/issue47217
>>
>>
>>
>> Most recent 15 issues waiting for review (15)
>> =
>>
>> #47256: re: limit the maximum capturing group to 1,073,741,823, reduce
>> https://bugs.python.org/issue47256
>>
>> #47255: Many broken :meth: roles in the docs
>> https://bugs.python.org/issue47255
>>
>> #47254: enhanced dir?
>> https://bugs.python.org/issue47254
>>
>> #47251: Merge BINARY_SUBSCR_LIST_INT with BINARY_SUBSCR_LIST_TUPLE
>> https://bugs.python.org/issue47251
>>
>> #47243: Duplicate entry in 'Objects/unicodetype_db.h'
>> https://bugs.python.org/issue47243
>>
>> #47233: show_caches option affects code positions reported by dis.get_
>> https://bugs.python.org/issue47233
>>
>> #47222: subprocess.Popen() should allow capturing output and sending i
>> https://bugs.python.org/issue47222
>>
>> #47218: adding name to lzmafile
>> https://bugs.python.org/issue47218
>>
>> #47217: adding name to BZ2File
>> https://bugs.python.org/issue47217
>>
>> #47216: adding mtime option to gzip open()
>> https://bugs.python.org/issue47216
>>
>> #47215: Add "unstable" frame stack api
>> https://bugs.python.org/issue47215
>>
>> #47208: Support libffi implementations that cannot support invocations
>> https://bugs.python.org/issue47208
>>
>> #47205: posix.sched_{get|set}affinity(-1) no longer returns ProcessLoo
>> https://bugs.python.org/issue47205
>>
>> #47200: Add ZipInfo.mode property
>> https://bugs.python.org/issue47200
>>
>> #47199: multiprocessing: micro-optimize Connection.send_bytes() method
>> https://bugs.python.org/issue47199
>>
>> ___
>> Python-Dev mailing list -- python-dev@python.org
>> To unsubscribe send an email to python-dev-le...@python.org
>> https://mail.python
[Python-Dev] Re: It's now time to deprecate the stdlib urllib module
... and there are also plenty examples out there of using http.server as a quick HTTP server for trying out new things, testing and teaching. FWIW: I find this discussion a bit strange. Python's stdlib is supposed to provide basic tooling for a breadth of use cases, with emphasis on "basic" and "breadth". urllib is such a basic library and covers one of the main use cases for Python we have. It would be pretty much beside the point of the stdlib to remove such basic functionality and make Python less attractive and less useful for beginners. Anything more complex can be dealt with on PyPI, as it is already happening. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Feb 08 2022) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/AKWL7QKOZJDODM3LIX4BBYZ4HMXZC3CZ/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: [python-committers] Sad news from Zurich
This is really sad news indeed. Fredrik was a brilliant and innovative key figure in Python land for such a long time and has contributed a lot towards Python's success. Here's an older archived version of his website: http://web.archive.org/web/20201109205132/http://effbot.org/ On 10.12.2021 21:20, Guido van Rossum wrote: > A former core dev who works at Google just passed the news that Fredrik Lundh > (also known as Effbot) has died. > > > Fredrik was an early Python contributor (e.g. Elementtree and the 're' module) > and his enthusiasm for the language and community were inspiring for all who > encountered him or his work. He spent countless hours on comp.lang.python > answering questions from newbies and advanced users alike. > > > He also co-founded an early Python startup, Secret Labs AB, which among other > software released an IDE named PythonWorks. Fredrik also created the Python > Imaging Library (PIL) which is still THE way to interact with images in > Python, > now most often through its Pillow fork. His effbot.org <http://effbot.org> > site > was a valuable resource for generations of Python users, especially its > Tkinter > documentation. > > > Fredrik's private Facebook page contains the following message from November > 25 > by Ylva Larensson (translated from Swedish): > > > """ > > It is with such sorrow and pain that I write this. Fredrik has left us > suddenly. > > """ > > > A core dev wrote: "I felt privileged to be able to study Fredrik's code and to > read his writing. He was a huge asset to our community in the early days. I > enjoyed his sense of humor as well. I'm sad that he passed away." > > > We will miss him. > > > > -- > --Guido van Rossum (python.org/~guido <http://python.org/~guido>) > /Pronouns: he/him //(why is my pronoun here?)/ > <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-change-the-world/> > > ___ > python-committers mailing list -- python-committ...@python.org > To unsubscribe send an email to python-committers-le...@python.org > https://mail.python.org/mailman3/lists/python-committers.python.org/ > Message archived at > https://mail.python.org/archives/list/python-committ...@python.org/message/36Q5QBILL3QIFIA3KHNGFBNJQKXKN7SD/ > Code of Conduct: https://www.python.org/psf/codeofconduct/ > -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Dec 12 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ____ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XH76ADYZOQX4XFPWRPX2NYRK3GMQ56QM/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Preventing Unicode-related gotchas (Was: pre-PEP: Unicode Security Considerations for Python)
On 15.11.2021 12:36, Steven D'Aprano wrote: > On Sun, Nov 14, 2021 at 10:12:39PM -0800, Christopher Barker wrote: > >> I am, however, surprised and disappointed by the NKFC normalization. >> >> For example, in writing math we often use different scripts to mean >> different things (e.g. TeX's Blackboard Bold). So if I were to use >> some of the Unicode Mathematical Alphanumeric Symbols, I wouldn't want >> them to get normalized. > > Hmmm... would you really want these to all be different identifiers? > > 𝕭 𝓑 𝑩 𝐁 B > > You're assuming the reader of the code has the right typeface to view > them (rather than as mere boxes), and that their eyesight is good enough > to distinguish the variations even if their editor applies bold or > italic as part of syntax highlighting. That's very bold of you :-) > > In any case, the question of NFKC versus NFC was certainly considered, > but unfortunately PEP 3131 doesn't document why NFKC was chosen. > > https://www.python.org/dev/peps/pep-3131/ > > Before we change the normalisation rules, it would probably be a good > idea to trawl through the archives of the mailing list and work out why > NFKC was chosen in the first place, or contact Martin von Löwis and see > if he remembers. This was raised in the discussion, but never conclusively answered: https://mail.python.org/pipermail/python-3000/2007-May/007995.html NFKC is the standard normalization form when you want remove any typography related variants/hints from the text before comparing strings. See http://www.unicode.org/reports/tr15/ I guess that's why Martin chose this form, since the point was to maintain readability, even if different variants of a character are used in the source code. A "B" in the source code should be interpreted as an ASCII B, even when written as 𝕭 𝓑 𝑩 or 𝐁. This simplifies writing code and does away with many of the security issues you could otherwise run into (where e.g. the absence of an identifier causes the application flow to be different). >> Then there's the question of when this normalization happens (and when it >> doesn't). It happens in the parser when reading a non-ASCII identifier (see Parser/pegen.c), so only applies to source code, not attributes you dynamically add to e.g. class or module namespaces. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 15 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SNN2WZ3MOH5IACSZVHGS6DKTNMKO5JBV/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Having Sorted Containers in stdlib?
On 12.11.2021 17:46, Bob Fang wrote: > > >> On 12 Nov 2021, at 16:32, Marc-Andre Lemburg > <mailto:m...@egenix.com>> wrote: >> >> Perhaps there's a reverse dependency graph we could use to find out >> why the package is downloaded this often. I remember having seen >> a project which does this, but have lost the URL. > > > I believe this is the URL we are looking for: > > https://www.wheelodex.org/projects/sortedcontainers/rdepends/?page=1 Yes, thanks, that was the one. The listing doesn't seem to solve the puzzle either, though. There are a few high profile projects using the package, but those are not high up on the download ranking, so don't explain the high download counts of the package. BTW: This reverse dependency ranking on the website gives a good idea of how important a package is for the Python package eco system: https://www.wheelodex.org/rdepends-leaders/ (sort of like the Page rank for Python packages) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 12 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/732T3MNBB2PMFP7TVXSDDMW6KNI5CEQS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Having Sorted Containers in stdlib?
On 12.11.2021 17:10, Steven D'Aprano wrote: > On Fri, Nov 12, 2021 at 10:07:13AM -0500, Paul Ganssle wrote: > >> I knew about sortedcontainers and I also don't remember ever seeing a >> situation where I needed one or recommended its use. > > We have a very odd situation where apparently sortedcontainers is one > of the most well-known, popular, most heavily downloaded libraries on > PyPI. According to here: > > https://hugovk.github.io/top-pypi-packages/ > > sortedcontainers is the 290th most popular package on PyPI, ahead of > such luminaries as pylint, black, selenium, mypy, django and nose. > > And yet, nobody(?) admits to either using it or knowing what it could be > used for. How very curious :-/ Those download stats can be misleading. Packages are often pulled in as a dependency of other packages which are popular or used a lot in CI/CD setups. Perhaps there's a reverse dependency graph we could use to find out why the package is downloaded this often. I remember having seen a project which does this, but have lost the URL. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 12 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FJT4SSWISWWRFB5FGRPXSLDLDZVMUIXF/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python
On 03.11.2021 01:21, Chris Angelico wrote:
> On Wed, Nov 3, 2021 at 11:09 AM Steven D'Aprano wrote:
>>
>> On Wed, Nov 03, 2021 at 03:03:54AM +1100, Chris Angelico wrote:
>>> On Wed, Nov 3, 2021 at 1:06 AM Petr Viktorin wrote:
>>>> Let me know if it's clear in the newest version, with this note:
>>>>
>>>>> Here, ``encoding: unicode_escape`` in the initial comment is an encoding
>>>>> declaration. The ``unicode_escape`` encoding instructs Python to treat
>>>>> ``\u0027`` as a single quote (which can start/end a string), ``\u002c`` as
>>>>> a comma (punctuator), etc.
>>>>
>>>
>>> Huh. Is that level of generality actually still needed? Can Python
>>> deprecate all but a small handful of encodings?
>>
>> To be clear, are you proposing to deprecate the encodings *completely*
>> or just as the source code encoding?
>
> Only source code encodings. Obviously we still need to be able to cope
> with all manner of *data*, but Python source code shouldn't need to be
> in bizarre, weird encodings.
>
> (Honestly, I'd love to just require that Python source code be UTF-8,
> but that would probably cause problems, so mandating that it be one of
> a small set of encodings would be a safer option.)
Most Python code will be written in UTF-8 going forward, but there's
still a lot of code out there in other encodings. Limiting this
to some reduced set doesn't really make sense, since it's not
clear where to draw the line.
Coming back to the thread topic, many of the Unicode security
considerations don't apply to non-Unicode encodings, since those
usually don't support e.g. changing the bidi direction within a
stream of text or other interesting features you have in Unicode
such as combining code points, invisible (space) code points, font
rendering hint code points, etc.
So in a sense, those non-Unicode encodings are safer than
using UTF-8 :-)
Please also note that most character lookalikes are not encoding
issues, but instead font issues, which then result in the characters
looking similar.
There are fonts which are designed to avoid this
and it's no surprise that source code fonts typically do make
e.g. 0 and O, as well as 1 and l look sufficiently different to be
able to notice the difference.
Things get a lot harder when dealing with combining characters, since
it's not always easy to spot the added diacritics, e.g. try
this:
>>> print ('a\u0348bc') # strong articulation
a͈bc
>>> print ('a\u034Fbc') # combining grapheme joiner
a͏bc
The latter is only "visible" in the unicode_escape encoding:
>>> print ('a\u034Fbc'.encode('unicode_escape'))
b'a\\u034fbc'
Projects wanting to limit code encoding settings, disallow using
bidi markers and other special code points in source code, can easily
do this via e.g. pre-commit hooks, special editor settings, code
linters or security scanners.
I don't think limiting the source code encoding is the right approach
to making code more secure. Instead, tooling has to be used to detect
potentially malicious code points in code.
--
Marc-Andre Lemburg
eGenix.com
Professional Python Services directly from the Experts (#1, Nov 03 2021)
>>> Python Projects, Coaching and Support ...https://www.egenix.com/
>>> Python Product Development ...https://consulting.egenix.com/
::: We implement business ideas - efficiently in both time and costs :::
eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48
D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg
Registered at Amtsgericht Duesseldorf: HRB 46611
https://www.egenix.com/company/contact/
https://www.malemburg.com/
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
Message archived at
https://mail.python.org/archives/list/python-dev@python.org/message/MBWBY47ILPL3E6733W4XAZXF2M6RKFH6/
Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: pre-PEP: Unicode Security Considerations for Python
On 01.11.2021 13:17, Petr Viktorin wrote: >> PEP: >> Title: Unicode Security Considerations for Python >> Author: Petr Viktorin >> Status: Active >> Type: Informational >> Content-Type: text/x-rst >> Created: 01-Nov-2021 >> Post-History: Thanks for writing this up. I'm not sure whether a PEP is the right place for such documentation, though. Wouldn't it be more visible in the standard Python documentation ? -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Nov 02 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FSFG2B3LCWU5PQWX3WRIOJGNV2JFW4AU/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Default for python -X frozen_modules.
On 28.09.2021 14:26, Filipe Laíns wrote: > On Tue, 2021-09-28 at 10:22 +0200, Marc-Andre Lemburg wrote: >> On 27.09.2021 18:51, Eric Snow wrote: >>> We've frozen most of the stdlib modules imported during "python -c >>> pass" [1][2], to make startup a bit faster. Import of those modules >>> is controlled by "-X frozen_modules=[on|off]". Currently it defaults >>> to "off" but we'd like to default to "on". The blocker is the impact >>> on contributors. I expect many will make changes to a stdlib module >>> and then puzzle over why those changes aren't getting used. That's an >>> annoyance we can avoid, which is the point of this thread. >>> >>> Possible solutions: >>> >>> 1. always default to "on" (the annoyance for contributors isn't big enough?) >>> 2. default to "on" if it's a PGO build (and "off" otherwise) >>> 3. default to "on" unless running from the source tree >>> >>> Thoughts? >> >> #3 sounds like a good solution, but how would you detect "running >> from the source tree" ? This sounds like you need another stat call >> somewhere, which is what the frozen modules try to avoid. > > It does. FYI, here's the sysconfig implementation > https://github.com/python/cpython/blob/main/Lib/sysconfig.py#L146-L181 > > But a more efficient way to do this could be added. Thanks. So the Setup files are used as landmarks to determine whether Python is from a Python source tree or not. >> I'd like to suggest adding an environment variable to enable / >> disable the setting instead. This makes it easy to customize the >> behavior without introducing complicated logic. >> > > From your followup reply, it seems like you are suggesting that it should be > enabled by default, and use a env var to disable it. That would have the same > problem regarding the annoyance of contributors. Setting an env var in a dev environment is not really all that hard (I always have such environments set up for all the projects I'm working on), so it's only a mild annoyance, while not affecting all other times Python is run by others. The env var would also have the nice side effect of not cluttering up the command line and making it easy to test drive frozen vs. source code based imports. > Is there any reason why you would prefer that over #2? That seems like the > best > option to me if #3 is not feasible. PGO optimizations have to be enabled with ./configure and are not enabled per default, so it's rather likely that many Python binaries out there do not have PGO enabled and would then not benefit from the frozen modules -- even though PGO is not required for supporting frozen modules. I don't think combining the two features is a good idea. Cheers, -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 28 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ signature.asc Description: OpenPGP digital signature ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/SKDBB3XN2FNWTIVDTOBFLEJXUFAWG6IO/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Default for python -X frozen_modules.
On 27.09.2021 18:51, Eric Snow wrote: > We've frozen most of the stdlib modules imported during "python -c > pass" [1][2], to make startup a bit faster. Import of those modules > is controlled by "-X frozen_modules=[on|off]". Currently it defaults > to "off" but we'd like to default to "on". The blocker is the impact > on contributors. I expect many will make changes to a stdlib module > and then puzzle over why those changes aren't getting used. That's an > annoyance we can avoid, which is the point of this thread. > > Possible solutions: > > 1. always default to "on" (the annoyance for contributors isn't big enough?) > 2. default to "on" if it's a PGO build (and "off" otherwise) > 3. default to "on" unless running from the source tree > > Thoughts? #3 sounds like a good solution, but how would you detect "running from the source tree" ? This sounds like you need another stat call somewhere, which is what the frozen modules try to avoid. I'd like to suggest adding an environment variable to enable / disable the setting instead. This makes it easy to customize the behavior without introducing complicated logic. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 28 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/FLFBNODDQOGFNKXOMFBQKTE5AQHLA7LS/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: The Default for python -X frozen_modules.
On 28.09.2021 10:22, Marc-Andre Lemburg wrote: > On 27.09.2021 18:51, Eric Snow wrote: >> We've frozen most of the stdlib modules imported during "python -c >> pass" [1][2], to make startup a bit faster. Import of those modules >> is controlled by "-X frozen_modules=[on|off]". Currently it defaults >> to "off" but we'd like to default to "on". The blocker is the impact >> on contributors. I expect many will make changes to a stdlib module >> and then puzzle over why those changes aren't getting used. That's an >> annoyance we can avoid, which is the point of this thread. >> >> Possible solutions: >> >> 1. always default to "on" (the annoyance for contributors isn't big enough?) >> 2. default to "on" if it's a PGO build (and "off" otherwise) >> 3. default to "on" unless running from the source tree >> >> Thoughts? > > #3 sounds like a good solution, but how would you detect "running > from the source tree" ? This sounds like you need another stat call > somewhere, which is what the frozen modules try to avoid. > > I'd like to suggest adding an environment variable to enable / > disable the setting instead. This makes it easy to customize the > behavior without introducing complicated logic. Just to clarify: the modules would still always be frozen with the env var setting, but Python would simply not import them as frozen modules, but instead go and look on the PYTHONPATH for the modules. This could be achieved by special casing the frozen module finder function to only trigger on importlib modules and return NULL for all other possibly frozen modules. -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Sep 28 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ________ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/XVEVVUFUXNDM7LQPWPPDOWITW2HXMPPK/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Should PEP 8 be updated for Python 3 only?
On 26.08.2021 06:07, Christopher Barker wrote: > I'm working on a PR now. It seems there is little support for keeping the > python2 content in the docs, so I'm re-writing it as though it was never > there. > If someone wants to add a note about Python 2, of course that can be added > later. > > Note that "moving the Python 2 content to a section at the end" is not all > that > straightforward, as it is pretty mixed in with the text at this point. > > But now a question -- the current text reads: > > "Code in the core Python distribution should always use UTF-8" > > and then: > > "In the standard library, non-default encodings should be used only for > test purposes or when a comment or docstring needs to mention an author > name that contains non-ASCII characters ..." > > I *think* that's a remnant of the Py2 ASCII encoding days -- but I wanted to > make sure, a bit later on, it says: > > "The following policy is prescribed for the > standard library ... In addition, string literals and comments must also be in > ASCII." For Python 2 code we mandated ASCII for the stdlib, with some exceptions using the source code encoding for testing purposes or in case e.g. Martin von Löwis or Marc-André Lemburg wanted to put his name into the code without escaping part of it ;-) Note that Python 2 defaults to ASCII as source code encoding. With UTF-8 as standard source code encoding, this is no longer necessary. So the second quote can be changed to "In the standard library, non-default source code encodings should be used only for test purposes ...". > Is that still correct for string literals and comments? And what about > docstrings? > > It seems to me that if we really are utf-8, then there is no need for those > "textual" elements to be ASCII. e.g they can still contain non-ascii > characters, > and escaping those makes things less readable, not more. > > So I think that section should now read: > > """ > Source File Encoding > > > Code in the core Python distribution should always use UTF-8, and should not > have an encoding declaration. > > In the standard library, non-UTF-8 encodings should be used only for > test purposes. I think the above should be limited to Python code. In C or other source files you may well still need a source code encoding. > The following policy is prescribed for the standard library (see PEP > 3131): All identifiers in the Python standard library MUST use > ASCII-only identifiers, and SHOULD use English words wherever feasible > (in many cases, abbreviations and technical terms are used which aren't > English). In comment and docstrings, authors whose names tht are not > based on the Latin alphabet (latin-1, ISO/IEC 8859-1 character set) > MUST provide a transliteration of their names in this character set. > > Open source projects with a global audience are encouraged to adopt a > similar policy. > """ > > But maybe we do want to keep comments, docstrings and literals as ASCII with > escapes? No need for the stdlib, since UTF-8 is widely accepted by now and why should people with non-ASCII names not be able to write their true name ? You may have noted that I rarely do... the reason is that in the past, the accent on the "e" caused me too many problems. Perhaps one of these days, I'll go back to adding it again :-) -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 26 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ... https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/V4YOYCZKJWSSHDSHDJZKVMAYMYUTVCI3/ Code of Conduct: http://python.org/psf/codeofconduct/
[Python-Dev] Re: Is anyone relying on new-bugs-announce/python-bugs-list/bugs.python.org summaries
On 24.08.2021 00:11, Ammar Askar wrote: > Hey everyone, > > As part of PEP 588, migrating bugs.python.org issues to Github, there > are two current mailing list related items that need a replacement or > need to be turned down. > > 1. Weekly summary emails with bug counts and issues from the week, > example: > https://mail.python.org/archives/list/python-dev@python.org/thread/JRFJ4QH7TR35HFRQWOYPPCGOYRFAXK24/ Not really, but they present some nice statistics. > 2. Emails sent to the new-bugs-announce and python-bugs-list for new > issues and comments to existing issues. I rely on python-bugs-list and have a filter on that to trigger on keywords I'm interested in. The list gets all updates for all RoundUp bugs. > I wanted to quickly gauge if anyone is relying on these mailing > lists/emails or if it's a convenient part of your workflow. Feel free > to chime in here or on the migration issues directly with your > use-case: > > 1. https://github.com/psf/gh-migration/issues/6 > 2. https://github.com/psf/gh-migration/issues/7 -- Marc-Andre Lemburg eGenix.com Professional Python Services directly from the Experts (#1, Aug 25 2021) >>> Python Projects, Coaching and Support ...https://www.egenix.com/ >>> Python Product Development ...https://consulting.egenix.com/ ::: We implement business ideas - efficiently in both time and costs ::: eGenix.com Software, Skills and Services GmbH Pastor-Loeh-Str.48 D-40764 Langenfeld, Germany. CEO Dipl.-Math. Marc-Andre Lemburg Registered at Amtsgericht Duesseldorf: HRB 46611 https://www.egenix.com/company/contact/ https://www.malemburg.com/ ___ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/KCFFZC2SOZZH4MNBM7BZDBM5XPS7UITB/ Code of Conduct: http://python.org/psf/codeofconduct/
