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

On 29Aug2017 0614, Wes Turner wrote: Wouldn't it be great to have the resources to source audit all code? (And expect everyone to GPG sign all their commits someday.) If you care this much, then you will find the resources to audit all the code manually after you've downloaded it and before yo

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

On 29Aug2017 0801, Steve Dower wrote: On 29Aug2017 0614, Wes Turner wrote: Wouldn't it be great to have the resources to source audit all code? (And expect everyone to GPG sign all their commits someday.) If you care this much, then you will find the resources to audit all the code man

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

Thanks for allowing me to speak for myself, as I said I would when contacted off list :) But as it happens, you've summarised my position very accurately: he now believes the implementation of these operators would lead people to a style of coding which would lead to the proliferation of None

[Python-Dev] Re: PEP 505 (None-aware operators) for Python 3.11

Okay, I'll let myself get sucked into responding ONE TIME, but only because you gave me such a nice API to work with :) On 10/18/2021 9:11 PM, Piotr Waszkiewicz wrote: > class User(DBModel): >    phone: str | None > > class Publisher(DBModel): >   owner: ForeignKey[User] | None > > class

[Python-Dev] Re: Should python-config be an stdlib module?

On 10/25/2021 4:24 PM, Filipe Laíns wrote: So, I guess the existing python-config script just needs to be updated to handle cross compilation properly. Including handling when the cross-compiled Python runtime won't actually run on the platform you're trying to get the config on ;) Over at

[Python-Dev] Re: The current state of typing PEPs

