Re: [Python-Dev] Best practices for Enum

On Sun, May 12, 2013 at 4:49 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > * will enums break doctests or any existing user code > Those are already broken by design. We shouldn't be limited just because someone wrote a bad test that assumed a particular repr of a value. We've

Re: [Python-Dev] Best practices for Enum

Bad: doctests. On Tue, May 14, 2013 at 5:08 AM, Steven D'Aprano wrote: > On 14/05/13 16:51, Gregory P. Smith wrote: > [...] > > This sounds like a feature request for doctest. doctest could be educated >> about enums and automatically compare to the integer value for su

Re: [Python-Dev] Mysterious Python pyc file corruption problems

On Thu, May 16, 2013 at 11:04 AM, Barry Warsaw wrote: > On May 16, 2013, at 09:44 AM, Ethan Furman wrote: > > >Is it happening on the same machines? If so, perhaps a daemon to monitor > >those files and then scream and shout when one changes. Might help track > >down what's going on at the time

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On Sat, May 18, 2013 at 11:41 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > On May 14, 2013, at 9:39 AM, Gregory P. Smith wrote: > > Bad: doctests. > > > I'm hoping that core developers don't get caught-up in the "doctests are >

Re: [Python-Dev] Purpose of Doctests [Was: Best practices for Enum]

On May 19, 2013 4:31 PM, "Benjamin Peterson" wrote: > > 2013/5/19 Gregory P. Smith : > > Idea: I don't believe anybody has written a fixer for lib2to3 that applies > > fixers to doctests. That'd be an interesting project for someone. > > 2to3 c

Re: [Python-Dev] PEP 442 delegate

+1 I second the scoundrel! fwiw, that pep being implemented is going to be a great addition to Python. :) On Tue, May 21, 2013 at 8:57 AM, Antoine Pitrou wrote: > > Hello, > > I would like to nominate Benjamin as BDFL-Delegate for PEP 442. > Please tell me if you would like to object :) > > R

Re: [Python-Dev] cpython: Issue #3329: Add new APIs to customize memory allocators

fwiw i'm also supportive of adding these apis. Lets PEP away to iron out any details or document disagreements but overall I'd also like to see something a lot like these go in. -gps On Fri, Jun 14, 2013 at 10:50 PM, Nick Coghlan wrote: > On 15 June 2013 11:54, Victor Stinner wrote: > > 2013

Re: [Python-Dev] backported Enum

I tend to just pick a name and stick with it. subprocess32 is subprocess backported from 3.2 (with the 3.3 timeout feature also in it). unittest2 is unittest from 2.7. It tends to work. and it also emphasizes that i'm unlikely to backport future non-bugfix updates beyond the release mentioned a

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

Raymond - Why did you do this in the 2.7 branch? It hasn't been done in 3.3 or default and it isn't not the sort of change we make in a stable release branch without justification. What issue was this for? What problem were you solving? -gps On Mon, Jun 17, 2013 at 11:08 PM, Ethan Furman w

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

Your work is great! I even agree with the changes on a coding best practices level. It's just that it belongs on the default (3.4) branch as it is an enhancement, not a bug fix. We don't do new things on release branches. I agree that can be extremely frustrating at times, knowing that code won'

Re: [Python-Dev] cpython (2.7): Fix comment blocks. Adjust blocksize to a power-of-two for better divmod

On Jun 24, 2013 9:11 PM, "Guido van Rossum" wrote: > > On Mon, Jun 24, 2013 at 7:47 PM, Raymond Hettinger < raymond.hettin...@gmail.com> wrote: >> >> >> >> On Jun 24, 2013, at 4:07 AM, Victor Stinner wrote: >> >>> Out of curiosity, do you know (remember) how was the number 62 chosen? >>> Is it a

Re: [Python-Dev] End of the mystery "@README.txt Mercurial bug"

If we disallowed builds *from in source tree* requiring all output to go into a separate build output directory instead (like any sane person does*) we wouldn't need a crazy find in the source tree to mess things up. ;) this can be done today: $ mkdir foo && cd foo && ../my-hg/2.7/configure --src

Re: [Python-Dev] [Python-checkins] cpython (3.3): Issue #17860: explicitly mention that std* streams are opened in binary mode by

Please update the docstring in subprocess.py with the wording improvements that you settle on while you're at it. On Sat, Jul 6, 2013 at 6:03 AM, Ronald Oussoren wrote: > > On 6 Jul, 2013, at 14:09, Ronald Oussoren wrote: > > > > > On 6 Jul, 2013, at 13:59, R. David Murray wrote: > >> > >> IMO

