[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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 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: 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: 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: 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: 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: 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: 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: 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 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 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: 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: 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: 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/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: 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: 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

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: 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: 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: 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: 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: 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: 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: 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: 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: 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: 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 654 except* formatting

On 10/6/2021 5:05 PM, Yury Selivanov wrote: So I'm -1 on `except group` or any variant that uses soft keywords. If the SC considers making `group` a proper keyword I can possibly change my mind on this. For the record (and I'm sure I'm not the only one), I'm -100 on making it a proper keyword

[Python-Dev] Re: PEP 654 except* formatting

On 10/4/2021 5:47 PM, Antoine Pitrou wrote: On Mon, 4 Oct 2021 12:18:35 -0400 Calvin Spealman wrote: On Mon, Oct 4, 2021 at 12:07 PM Guido van Rossum wrote: The question was about which style to *recommend* (a la PEP-8). I think the very fact that it can't (or is difficult) be enforce

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/27/2021 7:15 PM, Ethan Furman wrote: On 9/27/21 10:50 AM, Guido van Rossum wrote: > So my *actual* proposal (call it #2') is to use a separate compile-time flag, which is set by `./configure > --enable-optimizations` regardless of whether PGO/LTO are possible, and which on Windows can b

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/27/2021 6:40 PM, Patrick Reader wrote: I accidentally a word. "... module's hash and/or *timestamp* and comparing it ..." On 27/09/2021 18:38, Patrick Reader wrote: How about checking each non-frozen module's hash and/or and comparing it to that of the frozen module? Would that defeat th

[Python-Dev] Re: The Default for python -X frozen_modules.

On 9/27/2021 5:51 PM, Eric Snow wrote: 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) Just to air my concerns regarding option 2 (which I've already spoken to Eric about): I feel thi

[Python-Dev] Re: f-strings in the grammar

On 9/21/2021 7:42 PM, Eric V. Smith wrote: I don't recall exactly why, but I disallowed backslashes inside expressions at the last minute before 3.6 was released. It might have been because I was interpreting them in a way that didn't make sense if a "real" parser were inspecting f-strings. The

[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

On 9/13/2021 8:12 PM, Ethan Furman wrote: On 9/13/21 9:03 AM, Steve Dower wrote: > You *are* allowed to put some (brief) details in the abstract. No need to avoid spoilers ;) > > As it stands, "it is time" on its own is a really bad reason to change anything. So you&

[Python-Dev] Re: PEP 663: Improving and Standardizing Enum str(), repr(), and format() behaviors

On 9/11/2021 6:53 AM, Ethan Furman wrote: Abstract Now that we have a few years experience with Enum usage it is time to update the ``repr()``, ``str()``, and ``format()`` of the various enumerations by their intended purpose. You *are* allowed to put some (brief) details in the ab

[Python-Dev] Re: Making code object APIs unstable

On 8/16/2021 12:47 AM, Guido van Rossum wrote: My current proposal is to issue a DeprecationWarning in PyCode_New() and PyCode_NewWithPosArgs(), which can be turned into an error using a command-line flag. If it's made an error, we effectively have (B); by default, we have (A). Then in 3.13 w

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

On 7/29/2021 6:17 PM, Barry Warsaw wrote: On Jul 29, 2021, at 05:55, Steve Dower wrote: Maybe we should have a "Type" other than Standards Track for PEPs that are documenting implementation designs, rather than requirements for standardisation? Wouldn’t Informational fill

[Python-Dev] Re: Repealing PEP 509 (Add a private version to dict)

On 7/29/2021 11:41 AM, Mark Shannon wrote: The dictionary version number is currently unused in CPython and just wastes memory. I am not claiming that we will never need it, just that we shouldn't be required to have it. It should be an internal implementation detail that we can add or remove de

[Python-Dev] Re: [slightly OT] cryptographically strong random.SystemRandom()

On 7/12/2021 4:11 PM, Dan Stromberg wrote: It looks like CPython could do better on Windows: SystemRandom (because of os.urandom()) is good on Linux and mac, but on Windows they use the CryptGenRandom deprecated API Supporting detail: https://docs.microsoft.com/en-us/windows/win32/api/win

[Python-Dev] Re: Is the Python review process flawed?

On 7/1/2021 7:04 PM, Christopher Barker wrote: PS: All that being said, we, as a community, could do better. For instance, someone like me could do high-level triage on bug reports -- I need to set aside some time to do that. In addition/instead of triage, one thing we (as core maintainers) re

[Python-Dev] Re: Making PY_SSIZE_T_CLEAN not mandatory.

On 6/9/2021 2:20 PM, Petr Viktorin wrote: On 09. 06. 21 13:09, Paul Moore wrote: Also, I often use the stable ABI when embedding, so that I can replace the Python interpreter without needing to recompile my application and redeploy new binaries everywhere (my use case is pretty niche, though, so

[Python-Dev] Re: change of behaviour for '.' in sys.path between 3.10.0a7 and 3.10.0b1

On 6/3/2021 7:42 PM, Senthil Kumaran wrote: On Thu, Jun 03, 2021 at 07:08:06PM +0100, Robin Becker wrote: The regression may well be a platform issue. I am by no means an expert at building python; I followed a recipe from the ARCH PKGBUILD of some time I meant the change in the diff we were s

[Python-Dev] Re: GDB not breaking at the right place

On 5/24/2021 9:38 PM, Guido van Rossum wrote: To the contrary, I think if you want the CI jobs to be faster you should add the CFLAGS to the configure call used to run the CI jobs. Big +1 We should have the most useful interactive development/debugging options set by default (or with an obvio

[Python-Dev] Re: Question for potential python development contributions on Windows

When you're installing Visual Studio the C++ tools version is listed under the selected components as "v14x". However, at this stage, the *only* version in circulation is 14.x - mine shows v142. Until the 14 changes to a "15", it will be binary compatible and so you can use any version at all

[Python-Dev] Re: The repr of a sentinel

On 5/21/2021 9:36 AM, Petr Viktorin wrote: On 21. 05. 21 3:23, Eric V. Smith wrote: On 5/20/2021 3:24 PM, Ronald Oussoren via Python-Dev wrote: One example of this is the definition of dataclasses.field: |dataclasses.||field|(/*/, /default=MISSING/, /default_factory=MISSING/, /repr=True/, /ha

[Python-Dev] Re: The repr of a sentinel

On 14May2021 0622, micro codery wrote: There was a discussion a while back ( a year or so?? ) on Python-ideas that introduced the idea of having more "sentinel-like" singletons in Python -- right now, we only have None. Not quite true, we also have Ellipsis, which already has a nic

[Python-Dev] Re: The repr of a sentinel

On 13May2021 1248, Petr Viktorin wrote: On 13. 05. 21 11:45, Antoine Pitrou wrote: Le 13/05/2021 à 11:40, Irit Katriel a écrit : On Thu, May 13, 2021 at 10:28 AM Antoine Pitrou > wrote:  I agree that is a reasonable spelling. I initially suggested , but

[Python-Dev] Re: pth file encoding

On 3/17/2021 7:34 PM, Ivan Pozdeev via Python-Dev wrote: On 17.03.2021 20:30, Steve Dower wrote: On 3/17/2021 8:00 AM, Michał Górny wrote: How about writing paths as bytestrings in the long term?  I think this should eliminate the necessity of knowing the correct encoding for the filesystem

[Python-Dev] Re: pth file encoding

On 3/17/2021 6:08 PM, Stefan Ring wrote: A somewhat radical idea carrying this to the extreme would be to use UTF-16 (LE) on Windows. After all, this _is_ the native file system encoding, and Notepad will happily read and write it. I'm not opposed to detecting a BOM by default (when no other en

[Python-Dev] Re: pth file encoding

On 3/17/2021 8:00 AM, Michał Górny wrote: How about writing paths as bytestrings in the long term? I think this should eliminate the necessity of knowing the correct encoding for the filesystem. That's what we're trying to do, the problem is that they start as strings, and so we need to conve

[Python-Dev] Re: Have virtual environments led to neglect of the actual environment?

On 2/24/2021 4:26 PM, Christian Heimes wrote: On 24/02/2021 15.16, Random832 wrote: On Wed, Feb 24, 2021, at 06:27, Christian Heimes wrote: Separate directories don't prevent clashes and system breakage. But they provide an easy way to *recover* from a broken system. I think it could be turne

[Python-Dev] Re: Move support of legacy platforms/architectures outside Python

On 2/22/2021 5:18 PM, Matthias Klose wrote: On 2/21/21 1:13 PM, Victor Stinner wrote: Document what is supported, be inclusive about anything else. Don't make a distinction yet between legacy and upcoming new architectures. I agree with this, and I don't see any reason why we shouldn't just us

[Python-Dev] Re: PEP 624: Remove Py_UNICODE encoder APIs

On 2/1/2021 5:16 PM, Christian Heimes wrote: On 01/02/2021 17.39, M.-A. Lemburg wrote: Can you explain where wchar_t* type is appropriate and how two conversions is a performance bottleneck? If an extension has a wchar_t* string, it should be easy to convert this in to a Python bytes object fo

[Python-Dev] Re: Why aren't we allowing the use of C11?

On 29Jan2021 1715, Victor Stinner wrote: It seems like declaring a TLS in libpython and using it from an extension module (another dynamic library) is causing issues depending on the linker. It "should" work on macOS, but it doesn't. I'm pretty sure this is not defined in any calling convention

[Python-Dev] Re: Why aren't we allowing the use of C11?

On 29Jan2021 2227, Random832 wrote: On Thu, Jan 28, 2021, at 22:57, Emily Bowman wrote: On Thu, Jan 28, 2021 at 1:31 PM MRAB wrote: I have Microsoft Visual Studio Community 2019 Version 16.8.4 (it's free) and it supports C11 and C17. While an upgrade for Community is free, for Pro/Enterpri

[Python-Dev] Re: New sys.module_names attribute in Python 3.10: list of all stdlib modules

On 1/26/2021 8:32 PM, Steve Holden wrote: If the length of the name is any kind of issue, since the stdlib only contains modules (and packages), why not just sys.stdlib_names? And since the modules can vary between platforms and builds, why wouldn't this be sysconfig.stdlib_names rather than s

[Python-Dev] Re: The SC is accepting PEP 632: deprecating distutils

On 1/21/2021 6:30 PM, Brett Cannon wrote: On behalf of the SC, I'm happy to announce that we have chosen to accept PEP 632. Congrats, Steve, and thanks for the work on the PEP! I'll let Steve outline what the next steps are for implementing the PEP. Thanks. Work from this point on will be tra

[Python-Dev] Re: Enhancement request for PyUnicode proxies

On 12/29/2020 5:23 PM, Antoine Pitrou wrote: The third option is to add a distinct "string view" protocol. There are peculiarities (such as the fact that different objects may have different internal representations - some utf8, some utf16...) that make the buffer protocol suboptimal for this.

[Python-Dev] Re: Where is the SQLite module maintainer

On 12/28/2020 11:32 AM, Erlend Aasland wrote: On 27 Dec 2020, at 22:38, Christian Heimes > wrote: How about you put your name in the expert index instead of him? :) Thanks for your confidence, but I'm far from an expert :) Neither is anyone else :) I'm not lookin

[Python-Dev] Re: Advice / RTFM needed for tool setup to participate in python development from a Windows host

On 16Dec2020 2114, pjfarl...@earthlink.net wrote: If anyone has or knows of step-by-step instructions on how to set that debug environment up and start the outer-level script with debug breakpoints in the DLL I would greatly appreciate it. I'm also doing my own searches for tutorials on debug

[Python-Dev] Re: Who is target reader of tutorial?

e conventional way to store parameters for ML models. --Guido On Fri, Nov 6, 2020 at 8:32 AM Steve Dower <mailto:steve.do...@python.org>> wrote: It would also be nice for the tutorial to separate between "things you need to know to use Python" vs "things

[Python-Dev] Re: Who is target reader of tutorial?

It would also be nice for the tutorial to separate between "things you need to know to use Python" vs "things you need to write a Python library". For example, the fact that operators can do different things for different values (e.g. int, str, list, pathlib) would be in the first category, wh

[Python-Dev] Re: Speeding up CPython

On 22Oct2020 1341, Marco Sulla wrote: On Thu, 22 Oct 2020 at 14:25, Mark Shannon > wrote: MSVC seems to do better jump fusion than GCC. Maybe I'm wrong, since I only take a look at dict, tuple and set C code, but it does not seems to me that there's more than 1-2 GO

[Python-Dev] Re: PEP 640: Unused variable syntax.

On 20Oct2020 1309, Thomas Wouters wrote: The reason for this PEP is that pattern matching will make '_' (but not any other names) have the behaviour suggested in this PEP, but *only* in pattern matching. Then why is this PEP proposing a different syntax? At the very least, wait for pattern ma

[Python-Dev] Re: PEP 640: Unused variable syntax.

On 20Oct2020 1021, Steven D'Aprano wrote: In my opinion, having a convention to treat certain variables as "unused" is great (I'm partial to `__` myself, to avoid clobbering the special variable `_` in the REPL). But having that be a pseudo-variable which is *actually* unused and unuseable strike

[Python-Dev] Re: os.scandir bug in Windows?

On 20Oct2020 0520, Rob Cliffe wrote: On 19/10/2020 12:42, Steve Dower wrote: On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Correction - os.stat() updates the access time to _now_

[Python-Dev] Re: os.scandir bug in Windows?

On 19Oct2020 1846, Eryk Sun wrote: On 10/19/20, Steve Dower wrote: On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Correction - os.stat() updates the access time to _now_, while

[Python-Dev] Re: os.scandir bug in Windows?

On 19Oct2020 1652, Gregory P. Smith wrote: I'm sure this is covered in MSDN.  Linking to that if it has it in a concise explanation would make sense from a note in our docs. Probably unlikely :) I'm pretty sure this started "perfect" and was then wound back to improve performance. But it's alm

[Python-Dev] Re: os.scandir bug in Windows?

On 19Oct2020 1242, Steve Dower wrote: On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Correction - os.stat() updates the access time to _now_, while os.scandir() returns the last

[Python-Dev] Re: os.scandir bug in Windows?

On 15Oct2020 2239, Rob Cliffe via Python-Dev wrote: TLDR: In os.scandir directory entries, atime is always a copy of mtime rather than the actual access time. Correction - os.stat() updates the access time to _now_, while os.scandir() returns the last access time without updating it. Eryk re

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 9/11/2020 12:24 PM, Matthias Klose wrote: On 9/4/20 1:28 PM, Steve Dower wrote: Hi all. setuptools has recently adopted the entire codebase of the distutils module, so that they will be able to make improvements directly without having to rely on patching the standard library. As a result

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 07Sep2020 1602, Stefan Krah wrote: I'm under the impression that distutils has effectively been frozen for the last decade, except for the substantial improvements you made for the MSVC part. For Unix, no one has addressed e.g. C++ support. The underlying reason has always been that we cannot

[Python-Dev] Re: PEP 632: Deprecate distutils module

On 07Sep2020 1424, Stefan Krah wrote: On Mon, Sep 07, 2020 at 11:43:41AM +0100, Steve Dower wrote: Rest assured, I am very aware of air-gapped and limited network systems, as well as corporate policies and processes. Having distutils in the standard library does not help with any of these. Of

[Python-Dev] Re: PEP 632: Deprecate distutils module

Thanks everyone for your input so far. Rest assured, I am very aware of air-gapped and limited network systems, as well as corporate policies and processes. Having distutils in the standard library does not help with any of these. Do not forget that pip (and presently, though not permanently,

[Python-Dev] PEP 632: Deprecate distutils module

iodically check in and skim read it, assuming things don't go way off track). Also be aware that I already have some minor changes lined up that are not in this text. Refer to the discussion on Discourse if you need to see those. Cheers, Steve --- PEP: 632 Title: Deprecate distutils

[Python-Dev] Re: Procedure for trivial PRs

On 8/13/2020 9:56 PM, Mariatta wrote:  a) is it ok to touch 3.9, as it's in rc1? Yeah bug fixes are accepted to the maintenance branches. I think your PR does count as documentation bug fix, so it should be ok to backport to 3.9 At this stage, changes to the 3.9 branch won't go into the

  1   2   3   4   5   6   7   8   >