On 11/30/2021 1:16 AM, Guido van Rossum wrote: Why would it need to be reiterated? Are there really people who believe that such code would become invalid? AFAIK *everybody* here agrees that this should stay valid. So who would we be reiterating it for? (Yes, several static type checkers have

[Python-Dev] Re: Expectations of typing (was: The current state of typing PEPs)

On 12/1/2021 12:47 AM, Oscar Benjamin wrote: On Tue, 30 Nov 2021 at 23:37, Guido van Rossum wrote: We should definitely push back on zealous new converts to typing who insist that everything should be annotated. But we should also recognize that even in their current, far from perfect state,

[Python-Dev] Re: Tool to search in the source code of PyPI top 5000 projects

FTR, I don't consider the top projects on PyPI to be representative of our user base, and *especially* not representative of people compiling native modules. This is not a good way to evaluate the impact of breaking changes. It would be far safer to assume that every change is going to break

[Python-Dev] Re: PEP 674: Disallow using macros as l-value

On 12/7/2021 6:52 PM, Sebastian Berg wrote: One thing we once did in NumPy (for a runtime problem), was to intentionally break everyone at pre-release/dev time to point out what code needed fixing. Then flip the switch back at release time as to not break production. After a long enough time we

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

On 1/17/2022 8:47 PM, Barry Scott wrote: On 17 Jan 2022, at 06:35, Tim Peters wrote: [Guido] I don't think there's a way to do a PGO build from Visual Studio; but a command prompt in the repo can do it using `PCbuild\build.bat --pgo`. Just be patient with it. Thanks! That worked, and was

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

On 1/18/2022 2:44 PM, Antoine Pitrou wrote: We propose to revert the following 2 changes in Python 3.11 and postpone them in a later Python version, once most projects will be compatible with these changes: * Removal of unittest aliases (bpo-45162): it broke 61 Fedora packages * Removals from co

[Python-Dev] Re: 3.11 enhanced error location - can it be smarter?

On 1/18/2022 7:59 PM, Pablo Galindo Salgado wrote: We considered using colours and other markers such as bold text, but that opens a considerable can of worms with detecting in all systems and configurations if that can be done. I have been told that some of these situations are quite tricky an

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

Does HPy have any clear guidance or assistance for their users to keep it up to date? I'm concerned that if we simply substitute "support the C API for everyone" with "support the C API for every version of HPy" we're no better off. I think it can be done with clear communication from the HP

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 1/28/2022 5:15 PM, Barry Warsaw wrote: On Jan 28, 2022, at 09:00, Steve Dower wrote: Does HPy have any clear guidance or assistance for their users to keep it up to date? I'm concerned that if we simply substitute "support the C API for everyone" with "support

[Python-Dev] Re: Slowly bend the C API towards the limited API to get a stable ABI for everyone

On 1/28/2022 6:17 PM, Antonio Cuni wrote: Of course, in order to be fully usable, the HPy universal ABI will need special support by PyPI/pip/etc, because at the moment it is impossible to package it inside a wheel, AFAIK. It's totally possible, it's just that none of the existing tools will

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

On 2/4/2022 5:37 PM, Eric Snow wrote: On Thu, Feb 3, 2022 at 3:49 PM Eric Snow wrote: I suppose I'd like to know what the value of _Py_IDENTIFIER() is for 3rd party modules. Between Guido, Victor, Stefan, and Sebastian, I'm getting the sense that a public replacement for _Py_IDENTIFER() would

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

On 04Feb2022 2303, Guido van Rossum wrote: You *can* allocate unicode objects statically. We do it in deepfreeze, and Eric's PR under discussion here (https://github.com/python/cpython/pull/30928 ) does it. I wonder if a better solution than that P

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

On 2/5/2022 4:09 PM, Guido van Rossum wrote: On Sat, Feb 5, 2022 at 5:18 AM Steve Dower <mailto:steve.do...@python.org>> wrote: The gap this has with what I'd like to see is that it will only work for compile-time strings. If instead it could work for an arb

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

On 2/6/2022 4:44 PM, Christian Heimes wrote: If I had the power and time, then I would replace urllib with a simpler, reduced HTTP client that uses platform's HTTP library under the hood (WinHTTP on Windows, NSURLSession (?) on macOS, Web API for Emscripten, maybe curl on Linux/BSD). For non-tr

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

On 2/8/2022 1:35 AM, Gregory P. Smith wrote: While we're at it are  64 bit floats required for either cPython or Python the language? CPython: yes.  we use a double. Python the language: no.  (float is single precision on many micropython platforms as it saves precious ram and performa

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

On 2/8/2022 9:52 AM, Petr Viktorin wrote: On 07. 02. 22 18:09, Victor Stinner wrote: In 2022, C99 is now well supported by C compilers supported by Python: GCC, clang, MSVC. Does MSVC support all of C99? I haven't found any documentation claiming that... but I'm also not familiar with MSVC.

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

On 2/8/2022 9:54 PM, Steven D'Aprano wrote: Regarding your second point, about domain-specific tasks, I don't understand. If your domain-specific task doesn't need to use floats, just don't use floats. There's surely no need to invent a whole new language for some task because your app only needs

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

On 23Feb2022 2240, h.vetin...@gmx.com wrote: On top of that, I think the formulation you chose does not map correctly to actual compiler capabilities. C99 (minus C11 optionals) only arrived in VS2019, there were still gaps in VS2017. Additionally, Visual Studio version doesn't directly map to t

[Python-Dev] Re: Python 3.9.11

We're still working on it. Hopefully it will be today, but we have had other issues arise that have delayed things by a few days (including new critical OpenSSL fixes that were just released yesterday). Cheers, Steve On 15Mar2022 1743, Prasad, PCRaghavendra wrote: Hi Team, Can someone please

[Python-Dev] Re: Restrict the type of __slots__

On 3/18/2022 2:38 PM, Eric V. Smith wrote: There a practical need for these changes. See https://bugs.python.org/issue46382 for a case where dataclasses needs __slots__ to be iterated over after the class has been created. And it would be good if __slots__ accurately reflected the slots that we

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

On 3/22/2022 6:07 PM, Victor Stinner wrote: I proposed two PRs to move the private C API (Include/cpython/) of PEP 523 "Adding a frame evaluation API to CPython" to the internal C API (Include/internals/): After a normal deprecation period, yes? While Pyston didn't bring a JIT compiler to Pyt

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

On 3/22/2022 11:28 PM, Victor Stinner wrote: On Tue, Mar 22, 2022 at 7:33 PM Steve Dower wrote: After a normal deprecation period, yes? There is no backward compatibility warranty and no deprecation process for private APIs. And yet you're asking the question, which means you know

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

I think to most people "batteries included" doesn't necessarily mean "standard library," with all that implies. It just means "it came with the first thing that I installed" (or alternatively, "at no additional charge"). Given there are *plenty* of existing distros out there that install more

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 3/28/2022 7:26 PM, Paul Moore wrote: To be honest, I feel like I'm just reiterating stuff I've said before here, and I think the same is true of the points I'm responding to. Is there actually any new development here, or is it just a repeat of the same positions people have expressed in the p

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

On 3/28/2022 10:44 PM, Jason Ansel via Python-Dev wrote: The PyTorch team plans to use PEP 523 as a part of PyTorch 2.0, so this proposal may break the next major release of PyTorch. The related project is TorchDynamo, which can be found here: https://github.com/facebookresearch/torchdynamo We

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 30Mar2022 1124, Barney Gale wrote: I'd like to become a maintainer for the pathlib module, if possible. I know the code and tests inside-out, and I've been wrestling the internals for past few Python releases. I check the bugs/PRs at least every week and help wherever I can. Antoine is sti

[Python-Dev] Re: Are "Batteries Included" still a Good Thing? [was: It's now time to deprecate the stdlib urllib module]

On 30Mar2022 1132, Baptiste Carvello wrote: Le 28/03/2022 à 18:44, Steve Dower a écrit : I think to most people "batteries included" doesn't necessarily mean "standard library," with all that implies. It just means "it came with the first thing that I instal

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

On 3/30/2022 4:42 PM, Guido van Rossum wrote: In the not so distant past I have proposed to introduce a new category, "Unstable APIs". These are public but are not guaranteed to be backwards compatible in feature releases (though I feel they should remain so in bugfix releases). Agreed. This

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

On 4/1/2022 10:01 AM, Victor Stinner wrote: Update on this issue: I merged my 2 PRs. https://bugs.python.org/issue46850 So what was the point of this discussion then? I don't see any additional discussion on the bug, and the prevailing opinion from actual users of this API is that it probably

[Python-Dev] Re: Make HAMT available to python script

On 4/1/2022 11:48 AM, zhang kai wrote: Thanks Victor and Pablo. I will check the discussion of PEP 603. It's a little weird to use the immutables library when it's code in already in CPython but I'm glad it's an option. The main difference is that 'immutables' offers you a stable/versioned in

[Python-Dev] Re: Make HAMT available to python script

On 02Apr2022 0925, Paul Moore wrote: On Sat, 2 Apr 2022 at 02:30, Christopher Barker wrote: On Fri, Apr 1, 2022 at 4:06 AM Steve Dower wrote: The main difference is that 'immutables' offers you a stable/versioned interface to use it, while the one that's in CPython

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

On 4/5/2022 11:52 PM, Victor Stinner wrote: On Fri, Apr 1, 2022 at 12:36 PM Steve Dower wrote: I don't see any additional discussion on the bug, and the prevailing opinion from actual users of this API is that it probably shouldn't change, From what I understood my change basi

[Python-Dev] Re: Declarative imports

I've read the rest of the thread so far, and agree strongly that we can't do this at the language/runtime level. However ... On 4/8/2022 9:24 AM, Malthe wrote: This is an idea which has been brought up before, sometimes introduced as "heresy". But an interesting twist has surfaced now which is

[Python-Dev] Re: Declarative imports

On 4/8/2022 12:51 PM, Daniel Pope wrote: On Fri, 8 Apr 2022 at 12:23, Steve Dower wrote: I've read the rest of the thread so far, and agree strongly that we can't do this at the language/runtime level. You mean the hoisting, right? I don't see any reason why an import exp

[Python-Dev] Re: Add -P command line option to not add sys.path[0]

On 4/26/2022 10:46 AM, Victor Stinner wrote: I propose adding a -P option to Python command line interface to "not add sys.path[0]": https://github.com/python/cpython/pull/31542 See the documentation in the PR for the exact behavior of this option. I prefer to add an environment variable, only p

[Python-Dev] Re: Using the Python C API in C++

On 5/2/2022 2:21 PM, Victor Stinner wrote: Maybe it should be made optional, but so far I failed to test if distutils has an available C++ compiler. Considering the current status of distutils, you should probably put that check in configure or the Makefile and build the extension from there

[Python-Dev] Re: Test Python 3.11 beta1 with PYTHONSAFEPATH=1

On 5/9/2022 5:24 PM, Victor Stinner wrote: If PYTHONSAFEPATH=1 only breaks a minority of use cases, maybe we can consider to make it the default, as Perl did in Perl 5.26 (2017) to increase its security: https://perldoc.perl.org/perl5260delta#Removal-of-the-current-directory-(%22.%22)-from-@INC

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 5/10/2022 4:33 PM, Christian Heimes wrote: On 10/05/2022 13.18, Victor Stinner wrote: test_peg_generator and test_cppext build C extensions with distutils. Until these tests are modified to use something else, we still need to keep distutils. So I propose to rename it to _distutils to remove

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

scattered around PC, PCbuild and Tools/msi. Easier to just remove it from Lib. Cheers, Steve On 5/10/2022 9:24 PM, Victor Stinner wrote: On Tue, May 10, 2022 at 6:16 PM Steve Dower wrote: I agree. The internal tools that use it are all in our Tools directory, so we can move distutils there and

[Python-Dev] Re: Migration plan for the distutils removal in Python 3.12

On 5/10/2022 9:38 PM, Christopher Barker wrote: So if you can't entirely drop distutils in the stdlib, I don't think we can count on the rest of the community being able to drop it as well. The only reason distutils is used to build Python is for self-bootstrapping. setuptools would have to av

[Python-Dev] Re: Issue: 92359 - Python 3.10 IDLE 64-bit doesn't open any files names code (code.py, code.pyw) - found a partial fix but looking for input

On 5/14/2022 8:37 PM, Terry Reedy wrote: On 5/14/2022 12:40 AM, Guido van Rossum wrote: Probably "Edit with IDLE" should be changed. I have no idea where that is defined. I presume somewhere in PCBuild.  Steve Dower knows and is in charge of the Windows installer. FTR, the beh

[Python-Dev] Re: PEP 689 – Unstable C API tier (was: Semi-stable C API tier)

I prefer separate header files, provided people outside of core always have one (presumably "Python.h") that should be included first and includes enough info to check which headers will be available (i.e. the version defs). Modifying preprocessor definitions for different Python versions, or

[Python-Dev] Re: Accepting PEP 681 – Data Class Transforms

+1. Glad it's not just me On 6/6/2022 2:36 PM, Victor Stinner wrote: First, I understood that "Arbitrary Literal String Type" was adding a new built-in types for "literal strings" :-) Nope. It's just about type annotations ;-) I was also excited about the new built-in type :-) Pablo is alread

