[Python-Dev] Re: PEP 622 version 2 (Structural Pattern Matching)

On 07Aug2020 2133, Joao S. O. Bueno wrote: Enough cheaptalk - links are here: tests: https://github.com/jsbueno/terminedia/blob/fa5ac012a7b93a2abe26ff6ca41dbd5f5449cb0b/tests/test_utils.py#L356 Branch comparison for the match/case version: https://github.com/jsbueno/terminedia/compare/patma

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

Thanks. It looks like we can do it later this week and make the next round of releases. Please let us know asap if anything comes up that you wouldn't want to be released. Cheers, Steve On 01Aug2020 1632, Sumana Harihareswara wrote: Steve Dower asked: Do you think we should be updating

[Python-Dev] Re: Fwd: [pypi-announce] upgrade to pip 20.2 -- plus changes coming in 20.3

Do you think we should be updating the version of pip bundled with Python 3.9 at this stage (for the first RC)? Similarly, is there a need to update Python 3.8 for its next release? Thanks, Steve On 30Jul2020 2119, Sumana Harihareswara wrote: A new pip is out. Please see below, upgrade, and

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 25Jul2020 2014, Jim J. Jewett wrote: But it sounds as though you are saying the benefit is irrelevant; it is just inherently too expensive to ask programs that are already dealing with internals and trying to optimize performance to make a mechanical change from: code.magic_attrname

[Python-Dev] Re: PEP 626: Precise line numbers for debugging and other tools.

On 22Jul2020 1319, Mark Shannon wrote: On 21/07/2020 9:46 pm, Gregory P. Smith wrote: Q: Why can't we have the information about the entire span of lines rather than consider a definition to be a "line"? Pretty much every profiler, coverage tool, and debugger ever expects lines to be

[Python-Dev] Re: How to customize CPython to a minimal set

On 21Jul2020 0633, Huang, Yang wrote: Yes. Micropyhton is also in consideration. But sqlite3 is the first usage. There should be some additional features like numpy, scipy... Not sure if micropython supports well? Or is there a feasible way to strip CPython ? Only by manually removing

[Python-Dev] Re: os.add_dll_directory and DLL search order

On 22Jun2020 1646, Steve Dower wrote: DLLs should not be in the search path at all - it's searched by sys.path when importing .pyd files, which are loaded by absolute path and their dependencies found adjacent. To clarify this - by "DLLs" I meant the DLLs directory, not DLLs i

[Python-Dev] Re: os.add_dll_directory and DLL search order

On 22Jun2020 1039, Seth G wrote: However, there is one feature of using the Windows PATH that I can't seem to replicate with add_dll_directory. The MapServer DLL builds are linked to sqlite3 3.24.0, whereas Python 3.8.2 is linked to 2.6.0. Building with matching versions is not something I can

[Python-Dev] Re: Design and Architecture of python

If you're not willing to slog through the source code and many PEPs and past discussions, Anthony Shaw has done it for you and written a book: https://realpython.com/products/cpython-internals-book/ All the other write-ups I'm aware of are very dated, so I don't have any free suggestions I'm

[Python-Dev] Re: When can we remove wchar_t* cache from string?

On 16Jun2020 1641, Inada Naoki wrote: * This change doesn't affect to pure Python packages. * Most of the rest uses Cython. Since I already report an issue to Cython, regenerating with new Cython release fixes them. The precedent set in our last release with tp_print was that regenerating

[Python-Dev] Re: My take on multiple interpreters (Was: Should we be making so many changes in pursuit of PEP 554?)

On 12Jun2020 1008, Paul Moore wrote: On Fri, 12 Jun 2020 at 09:47, Mark Shannon wrote: Starting a new process is cheap. On my machine, starting a new Python process takes under 1ms and uses a few Mbytes. Is that on Windows or Unix? Traditionally, process creation has been costly on Windows,

[Python-Dev] Re: PEP 618: Add Optional Length-Checking To zip

On 02Jun2020 1430, David Mertz wrote: On Tue, Jun 2, 2020 at 8:07 AM Chris Angelico > wrote: > Given that the only input parameters are the iterables themselves, it's a stretch to even consider the first two as possibilities. Why? I can conceivably

[Python-Dev] Re: A PEP PR that I closed until someone discusses context

On 06May2020 2204, joannah nanjekye wrote: I saw a PR on the PEP repository that looked like a joke here : https://github.com/python/peps/pull/1396 The author can give context to re-open if it was intentional. Given there isn't a real email address on the PEP, I'd assume it was meant as a