Re: [Python-Dev] Tweaking PEP 8 guidelines for use of leading underscores

+1 This is already how we've been behaving for years. On Sun, Jul 14, 2013 at 4:09 AM, Nick Coghlan wrote: > On 14 July 2013 18:11, Nick Coghlan wrote: > >> Currently, the naming section of PEP 8 doesn't say very much about what a >> leading underscore *means* in the Python standard library.

Re: [Python-Dev] Misc re.match() complaint

On Mon, Jul 15, 2013 at 4:14 PM, Guido van Rossum wrote: > In a discussion about mypy I discovered that the Python 3 version of > the re module's Match object behaves subtly different from the Python > 2 version when the target string (i.e. the haystack, not the needle) > is a buffer object. > >

Re: [Python-Dev] Avoiding error from repr() of recursive dictview

On Mon, Jul 22, 2013 at 2:44 PM, Ben North wrote: > Hi, > > A friend of mine, Ruadhan O'Flanagan, came across a bug which turned out > to be the one noted in [http://bugs.python.org/issue18019], i.e.: > > >>> d={} > >>> d[42]=d.viewvalues() > >>> d > > > This issue has been fixed in hg; the beha

Re: [Python-Dev] [Python-checkins] cpython (3.3): return NULL here

On Tue, Jul 23, 2013 at 8:46 AM, Ronald Oussoren wrote: > > On 23 Jul, 2013, at 17:36, Christian Heimes wrote: > > > Am 23.07.2013 17:10, schrieb Benjamin Peterson: > >>> PyErr_SetFromErrno() already and always returns NULL. Or do you prefer > >>> to return NULL explicitly? > >> > >> It might alw

Re: [Python-Dev] Inherance of file descriptor and handles on Windows (PEP 446)