[Python-Dev] Re: problem with Distributed File System Replication and Namespacing and different versions of Python 3

On 10/20/2022 1:07 PM, rainonthescarecrowhumanwhe...@gmail.com wrote: What happens is, when injecting into the sys.path the domain names it doesnt import but when injecting into the sys.path the "real" file server path it works, generally speaking. We have been facing this issue in such differe

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

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 can do that without having to rebuild all of CPython themselv

[Python-Dev] Re: C- Python on Windows

On 15Jan2023 0922, Guenther Sohler wrote: Now when i want to get my project compiled in windows, whats the easiest development chain ? Is there something like a python.dll which i can link to my project and having an embedded python interpreter ? Maybe the question is too simple, but i could not

[Python-Dev] Re: Debugging of native extensions on windows

Hi Rokas The typical solution (which I myself use frequently) is to enable your debugger to attach to child processes automatically. It can make things a bit noisier, but it's generally manageable, especially if you've got breakpoints set in your own code. Another option is to not use the vi

[Python-Dev] Re: Debugging of native extensions on windows

On 3/14/2023 7:13 AM, Rokas Kupstys wrote: > Still, i think there can be an improvement in this area, and it would > likely be quite cheap. The biggest problem is people being unaware what > is going on. IsDebuggerPresent()/CheckRemoteDebuggerPresent() could be > used for checking debugger presenc

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