[Python-Dev] Remove ctypes from uuid

For those who haven't looked in a while, the uuid module uses ctypes to look up libuuid for uuid_generate_time_safe() and uuid_generate_time() functions. I've run into scenarios where I need to remove this from our own builds, but it seems like it's probably unnecessary anyway? It's certainly

[Python-Dev] Re: killing static types (for sub-interpreters?)

On 28Apr2020 2006, Steve Dower wrote: (For those who aren't following it, there's a discussion with a patch and benchmarks going on at https://bugs.python.org/issue40255 about making objects individually immortal. It's more focused around copy-on-write, rather than subinterpreters

[Python-Dev] Re: killing static types (for sub-interpreters?)

If the object is going to live until the "end of time" (process/runtime/whatever) then there'll never be a need to deallocate it, and so there's no point counting how many references exist (and ditto for anything that it references). Currently, statically allocated types include references to

[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, but I didn’t

[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

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

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

[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

[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

[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 think

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

[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

[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

[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

[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

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

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 wrote: So over

[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

[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

[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

[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?

[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

[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

[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 only

[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

[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] 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'm personally up

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

[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

[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 service

[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

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

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

[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

[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",

[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

[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

[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

[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

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

[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 replaced

[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

[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: 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: 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 07Aug2019 0247, Chris Angelico wrote: On Wed, Aug 7, 2019 at 7:33 PM Steven D'Aprano wrote: What's the rush? Let's be objective here: what benefit are we going to get from this change? Is there anyone hanging out desperately for "\d" and "\-" to become SyntaxErrors, so they can... do what?

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

On 06Aug2019 0959, Neil Schemenauer wrote: Could PyPI and pip gain the ability to warn and even fix these issues? Having a warning from pip at install time could be better than a warning at import time. If linting was built into PyPI, we could even do a census to see how many packages would be

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

On 04Aug2019 2122, raymond.hettin...@gmail.com wrote: We should revisit what we want to do (if anything) about invalid escape sequences. For Python 3.8, the DeprecationWarning was converted to a SyntaxWarning which is visible by default. The intention is to make it a SyntaxError in Python

[Python-Dev] Re:  New keyword in bpo: `newcomer friendly`

On 26Jul.2019 1909, Guido van Rossum wrote: > See the thread 'The trouble with "Easy" issues' in > core-mentors...@python.org . > Essentially those "easy" issues aren't so easy, and we're starting over. Couldn't that be achieved just as easily by removing the

[Python-Dev] Re: What is a public API?

On 23Jul2019 1128, Kyle Stanley wrote: Barry Warsaw wrote: My package has a C version. If public() were a builtin (which I’ve implemented) it wouldn’t have that much import time overhead. Is there a way we could estimate the approximate difference in overhead this would add using

[Python-Dev] Re: What is a public API?

On 22Jul2019 2051, Kyle Stanley wrote: Also, is the rule "unless explicitly documented public, all imports are private even if not prefixed with an underscore" officially stated anywhere, or is it mostly implied? Personally, I think that it should be explicitly stated in a public manner if

[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source

On 23Jul2019 0812, Kacvinsky, Tom wrote: Tests passed once I used the right Visual Studio Command prompt. I was using the x64 Native toolchain command shell. Once I switched to the generic command shell, all is well. Thanks for the lick in the right direction, it got me to thinking that

[Python-Dev] Re: Python 3.7.4, Visual Studio versions for building modules from source

On 22Jul.2019 0825, Kacvinsky, Tom wrote: > HI, > > Not sure if this is the right place to ask, but I am trying to build > pywin32-224 from source for Python 3.7.4. I think this might > be the right list as this seems to be a generic problem I am having, but I > want to focus on one particular

[Python-Dev] Re: bpo-37468: make install no longer install wininst-*.exe files

We've tried this before, but apparently people were cross-compiling. I'd suggest not removing them any faster than whatever deprecation applies to the module on all platforms (which should still be as quickly as possible :-) ). Cheers, Steve On Mon, Jul 15, 2019 at 5:26 PM +0200,

[Python-Dev] Re: Annoying user on GitHub

On 02Jul2019 0840, Mariatta wrote: I've used the "Report abuse" feature on GitHub for such situations. Most of the time I see the user suspended, and the associated comments deleted. Our GitHub admins can delete comments too. On Tue, Jul 2, 2019, 1:42 AM Victor Stinner

[Python-Dev] Re: strip behavior provides inconsistent results with certain strings

On 02Jul2019 0707, brian.sk...@gmail.com wrote: Taking swapping a file extension as an example of a particular transformation of interest, it would be achieved with something like s.replace(".htm", ".html", only_end=True). Please don't use string functions for file system paths, they are not

[Python-Dev] Re: Sponsoring Python development via the PSF

On 26Jun2019 1006, Ivan Pozdeev via Python-Dev wrote: +1. That's why I never donate to charity. I can't see or control what my money is going to be used for. That's not charity then, it's a purchase or an investment. On 26.06.2019 10:41, Pau Freixes wrote: Why not the other way around? Having

[Python-Dev] Re: v3.8b1 Breaks PyQt on Windows (Issue 36085/os.add_dll_directory())

On 22Jun.2019 1404, Phil Thompson wrote: > The implementation of issue 36085 breaks PyQt on Windows as it relies on > PATH to find the Qt DLLs. The problem is that PyQt is built using the > stable ABI and a single wheel is supposed to support all versions of > Python starting with v3.5. On the

[Python-Dev] Re: Who uses libpython38.a on Windows?

On 14Jun2019 1930, MRAB wrote: I'm able to build the regex module without it; in fact, I believe I've been able to do so since Python 3.5! This is about the only specific feedback I've received (including on Twitter, where most reactions were "I have no idea what file you're talking about"),

[Python-Dev] Re: _Py_Identifier should support non-ASCII string?

On 20Jun2019 0205, Inada Naoki wrote: Hi, all. Both of PyUnicdoe_FromString() and _Py_Identifier are supporting UTF-8 for now. We can not change PyUnicode_FromString() for backward compatibility, so we have _PyUnicode_FromASCII instead. But _Py_Identifier is still private. And non-ASCII

[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?

On 19Jun2019 0124, Steve Holden wrote: I just posted a webmaster reply about just such an inquiry. As one of the people who get to do the explaining, it would be nice if we (not the devs) could figure out some way of getting people to the download they want. Probably the easiest thing to do

[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?

On 18Jun2019 1025, Stephen J. Turnbull wrote: Oleg Broytman writes: > On Tue, Jun 18, 2019 at 10:09:59AM -, smartmanoj42...@gmail.com wrote: > > Why don't we check the architecture using js and provide the > > appropriate version? > >Because the downloading computer is not

[Python-Dev] Re: why is not 64-bit installer the default download link for Windows?

On 18Jun2019 0309, smartmanoj42...@gmail.com wrote: why is not 64-bit installer the default download link for Windows? Because there are still 32-bit operating systems out there, and the 32-bit version of Python will work just fine on both 32 and 64-bit Windows (and will use less memory than

[Python-Dev] Re: How to (best) organize platform dependent blocks of Python code

On 16Jun2019 2354, Michael wrote: CONCERN: How to organize platform dependent blocks of code POLICY/RECOMMENDATION: (today) seems to be: arbitrary, although sys.platform, seems to be the favorite. * I, as 'python-consumer' was very surprised when I learned that sys.platform is "set" when Python

[Python-Dev] Who uses libpython38.a on Windows?

One of the most annoying steps in building the Windows installers is generating the libpython38.a file. It's annoying, because it requires having "generic enough" MinGW tools to ensure that the file is compatible with whatever version of MinGW might be trying to build against the regular

[Python-Dev] EuroPython 2019 sprints

Hi all Just letting everyone know that I signed up any core devs who are going to be at EuroPython to run sprints :) (including myself, since I'll be there) Like PyCon US, the sprints at EuroPython will attract many first-time contributors, so it will be helpful to have as many people who

[Python-Dev] Re: PyAPI_FUNC() is needed to private APIs?

On 13Jun2019 0816, Jeroen Demeyer wrote: On 2019-06-13 17:11, Steve Dower wrote: The cost of that convenience is that we can never optimise internals because they are now public API. I think that the opposite is true actually: the reason that people access internals is because

[Python-Dev] Re: PyAPI_FUNC() is needed to private APIs?

On 13Jun2019 0643, Jeroen Demeyer wrote: On 2019-06-13 15:36, Victor Stinner wrote: The main risk is that people start to use it If people use it, it should be taken as a sign that the function is useful and deserves to be public API. If it's useful, then someone can write a justification

[Python-Dev] Re: Enum and annotations

On 10Jun2019 1429, Ethan Furman wrote: I saw my first annotation mix-up with regards to Enum today:   https://stackoverflow.com/q/56532591/208880     #enum import:     from enum import Enum     # enum definition:     class Status(Enum):     on: 1     off: 2 For those who

[Python-Dev] Re: PEP 594: update 1

On 04Jun2019 1721, Victor Stinner wrote: So what is happening for this PEP since Python 3.8 beta1 has been released? Is it too late for Python 3.8 or not? It seems like most people are confused by the intent of the PEP. IMHO it would be better to rewrite "Remove packages from the stdlib" as

Re: [Python-Dev] PEP 590: vectorcall without tp_call

On 29May2019 1311, Petr Viktorin wrote: On 5/29/19 3:36 PM, Jeroen Demeyer wrote: On 2019-05-29 15:29, Petr Viktorin wrote: That sounds like a good idea for PyType_FromSpec. I don't think we're planning to support vectorcall in PyType_FromSpec for now. That's maybe for 3.9 when vectorcall

Re: [Python-Dev] PEP 594 - a proposal for unmaintained modules

On 23May2019 2355, Steven D'Aprano wrote: I don't know if this is a good idea or a terrible idea or somewhere in between, so I'm throwing it out to see if anyone likes it. Let's add a third option to PEP 594 between "keep" and "remove": explicitly flagging a module as unmaintained. Unmaintained

Re: [Python-Dev] Python in next Windows 10 update

On 24May2019 0220, Baptiste Carvello wrote: Hello, Le 21/05/2019 à 22:30, Steve Dower a écrit : [...] * the Python 3.7 installed from the store will not auto-update to 3.8, but when 3.8 is released we (Microsoft) will update the redirect to point at it * if you pass arguments to the redirect

Re: [Python-Dev] PEP 594: update 1

On 23May2019 0947, Anders Munch wrote: Fra: Paul Moore [mailto:p.f.mo...@gmail.com]: A major version change serves as a heads up that something is going on and you need to check the consequences before upgrading. Python's backward compatibility policy allows breaking changes between versions

Re: [Python-Dev] PEP 558: Defined semantics for locals()

On 23May2019 0636, Nick Coghlan wrote: However, I think the PR does show that the proposed technique can be implemented without too much additional code complexity, and will hopefully be adaptable for all implementations that emulate the frame API at all. Much excitement! One of the things I

Re: [Python-Dev] Have a big machine and spare time? Here's a possible Python bug.

On 23May2019 0542, Inada Naoki wrote: 1. perf shows 95% of CPU time is eaten by _PyObject_Free, not kernel space. 2. This loop is cleary hot: https://github.com/python/cpython/blob/51aa35e9e17eef60d04add9619fe2a7eb938358c/Objects/obmalloc.c#L1816-L1819 I can attach the process by gdb and I

Re: [Python-Dev] Python in next Windows 10 update

On 22May2019 1309, Ivan Pozdeev via Python-Dev wrote: As someone whose job is to diagnose and fix problems with running software: Are there patches in your release? Do you provide corresponding sources and debug symbols for it? You can find the sources at https://github.com/python/cpython :)

Re: [Python-Dev] Python in next Windows 10 update

On 22May2019 1237, Oscar Benjamin wrote: On Tue, 21 May 2019 at 21:32, Steve Dower wrote: In the next Windows 10 update that starts rolling out today, we (Microsoft) have added "python.exe" and "python3.exe" commands that are installed on PATH *by default* and will open

Re: [Python-Dev] Python in next Windows 10 update

On 21May2019 1621, MRAB wrote: Does it behave nicely with py.exe? This is still something of an open issue with the Store package for Python - py.exe doesn't look for the registry keys in a way that will find them (due to some very obscure compatibility quirks). The Store package does not

[Python-Dev] Python in next Windows 10 update

Hi all Just sharing this here because I think it's important for us to be aware of it - I'm not trying to promote or sell anything here :) (Those who were at the language summit have seen this already.) In the next Windows 10 update that starts rolling out today, we (Microsoft) have added

Re: [Python-Dev] Parser module in the stdlib

On 16May2019 1548, Pablo Galindo Salgado wrote: > Will the folks using forks be happy to switch to the stdlib version? For example I can imagine that if black wants to process 3.7 input code while running on 3.6, it might prefer a parser on PyPI even if he stdlib version were public, since the

Re: [Python-Dev] bpo-36829: Add sys.unraisablehook()

On 16May2019 1441, Victor Stinner wrote: Le jeu. 16 mai 2019 à 23:17, Steve Dower a écrit : You go on to say "pass an error message" and "keep repr(obj) if you want", but how is this different from creating an exception that contains the custom message, the repr of th

<    1   2   3   4   5   6   7   8   >