On Fri, Jul 26, 2013 at 3:23 PM, Antoine Pitrou wrote: > On Sat, 27 Jul 2013 00:18:40 +0200 > Victor Stinner wrote: > > 2013/7/26 Antoine Pitrou : > > > On Fri, 26 Jul 2013 22:17:47 +0200 > > >> """ > > >> On Linux, setting the close-on-flag has a low overhead on > > >> performances. Results of

Re: [Python-Dev] EINTR handling...

On Fri, Aug 30, 2013 at 10:57 AM, Guido van Rossum wrote: > I don't have a strong opinion on this either. The distinction between > send() and send_all() makes sense to me though (send_all() works hard to > get all your data out, send() only does what it can quickly). > > Personally for calls lik

Re: [Python-Dev] Add a new tracemalloc module to trace memory allocations

First, I really like this. +1 On Wed, Aug 28, 2013 at 6:07 PM, Victor Stinner wrote: > 2013/8/29 Victor Stinner : > > My proposed implementation for Python 3.4 is different: > > > > * no enable() / disable() function: tracemalloc can only be enabled > > before startup by setting PYTHONTRACEMALLO

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

Just drop support for 10.6 with Python 3.4. Problem solved. People on that old of a version of the OS can build their own Python 3.4 or do the right thing and upgrade or just install Linux. This isn't Windows. Compiler tool chains are freely available for the legacy platform. We don't need to main

Re: [Python-Dev] Compiler for the Mac OS X version of Python 3.4

On Wed, Sep 18, 2013 at 6:38 AM, Ronald Oussoren wrote: > > > On Sep 18, 2013, at 03:03 PM, "Martin v. Löwis" > wrote: > > Am 15.09.13 00:56, schrieb Ryan: > > +1. A 10.6-only build makes sense. > > > I'd like to support Russell's point: this could put a burden on everyone > releasing extension m

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 11:42 AM, Christian Heimes wrote: > Hi, > > some of you may have seen that I'm working on a PEP for a new hash API > and new algorithms for hashing of bytes and str. The PEP has three major > aspects. It introduces DJB's SipHash as secure hash algorithm, chances > the hash A

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 12:05 PM, Guido van Rossum wrote: > We already have adopted a feature that plugged most viable attacks on web > apps, I think that's enough. > Actually... we did not do a very good job on that: http://bugs.python.org/issue14621 The point of allowing alternates is to let p

Re: [Python-Dev] Make str/bytes hash algorithm pluggable?

On Thu, Oct 3, 2013 at 1:06 PM, Victor Stinner wrote: > 2013/10/3 Christian Heimes : > > A hash algorithm can be added and one avaible hash > > algorithm can be set before Py_Initialize() is called for the first > > time. > > "Py_Initialize" is not the good guard. Try for example "python3 -X > fau

Re: [Python-Dev] cpython: Rename contextlib.ignored() to contextlib.ignore().

On Fri, Oct 11, 2013 at 11:41 AM, Glenn Linderman wrote: > On 10/11/2013 10:19 AM, Eric V. Smith wrote: > > On 10/11/2013 12:43 PM, Barry Warsaw wrote: > > On Oct 11, 2013, at 06:27 PM, Georg Brandl wrote: > > > Maybe to fit in with other verb-like APIs used as context managers: > it's open() n

Re: [Python-Dev] Right place for PBKDF2 wrapper

On Sat, Oct 12, 2013 at 11:06 AM, Georg Brandl wrote: > Am 12.10.2013 19:37, schrieb Antoine Pitrou: > > On Sat, 12 Oct 2013 19:19:44 +0200 > > Christian Heimes wrote: > ... > >> * add PBKDF2 to ``hashlib`` > >> * make ``hashlib`` a package and add PBKDF2 to a new ``hashlib.kdf`` > module > >>

Re: [Python-Dev] Right place for PBKDF2 wrapper

On Sat, Oct 12, 2013 at 2:31 PM, Christian Heimes wrote: > Am 12.10.2013 23:04, schrieb Gregory P. Smith: > > agreed with any of these three. > > I'm going for hashlib.pbkdf2_hmac() for now. Right now it's just one > function. We can always add a new module for

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

On Thu, Oct 17, 2013 at 9:06 AM, Barry Warsaw wrote: > On Oct 18, 2013, at 01:26 AM, Nick Coghlan wrote: > > >By contrast, suppress() and redirect_stdout() are the *first* general > >purpose context managers added to contextlib since its incarnation in > >Python 2.5 (although there have been many

Re: [Python-Dev] On suppress()'s trail blazing (was Re: cpython: Rename contextlib.ignored() to contextlib.ignore())

> Right again. The simplest rule to remember seems to be "don't use yield or > yield-from inside a with-statement". You can relax it by limiting it to > context managers that manage any kind of shared resource, but that is > probably already too subtle: e.g. yielding inside "with open(file) as f" >

Re: [Python-Dev] Supported versions of OpenSSL

On Mon, Aug 29, 2016 at 1:18 PM Christian Heimes wrote: > On 2016-08-29 21:31, M.-A. Lemburg wrote: > > On 29.08.2016 18:33, Cory Benfield wrote: > >> > >>> On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > >>> > >>> On 28.08.2016 22:40, Christian Heimes wrote: > ... > I like to reduce

Re: [Python-Dev] Supported versions of OpenSSL

On Tue, Aug 30, 2016 at 1:08 PM M.-A. Lemburg wrote: > On 29.08.2016 22:16, Christian Heimes wrote: > > On 2016-08-29 21:31, M.-A. Lemburg wrote: > >> On 29.08.2016 18:33, Cory Benfield wrote: > >>> > On 29 Aug 2016, at 04:09, M.-A. Lemburg wrote: > > On 28.08.2016 22:40, Christia

Re: [Python-Dev] The Amazing Unreferenced Weakref

This code appears to have been added to fix https://bugs.python.org/issue3100 - A crash involving a weakref subclass. -gps On Tue, Sep 6, 2016 at 3:51 PM Larry Hastings wrote: > > This is all about current (3.6) trunk. > > In Objects/weakrefobject.c, we have the function > PyObject_ClearWeakRef

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

For the regular dict (non kwargs or namespace __dict__) use case I would actually like to *see disorder preserved during iteration*. If we don't, we will eventually to find ourselves in a similar state we were in pre hash-randomization: (1) Over time, code will come to depend on the order for no

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 10:25 AM INADA Naoki wrote: > > So fundamental question is: Is it to so bad thing that some people > write code depending on CPython and PyPy implementation? > Yes. See below. I think cross-interpreter libraries can use OrederedDict correctly > when they should use it.

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 9:51 AM Chris Angelico wrote: > On Tue, Sep 13, 2016 at 2:27 AM, Gregory P. Smith wrote: > > Disorder for this purpose need not be a random shuffle (overkill). It > just > > needs to be regularly inconsistent. A simple thing to do on top of 3.

Re: [Python-Dev] Python 3.6 dict becomes compact and gets a private version; and keywords become ordered

On Mon, Sep 12, 2016 at 3:57 PM Brett Cannon wrote: > On Mon, 12 Sep 2016 at 15:46 Ethan Furman wrote: > > On 09/12/2016 09:27 AM, Gregory P. Smith wrote: > > > For the regular dict (non kwargs or namespace __dict__) use case I would > actually like to /see disorder prese

Re: [Python-Dev] Playing games with reference counts (was Re: PyWeakref_GetObject() borrows its reference from... whom?)

On Thu, Oct 13, 2016 at 4:43 AM Larry Hastings wrote: > > On 10/10/2016 10:38 PM, Chris Angelico wrote: > > On Tue, Oct 11, 2016 at 8:14 AM, Larry Hastings > wrote: > > These hacks where we play games with the > reference count are mostly removed in my branch. > > That's exactly what I would h

[Python-Dev] Would someone please update the profile-opt buildbot flag settings?

For http://buildbot.python.org/all/buildslaves/gps-debian-profile-opt in particular (and any others we have using it - if any): Our new --with-optimizations configure flag has been renamed to *--enable-optimizations* to be more consistent with preferred autoconf terminology (see https://bugs.python

Re: [Python-Dev] Help requested with Python 2.7 performance regression

We updated profile-opt to use the testsuite subset based on what distros had already been using for their training runs. As for the comment about the test suite not being good for training Mostly a myth. The test suite exercises the ceval loop well as well as things like re and json sufficientl

Re: [Python-Dev] 2017 Python Language Summit coverage

Thanks Jake! I'm laughing at not being in the photo. That must've happened soon after I left the room as I disappeared a tad early. I'll pretend I'm hiding behind Brett or Thomas. ;) -gps On Thu, May 25, 2017 at 10:34 AM Barry Warsaw wrote: > On May 25, 2017, at 08:03 AM, Jake Edge wrote: >

Re: [Python-Dev] The untuned tunable parameter ARENA_SIZE

On Fri, Jun 2, 2017 at 12:33 PM Larry Hastings wrote: > > On 06/02/2017 02:46 AM, Victor Stinner wrote: > > I would be curious of another test: use pymalloc for objects larger > than 512 bytes. For example, allocate up to 4 KB? > > In the past, we already changed the maximum size from 256 to 512

Re: [Python-Dev] PEP 538 warning at startup: please remove it

On Mon, Jun 12, 2017 at 5:25 AM Nick Coghlan wrote: > On 12 June 2017 at 18:56, Victor Stinner wrote: > > Hi, > > > > Nick Coghlan pushed his implementation of his PEP 538: nice! Nice step > > forward to UTF-8 everywhere ;-) > > > > I would prefer to not be annoyed by warning messages about enco

Re: [Python-Dev] PEP 538 warning at startup: please remove it

On Mon, Jun 12, 2017 at 1:48 PM Nathaniel Smith wrote: > On Jun 12, 2017 10:50, "Gregory P. Smith" wrote: > > > The problem, as with all warnings, is that it isn't the user who has > control over the problem who sees the warning. It is the end use of an > app

Re: [Python-Dev] 64 bit units in PyLong

On Wed, Jul 5, 2017 at 12:05 PM Mark Dickinson wrote: > On Mon, Jul 3, 2017 at 5:52 AM, Siyuan Ren wrote: > > The current PyLong implementation represents arbitrary precision > integers in > > units of 15 or 30 bits. I presume the purpose is to avoid overflow in > > addition , subtraction and mu

Re: [Python-Dev] Impact of Namedtuple on startup time

On Mon, Jul 17, 2017 at 8:00 AM Raymond Hettinger < raymond.hettin...@gmail.com> wrote: > > > On Jul 17, 2017, at 6:31 AM, Antoine Pitrou wrote: > > > >> I think I understand well enough to say something intelligent… > >> > >> While actual references to _source are likely rare (certainly I’ve nev

Re: [Python-Dev] startup time repeated? why not daemon

On Thu, Jul 20, 2017 at 10:56 AM Jim J. Jewett wrote: > I agree that startup time is a problem, but I wonder if some of the pain > could be mitigated by using a persistent process. > This is one strategy that works under some situations, but not all. There are downsides to daemons: * They only

Re: [Python-Dev] Program runs in 12s on Python 2.7, but 5s on Python 3.5 -- why so much difference?

On Mon, Jul 24, 2017 at 1:49 PM Wang, Peter Xihong < peter.xihong.w...@intel.com> wrote: > I believe we have evaluated clang vs gcc before (long time ago), and gcc > won at that time. > > > > PGO might have overshadowed impact from computed goto, and thus the latter > may no longer be needed. > C

Re: [Python-Dev] first post introduction and question regarding lto

I've personally never seen a situation where PGO is not desired yet some other fancier optimization such as LTO is. When do you encounter people wanting that? PGO always produces a 10-20% faster CPython interpreter. I have no problem with patches enabling an LTO only build for anyone who wants on

Re: [Python-Dev] first post introduction and question regarding lto

ilation time. Of course, > > lto is time consuming. To the best of my knowledge, compiling with lto > > only is shorter than combining pgo and lto. > > > > > > > > In this context, I will be more than happy to receive more feedback > > and opinions. > > >

Re: [Python-Dev] PEP 551: Security transparency in the Python runtime

My gut feeling says that there are N interpreters available on just about every bloated system image out there. Multiple pythons are often among them, other we do not control will also continue to exist. I expect a small initial payload can be created that when executed will binary patch the interp

Re: [Python-Dev] Compiling without multithreading support -- still useful?

My take on platforms without thread support is that they should provide a their own fake/green/virtual threading APIs. I don't know how practical that thought actually is for things like web assembly but I'm with Antoine here. The maintenance burden for --without-threads builds is a pain I'd love

Re: [Python-Dev] Consolidate stateful runtime globals

On Wed, Sep 6, 2017 at 10:26 AM Benjamin Peterson wrote: > > On Wed, Sep 6, 2017, at 10:08, Antoine Pitrou wrote: > > On Wed, 06 Sep 2017 09:42:29 -0700 > > Benjamin Peterson wrote: > > > On Wed, Sep 6, 2017, at 03:14, Antoine Pitrou wrote: > > > > > > > > Hello, > > > > > > > > I'm a bit concer

[Python-Dev] Re: Packing a long list of numbers into memory

On Sun, Oct 10, 2021 at 7:25 AM Facundo Batista wrote: > Hello everyone! > > I need to pack a long list of numbers into shared memory, so I thought > about using `struct.pack_into`. > > Its signature is > > struct.pack_into(format, buffer, offset, v1, v2, ...) > > I have a long list of nums (

[Python-Dev] Re: Python release announcement format

On Tue, Dec 14, 2021 at 9:06 AM Yann Droneaud wrote: > Hi, > > I'm not familiar with the Python release process, but looking at the latest > release > https://www.python.org/downloads/release/python-3101/ > > we can see MD5 is still used ... which doesn't sound right in 2021 ... > especially sin

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Thu, Dec 30, 2021 at 4:47 AM Mark Dickinson wrote: > tl;dr: I'd like to deprecate and eventually remove the option to use > 15-bit digits in the PyLong implementation. Before doing so, I'd like to > find out whether there's anyone still using 15-bit PyLong digits, and if > so, why they're doin

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Thu, Dec 30, 2021 at 12:42 PM Gregory P. Smith wrote: > > On Thu, Dec 30, 2021 at 4:47 AM Mark Dickinson wrote: > >> tl;dr: I'd like to deprecate and eventually remove the option to use >> 15-bit digits in the PyLong implementation. Before doing so, I'd like

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

Regarding ABI issues, I don't see anything obvious either. I was probably misremembering the potential marshal issue, which was addressed. struct _longobject (the implementation details behind the public PyLongObject typedef name) and the digit definition are excluded from Py_LIMITED_API. So per

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 2, 2022 at 2:37 AM Mark Dickinson wrote: > On Sat, Jan 1, 2022 at 9:05 PM Antoine Pitrou wrote: > >> Note that ARM is merely an architecture with very diverse >> implementations having quite differing performance characteristics. [...] >> > > Understood. I'd be happy to see timings

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

-gps On Tue, Jan 4, 2022 at 10:59 AM Antoine Pitrou wrote: > >> On Mon, 3 Jan 2022 22:40:25 -0800 >> "Gregory P. Smith" wrote: >> > >> > rerunning a mere few of those in --rigorous mode for more runs does not >> > significantly improve the stdd

[Python-Dev] Re: Sanity check about ctypes

On Wed, Jan 5, 2022 at 3:17 PM Yonatan Zunger wrote: > Hey everyone. > > Quick sanity check: The ctypes docs > refer to > _CData as a non-public class which is in the module, but _ctypes.c doesn't > actually export it >

[Python-Dev] Re: Minor inconvenience: f-string not recognized as docstring

On Tue, Jan 11, 2022 at 10:29 AM Guido van Rossum wrote: > I personally think F-strings should not be usable as docstrings. If you > want a dynamically calculated docstring you should assign it dynamically, > not smuggle it in using a string-like expression. We don't allow "blah {x} > blah".forma

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Fri, Jan 14, 2022 at 9:50 AM Mark Dickinson wrote: > On Sun, Jan 2, 2022 at 10:35 AM Mark Dickinson wrote: > >> Division may still be problematic. >> > > On that note: Python divisions are somewhat crippled even on x64. Assuming > 30-bit digits, the basic building block that's needed for mult

[Python-Dev] Re: Is anyone using 15-bit PyLong digits (PYLONG_BITS_IN_DIGIT=15)?

On Sun, Jan 16, 2022 at 1:51 PM Mark Dickinson wrote: > On Sun, Jan 16, 2022 at 9:28 PM Guido van Rossum wrote: > >> Does the optimization for //10 actually help in the real world? [...] >> > > Yep, I don't know. If 10 is *not* the most common small divisor in real > world code, it must at least

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

On Tue, Jan 18, 2022 at 10:58 PM Christopher Barker wrote: > On Tue, Jan 18, 2022 at 10:30 AM Brett Cannon wrote: > >> I remember that "noisy by default" deprecation warnings were widely >>> despised. >>> >>> One thought, what if they were off by default UNLESS you were doing unit >>> tests? >>

[Python-Dev] Re: Request to revert unittest and configparser incompatible changes in Python 3.11

On Tue, Jan 18, 2022 at 6:24 AM Victor Stinner wrote: > Hi, > > My colleagues Tomáš Hrnčiar and Miro Hrončok made good progress on > updating Python 3.10 to Python 3.11 in Fedora, but some specific > Python 3.11 incompatible changes are causing more troubles than > others: > https://discuss.pytho

[Python-Dev] Re: How about using modern C++ in development of CPython ?

On Thu, Jan 20, 2022 at 8:16 PM Dan Stromberg wrote: > > On Fri, Apr 16, 2021 at 11:13 AM Christian Heimes > wrote: > >> On 16/04/2021 19.14, redrad...@gmail.com wrote: >> > My personal stop of contributing in CPython is that it is written in >> pure C !! >> > I wrote code in both: pure C and C+

[Python-Dev] Re: [Steering-council] Re: PEP 651, Robust Stack Overflow Handling, Rejection notice

-cc: python-steering-council On Fri, Mar 5, 2021 at 4:26 PM Guido van Rossum wrote: > On Fri, Mar 5, 2021 at 11:11 AM Brett Cannon wrote: > >> Speaking for myself ... >> > > Ditto ... > > On Fri, Mar 5, 2021 at 7:04 AM Mark Shannon wrote: >> [...] >> >>> In some cases, the PEP would have impro

[Python-Dev] Re: Moving away from _Py_IDENTIFIER().

On Wed, Feb 2, 2022 at 2:48 PM Eric Snow wrote: > I'm planning on moving us to a simpler, more efficient alternative to > _Py_IDENTIFIER(), but want to see if there are any objections first > before moving ahead. Also see https://bugs.python.org/issue46541. > > _Py_IDENTIFIER() was added in 2011

[Python-Dev] Re: It's now time to deprecate the stdlib urllib module

On Sun, Feb 6, 2022 at 9:13 AM Paul Moore wrote: > On Sun, 6 Feb 2022 at 16:51, Christian Heimes > wrote: > > > The urllib package -- and to some degree also the http package -- are > > constant source of security bugs. The code is old and the parsers for > > HTTP and URLs don't handle edge case

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 11:06 AM Victor Stinner wrote: > Hi Mark, > > Aha, good, you posted an email to python-dev, good :-) Last days, I > was trying to collect more data about this topic, especially find > platforms which *don't* support IEEE 754, before posting to > python-dev. > > Nowadays, ou

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Mon, Feb 7, 2022 at 4:52 PM Christopher Barker wrote: > From the perspective of some that writes a lot of computational code: > > On Mon, Feb 7, 2022 at 10:25 AM Mark Dickinson wrote: > >> - Should we require the presence of NaNs in order for CPython to build? >> - Should we require IEEE 754

[Python-Dev] Re: Replace debug runtime checks in release mode with assertions in debug mode

What does pyperformance say about --enable-optimizations builds with all of those compiled out vs today? I like the runtime safety checking for purposes of making the lives of Python C API users easier. But without the use of assertion enabled CPython builds being the norm during development (we s

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Tue, Feb 8, 2022 at 2:25 PM Steven D'Aprano wrote: > On Mon, Feb 07, 2022 at 05:35:17PM -0800, Gregory P. Smith wrote: > > > CPython: yes. we use a double. > > Python the language: no. (float is single precision on many micropython > > platforms as it saves

[Python-Dev] Re: Should we require IEEE 754 floating-point for CPython?

On Tue, Feb 8, 2022 at 2:41 PM Steven D'Aprano wrote: > On Mon, Feb 07, 2022 at 06:23:52PM +, Mark Dickinson wrote: > > > - Should we require IEEE 754 floating-point for > CPython-the-implementation? > > - Should we require IEEE 754 floating-point for Python-the-language? > > If the answer to

[Python-Dev] Re: Steering Council reply to PEP 670 -- Convert macros to functions in the Python C API

On Wed, Feb 9, 2022 at 8:54 AM Victor Stinner wrote: > On Wed, Feb 9, 2022 at 1:04 PM Petr Viktorin wrote: > > > Right now, a large number of macros cast their argument to a type. A > > > few examples: > > > > > > #define PyObject_TypeCheck(ob, type) > > > PyObject_TypeCheck(_PyObject_CAST(ob),

[Python-Dev] PEP 677 (Callable Type Syntax): Rejection notice.

Thank you PEP authors for producing a very well written and laid out PEP. That made it easy to understand the proposal, rationale, and alternatives considered. We agree that the existing typing.Callable syntax, while capable, is less than ideal for humans. That said, we deliberated last week and ul

[Python-Dev] Re: PEP 677 (Callable Type Syntax): Rejection notice.

essive dead end. Think of it as *attempting* not to accumulate too many ways to do the same thing in the long term. If the 677 proposed syntax had been expanded to include more def features instead of being conservative I think it would've been an even easier rejection for many of us as that would&#x

[Python-Dev] Re: Require a C compiler supporting C99 to build Python 3.11

On Thu, Feb 24, 2022 at 3:27 PM Victor Stinner wrote: > On Thu, Feb 24, 2022 at 11:10 PM Barry wrote: > > > "Python 3.11 and newer versions use C11 without optional features. The > > > public C API should be compatible with C++." > > > https://github.com/python/peps/pull/2309/files > > > > Shoul

[Python-Dev] Re: Need Help

The embedded copy of expat was recently upgraded to 2.4.6 in https://bugs.python.org/issue46794 including on the 3.9 branch. That will wind up in 3.9.11 per https://www.python.org/dev/peps/pep-0596/. If you are using 3.9.5 you may also have a host of other potential security issues that updating

[Python-Dev] Accepting PEP 675 - Arbitrary Literal String Type

On behalf of the Python Steering Council, we are accepting PEP 675 - Arbitrary Literal String Type . TL;DR - PEP 675 allows type checkers to help prevent bugs allowing attacker-controlled data to be passed to APIs that declare themselves as requiring literal, in-

[Python-Dev] Accepting PEP 655 - Marking individual TypedDict items as required or potentially-missing

On behalf of the Python Steering Council, we are pleased to accept PEP 655 - Marking individual TypedDict items as required or potentially-missing . Thanks for considering the potential for confusion with Optional during the design and recommending best practices

[Python-Dev] Re: Changing unittest verbose output.

For many of us, this isn't a nuisance. It is a desirable feature. test_xxx functions and methods typically don't have docstrings at all as the majority of tests tend to be concise and obvious with the function name itself describes what its purpose is. When we added printing the docstring, it was

[Python-Dev] Re: Changing unittest verbose output.

ib/unittest/runner.py#L46 > > On Sun, Mar 27, 2022 at 2:42 PM Gregory P. Smith wrote: > >> For many of us, this isn't a nuisance. It is a desirable feature. >> >> test_xxx functions and methods typically don't have docstrings at all as >> the majority of

[Python-Dev] Re: C API: Move PEP 523 "Adding a frame evaluation API to CPython" private C API to the internal C API

On Fri, Apr 1, 2022 at 2:06 AM Victor Stinner wrote: > Hi, > > Update on this issue: I merged my 2 PRs. > https://bugs.python.org/issue46850 > > The following APIs have been moved to the internal C API: > > - _PyFrameEvalFunction type > - _PyInterpreterState_GetEvalFrameFunc() > - _PyInterpreterS

[Python-Dev] Re: About PEPs being discussed on Discourse

On Thu, Apr 7, 2022 at 4:31 PM Jean Abou Samra wrote: > > I'm only a lurker here, but find the split between this mailing list > and various Discourse categories a little confusing from the outside. > As far as I understand, the Discourse server was originally an experiment. > Today, it has grown

[Python-Dev] Re: PEP 678: Enriching Exceptions with Notes

On Thu, Jan 27, 2022 at 10:10 AM Zac Hatfield Dodds < zac.hatfield.do...@gmail.com> wrote: > Hi all, > > I've written PEP 678, proposing the addition of a __note__ attribute > which can be used to enrich displayed exceptions. This is particularly > useful with ExceptionGroup, or where exception c

[Python-Dev] Re: Proposal to deprecate mailcap

+1 add it to the 3.11 deprecations and proactively reach out to the mitmproxy owners. (internal code search: aside from mitmproxy I only see a _single_ use of this in our codebase and it was simply convenient but has a clear simpler alternative assuming that ~2008 era code is even still in use) -

[Python-Dev] Re: What is Modules/rotatingtree.c for?

On Sun, Apr 24, 2022 at 9:24 AM Patrick Reader <_...@pxeger.com> wrote: > I've just noticed Modules/rotatingtree.{h,c}, which don't seem to be > used anywhere. Are they just dead code? If so, is there a reason they > haven't been removed? > grep -R rotatingtree ; grep -R _lsprof rotatingtree is

[Python-Dev] Re: Starting a new thread

On Tue, May 10, 2022 at 10:34 AM Barney Stratford < barney_stratf...@fastmail.fm> wrote: > > 1. Does t = target(...) start the thread? I think it does. > I think it does too. In the commonest use case, immediately after creating > a thread, you start it. And if you want to delay the thread but sti

[Python-Dev] Re: [OT] Re: Raw strings ending with a backslash

On Sat, May 28, 2022 at 12:55 PM Guido van Rossum wrote: > > On Sat, May 28, 2022 at 12:11 MRAB > > Names in Python are case-sensitive, yet the string prefixes are >> case-/insensitive/. >> >> Why? > > > IIRC we copied this from C for numeric suffixes (0l and 0L are the same; > also hex digits a

[Python-Dev] Re: [Python-Help] Unable to bootstrap Python 3 install

-cc:help (bcc) FWIW the thing to do to move this forward is to open a new PR. Patches attached to an email are lost like tears in the rain. What you describe of cross compilation where host and target triples appear the same but use different libraries is a valid cross compilation case. But doesn

[Python-Dev] Re: Embedded Python Memory Leaks

On Thu, Oct 6, 2022 at 12:48 PM wrote: > Hi Python team > > Is any plan to try and fix memory leaks when embedding Python in a C/C++ > application? > Please file issues on github with details if you find problems. -gps ___ Python-Dev mailing list -- p

[Python-Dev] Re: [CVE-2022-37454] SHA3 vulnerability and upcoming Python patches for 3.7 - 3.10

The patches to 3.6-3.10 have been merged, which means they will go out in the next Python patch release for those updates. ie: https://github.com/python/cpython/issues/98517 You can see the planned schedule of those on https://peps.python.org/pep-0619/ and related similar peps for older python ver

[Python-Dev] Re: RFC: expose ssl internals for use by ctypes/cffi

On Wed, Nov 30, 2022 at 12:47 PM Steve Dower wrote: > On 11/30/2022 4:52 PM, chris...@weinigel.se wrote: > > Does this seem like a good idea? As I said, I feel that it is a bit > ugly, but it does mean that if someone wants to use some > SSL_really_obscure_function in libcrypto or libssl they ca

[Python-Dev] Re: Switching to Discourse

On Thu, Dec 1, 2022 at 8:37 AM Victor Stinner wrote: > > Should we *close* the python-dev mailing list? > I'd be in favor of this. Or at least setting up an auto-responder suggesting people post on discuss.python.org instead. -gps ___ Python-Dev maili

[Python-Dev] Re: Fwd: Python 3.11 performance with frame pointers

I suggest re-posting this on discuss.python.org as more engaged active core devs will pay attention to it there. On Wed, Jan 4, 2023 at 11:12 AM Daan De Meyer wrote: > Hi, > > As part of the proposal to enable frame pointers by default in Fedora > (https://fedoraproject.org/wiki/Changes/fno-omit

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 8:43 AM Guido van Rossum wrote: > This discussion looks like there's no end in sight. Maybe the Steering > Council should take a vote? > I've merged the PR reverting the behavior in 3.8 and am doing the same in the master branch. The sheer volume of email this is generati

[Python-Dev] Re: What to do about invalid escape sequences

On Fri, Aug 9, 2019 at 11:37 AM Eric V. Smith wrote: > On 8/9/2019 2:28 PM, Jonathan Goble wrote: > > On Fri, Aug 9, 2019 at 12:34 PM Nick Coghlan wrote: > >> I find the "Our deprecation warnings were even less visible than > >> normal" argument for extending the deprecation period compelling. >

[Python-Dev] Re: Stalemate on bringing back PEP 523 support into Python 3.8

On Fri, Nov 22, 2019 at 10:10 AM Mark Shannon wrote: > Hi, > > On 21/11/2019 8:04 pm, Brett Cannon wrote: > > An unfortunate side-effect of making PyInterpreterState in Python 3.8 > opaque is it removed [PEP 523](https://www.python.org/dev/peps/pep-0523/) > support. https://www.python.org/dev/pep

<    1   2   3   4   5   6   7   >