On 09Aug2019 0905, Serhiy Storchaka wrote: 09.08.19 18:30, Guido van Rossum пише: This discussion looks like there's no end in sight. Maybe the Steering Council should take a vote? Possible options: 1. SyntaxWarning in 3.8+ (the current status). 2. DeprecationWarning in 3.8, SyntaxWarning in

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

On 10Aug2019 1544, Glenn Linderman wrote: On 8/10/2019 3:36 PM, Greg Ewing wrote: It might be better to introduce a new string prefix, e.g. 'v' for 'verbatim':    v"C:\Users\Fred\" Which is why I suggested  rr"C:\directory\", but allowed as how there might be better spellings I like your 

[Python-Dev] Re: [Python-checkins] bpo-9949: Enable symlink traversal for ntpath.realpath (GH-15287)

On 21Aug2019 1626, Jeremy Kloth wrote: On Wed, Aug 21, 2019 at 2:43 PM Steve Dower wrote: https://github.com/python/cpython/commit/75e064962ee0e31ec19a8081e9d9cc957baf6415 commit: 75e064962ee0e31ec19a8081e9d9cc957baf6415 branch: master author: Steve Dower committer: GitHub date: 2019-08

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

On 29Aug2019 0152, Armen Michaeli wrote: The installer dialog mentions Python will be installed in something like $USERPROFILE\AppData\Local\Programs\Python\Python37-32 while at the same time suggesting it will be made available for all users through the "Install launcher for all users (recomme

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

On 29Aug2019 0851, Serhiy Storchaka wrote: 29.08.19 18:35, Steve Dower пише: The main reason for making it as a per-machine install by default was because there was no other way to replace the Python 3.4 launcher, but I suspect that's less of an issue now. (If the old one wasn't re

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

Paul answered sufficiently for the venv part, but I wanted to address this point. On 09Sep2019 0621, Kyle Stanley wrote: +1, Particularly on this part. If the user installing Python has administrative access, I don't see much of a reason for them to have to install a separate launcher and ins

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

On 09Sep2019 1950, Glenn Linderman wrote: On 9/9/2019 2:48 AM, Steve Dower wrote: User with administrative privileges are by implication better able to handle decisions such as this. If they are not, they should not be administrating a machine. Most home machines are administered by people

[Python-Dev] Re: Python for Windows (python-3.7.4.exe) location confusing

On 10Sep2019 2120, Jim J. Jewett wrote: Is it possible for the installer to check whether or not there is a pre-existing system-wide launcher, and only do the complicated stuff if it is actually there? I'm not sure what you're referring to here. If there's a pre-existing launcher of the same o

[Python-Dev] Re: The Python 2 death march

On 25Sep2019 2140, Benjamin Peterson wrote: On Wed, Sep 25, 2019, at 17:25, Rob Cliffe via Python-Dev wrote: I additionally share the bemusement of some other commentators on this thread to the idea of Python 2 "support", which is not something ever promised to Python 2 (or 3) users by CPytho

[Python-Dev] Re: PEP 587 (Python Initialization Configuration) updated to be future proof again

On 30Sep2019 1625, Nick Coghlan wrote: After merging your PR and closing mine, I had an idea for Python 3.9: what if we offered a separate public "int Py_CheckVersionCompatibility(uint64_t header_version)" call? (64 bit input rather than 32 to allow for possible future changes to the version n

[Python-Dev] Re: [RELEASE] Python 3.8.0 is now available

On 15Oct2019 1143, MRAB wrote: On 2019-10-15 19:03, MRAB wrote: I've installed pywin32 on Python 3.8, but when I try to import win32clipboard it says it can't find it: Python 3.8.0 (tags/v3.8.0:fa919fd, Oct 14 2019, 19:37:50) [MSC v.1916 64 bit (AMD64)] on win32 Type "help", "copyright", "credi

[Python-Dev] Cleaning the stable ABI [was Accepting PEP 602 -- Annual Release Cycle for Python]

On 30Oct2019 1226, Brett Cannon wrote: * Now that the stable ABI has been cleaned, extension modules should feel more comfortable targeting the stable ABI which should make supporting newer versions of Python much easier I'm taking this as an indication that we should finish https://bugs.pyt

[Python-Dev] Re: Pass the Python thread state to internal C functions

On 13Nov2019 1954, Larry Hastings wrote: On 11/13/19 5:52 AM, Victor Stinner wrote: Le mer. 13 nov. 2019 à 14:28, Larry Hastings a écrit : I did exactly that in the Gilectomy prototype. Pulling it out of TLS was too slow, What do you mean? Getting tstate from a TLS was a performance bottle

[Python-Dev] Re: [RELEASE] Python 3.9.0a1 available for testing

On 19Nov2019 1708, Łukasz Langa wrote: Go get it here: https://www.python.org/downloads/release/python-390a1/ Is it intentional that this link does not appear on https://www.python.org/download/pre-releases/ ? Cheers, Steve __

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21Nov2019 0927, Jason Killen wrote: I sent in a couple of PRs, accepted and merged (Thanks!), lately that switch to using io.open_code when appropriate.  In the process of making those PRs I spent a bit of time reading the two related PEPs.  In PEP-551 there's a suggestion that people use a

[Python-Dev] Re: Restricted Entry Point from PEP-551/578

On 21Nov2019 1337, Jason Killen wrote: I'm good, not discouraged.  Thank you for the explanation I've got my bearings now.  I will try and figure out what's missing with the new config system.  If you have tips or reading material or anything else I should know just send it on otherwise I'll st

[Python-Dev] Re: PEP proposal to limit various aspects of a Python program to one million.

On 03Dec2019 0815, Mark Shannon wrote: Hi Everyone, I am proposing a new PEP, still in draft form, to impose a limit of one million on various aspects of Python programs, such as the lines of code per module. I assume you're aiming for acceptance in just under four months? :) Any thoughts

[Python-Dev] Re: Travis CI for backports not working.

On 06Dec2019 0620, Victor Stinner wrote: What's the status? Right now, I see Travis CI jobs passing on 3.7, 3.8 and master branches so I don't understand the problem. Maybe the issue has been fixed and Travis CI can be made mandatory again? They've been passing fine for me too, I'm not quite su

[Python-Dev] Re: Travis CI for backports not working.

On 06Dec2019 1023, Kyle Stanley wrote: Steve Dower wrote: > As a related aside, I've been getting GitHub Actions support together > (which I started at the sprints). Would adding support for GitHub Actions make it easier/faster to temporarily disable and re-enable specific CI se

[Python-Dev] Re: Travis CI for backports not working.

On 13Dec2019 0233, Victor Stinner wrote: Azure Pipelines were very unstable one year ago. It's getting better, but there are still some random bugs sometimes. They are not really blocking, so I didn't report them. The only ones I'm aware of are macOS builds failing (which don't run on Travis C

[Python-Dev] Re: Should set objects maintain insertion order too?

On 16Dec2019 0417, Petr Viktorin wrote: Originally, making dicts ordered was all about performance (or rather memory efficiency, which falls in the same bucket.) It wasn't added because it's better semantics-wise. Here's one (very simplified and maybe biased) view of the history of dicts: * 2.

[Python-Dev] GitHub Actions enabled (was: Travis CI for backports not working)

On 13Dec2019 0959, Brett Cannon wrote: Steve Dower wrote: If people are generally happy to move PR builds/checks to GitHub Actions, I'm happy to merge https://github.com/zooba/cpython/pull/7 into our active branches (with probably Brett's help) and disable Azure Pipelines? I'

[Python-Dev] Re: Should we pass tstate in the VECTORCALL calling convention before making it public?

On 08Jan2020 0746, Victor Stinner wrote: The question is now if we should "propagate" tstate to function calls in the latest VECTORCALL calling convention (which is currently private). +1, for all the same reasons I'm +1 on passing it to C functions explicitly. (In short, embedding can be very

[Python-Dev] Re: Should we pass tstate in the VECTORCALL calling convention before making it public?

On 09Jan2020 0429, Mark Shannon wrote: There is a one-to-one correspondence between Python threads and O/S threads. So the threadstate can, and should, be stored in a thread local variable. This is a major issue for embedders (and potentially asyncio), as it prevents integration with existing

[Python-Dev] Re: Should we pass tstate in the VECTORCALL calling convention before making it public?

On 09Jan2020 1659, Victor Stinner wrote: Le jeu. 9 janv. 2020 à 19:33, Steve Dower a écrit : Requiring an _active_ Python thread (~GIL held) to only run on a single OS thread is fine, but tying it permanently to a single OS thread makes things very painful. (Of course, this isn't the

[Python-Dev] Re: Request to postpone some Python 3.9 incompatible changes to Python 3.10

On 25Jan.2020 0348, Guido van Rossum wrote: > On Fri, Jan 24, 2020 at 12:12 AM Serhiy Storchaka > wrote: > > I consider breaking unmaintained code is an additional benefit of > removing deprecated features. > > > I'd like to warn against this attitude (even t

[Python-Dev] Re: Azure Pipelines PR: Unresponsive agent

On 01Feb2020 1840, Kyle Stanley wrote: > In a recent PR (https://github.com/python/cpython/pull/18057), I > received the following error message in the Azure Pipelines build results: > > ##[error]We stopped hearing from agent Azure Pipelines 5. Verify the > agent machine is running and has a healt

[Python-Dev] Re: Maintenance of multiprocessing module: there are a few stalled issues/patches

On 13Feb2020 0156, Benjamin Peterson wrote: On Wed, Feb 12, 2020, at 08:22, mailer@app.tempr.email wrote: I've just been looking through the multiprocessing module and open issues and wondered why there were some small bugs/patches not being fixed/merged. Is this the "normal" patch cycle? D

[Python-Dev] Re: Proliferation of tstate arguments.

On 17Mar2020 1447, Mark Shannon wrote: On 16/03/2020 3:04 pm, Victor Stinner wrote: In short, the answer is yes. I said "no" then and gave reasons. AFAICT no one has faulted my reasoning. I said "yes" then and was also not faulted. Let me reiterate why using a thread-local variable is bette

[Python-Dev] Re: Proliferation of tstate arguments.

On 17Mar2020 1803, Chris Angelico wrote: On Wed, Mar 18, 2020 at 3:50 AM Mark Shannon wrote: The accessibility of a thread-local variable is a strict superset of that of a function-local variable. Therefore storing the thread state in a thread-local variable is at least as capable as passing t

[Python-Dev] [bpo-22699] Cross-compiling and fixing sysconfig

So over on https://bugs.python.org/issue22699 I've been talking to myself as I figure out all the ways that cross-compiling (on Ubuntu, targeting another Linux distro via an SDK) fails. In short, it's either because sysconfig can't provide details about any CPython install other than the curre

[Python-Dev] Re: [bpo-22699] Cross-compiling and fixing sysconfig

an Pozdeev via Python-Dev wrote: Last time I checked, distutils didn't support compilation for anything but the running Python instance, nor was it intended to. Should it? If not, the efforts look misplaced, you should rather use a toolchain that does... On 19.03.2020 23:22, Steve Dower wr

[Python-Dev] Re: PEP 616 -- String methods to remove prefixes and suffixes

On 24Mar2020 1849, Brett Cannon wrote: -1 on "cut*" because my brain keeps reading it as "cute". +1 on "trim*" as it is clear what's going on and no confusion with preexisting methods. +1 on "remove*" for the same reasons as "trim*". And if no consensus is reached in this thread for a name I wo

[Python-Dev] Re: Need help with test_ctypes failing on Windows (test_load_dll_with_flags)

FWIW, this test is meant to verify that the old, unsafe DLL load logic still works. I suspect what has happened here is that a new VM image has been rolled out and another app has installed an incompatible _sqlite3.dll on PATH (most likely another copy of Python :) ), thereby proving why the o

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 10Apr2020 2055, Antoine Pitrou wrote: On Fri, 10 Apr 2020 19:20:00 +0200 Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. Using Cython does not make the C API irrelevan

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 0111, Victor Stinner wrote: Steve: the use case is to debug very rare Python crashes (ex: once every two months) of customers who fail to provide a reproducer. My *expectation* is that a debug build should help to reproduce the bug and/or provide more information when the bug happens

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 1156, Rhodri James wrote: On 10/04/2020 18:20, Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C extensions which cannot be rewritten with Cython. If this is true, the documentation on python.org needs a serious

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 11Apr2020 0025, Antoine Pitrou wrote: On Fri, 10 Apr 2020 23:33:28 +0100 Steve Dower wrote: On 10Apr2020 2055, Antoine Pitrou wrote: On Fri, 10 Apr 2020 19:20:00 +0200 Victor Stinner wrote: Note: Cython and cffi should be preferred to write new C extensions. This PEP is about existing C

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1157, Antoine Pitrou wrote: On Mon, 13 Apr 2020 11:35:34 +0100 Steve Dower wrote: and this code that they're using doesn't have any system dependencies that differ in debug builds (spoiler: they do). Are you talking about Windows? On non-Windows systems, I don't

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1122, Steve Dower wrote: On 11Apr2020 0111, Victor Stinner wrote: Steve: the use case is to debug very rare Python crashes (ex: once every two months) of customers who fail to provide a reproducer. My *expectation* is that a debug build should help to reproduce the bug and/or

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 1325, Paul Moore wrote: Personally, I'd say that "recommended 3rd party tools" reads as saying "if you want a 3rd party tool to build extensions, these are good (and are a lot easier than using the raw C API)". That's a lot different than saying "we recommend that people writing C ex

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 2105, Chris Meyer wrote: How would I call a Python function from the C++ application that returns a Python object to C++ and then call a method on that Python object from C++? My specific example is that I create Python handlers for Qt windows and then from the Qt/C++ I call meth

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 13Apr2020 2308, André Malo wrote: For one thing, if you open up APIs for Cython, they're open for everybody (Cython being "just" another C extension). More to the point: The ABIs have the same problem as they have now, regardless how responsive the Cython developers are. Once you compiled the

[Python-Dev] Re: PEP: Modify the C API to hide implementation details

On 14Apr2020 1557, André Malo wrote: Stefan Behnel wrote: André Malo schrieb am 14.04.20 um 13:39: A good way to test that promise (or other implications like performance) might also be to rewrite the standard library extensions in Cython and see where it leads. Not sure I understand wha

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 27Apr2020 2237, t...@tomforb.es wrote: 2. Special casing "lru_cache" to account for zero arity methods isn't trivial and we shouldn't endorse lru_cache as a way of achieving "call_once" semantics Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 27Apr2020 2311, Tom Forbes wrote: Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object. It’s not that it’s impossible, but I didn’t think the current implementation doesn’t make it easy This is the line I'd chang

[Python-Dev] Re: Adding a "call_once" decorator to functools

On 28Apr2020 1243, Petr Viktorin wrote: On 2020-04-28 00:26, Steve Dower wrote: On 27Apr2020 2311, Tom Forbes wrote: Why not? It's a decorator, isn't it? Just make it check for number of arguments at decoration time and return a different object. It’s not that it’s impossible, bu

<    2   3   4   5   6   7   8   >