[issue21536] extension built with a shared python cannot be loaded with a static python

Change by Antoine Pitrou : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue21536> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue36666] threading.Thread should have way to catch an exception thrown within

Antoine Pitrou added the comment: The current behavior can't be changed for compatibility reasons (imagine user programs starting to raise on Thread.join()), but we could add an option to the threading.Thread() constructor in order to store and propagate exceptions. -- nosy

[issue36666] threading.Thread should have way to catch an exception thrown within

Change by Antoine Pitrou : -- nosy: +tim.peters type: -> enhancement versions: +Python 3.8 -Python 3.7 ___ Python tracker <https://bugs.python.org/issu

[issue34814] makesetup: must link C extensions to libpython when compiled in shared mode

Antoine Pitrou added the comment: What do you mean, "no consensus could be found"? I don't see anyone objecting the change. -- ___ Python tracker <https://bugs.python.o

[issue36346] Prepare for removing the legacy Unicode C API

Antoine Pitrou added the comment: > The proposed PR adds two compile time options: HAVE_UNICODE_WCHAR_CACHE and > USE_UNICODE_WCHAR_CACHE I don't think this is a good approach. Most projects and developers don't recompile Python. It's especially a chore when you have many depend

[issue36368] server process of shared_memory shuts down if KeyboardInterrupt

Antoine Pitrou added the comment: Sorry - I meant make a *PR* out of it :-) -- ___ Python tracker <https://bugs.python.org/issue36368> ___ ___ Python-bugs-list m

[issue36368] server process of shared_memory shuts down if KeyboardInterrupt

Antoine Pitrou added the comment: Your patch sounds good on the principle, but can you make a patch out of it? -- ___ Python tracker <https://bugs.python.org/issue36

[issue35943] PyImport_GetModule() can return partially-initialized module

Change by Antoine Pitrou : -- nosy: +vstinner ___ Python tracker <https://bugs.python.org/issue35943> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: This is pushed to 3.7 and master now. Thank you Tim for the report and the fix! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -Python 3.6 ___ Python tracke

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: New changeset 3129432845948fdcab1e05042e99a19e9e2c3c71 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-34572: change _pickle unpickling to use import rather than retrieving from sys.modules (GH-9047) (GH-11921) https://github.com/python

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: New changeset 4371c0a9c0848f7a0947d43f26f234842b41efdf by Antoine Pitrou (tjb900) in branch 'master': bpo-34572: change _pickle unpickling to use import rather than retrieving from sys.modules (GH-9047) https://github.com/python/cpython/commit

[issue31829] Portability issues with pickle

Antoine Pitrou added the comment: I am not particularly interested in making Python 2 or ancient pickle protocols easier to use, sorry ;-) -- ___ Python tracker <https://bugs.python.org/issue31

[issue1054041] Python doesn't exit with proper resultcode on SIGINT

Antoine Pitrou added the comment: I'm assuming the calling shell uses waitpid() and then WIFSIGNALED()? -- ___ Python tracker <https://bugs.python.org/issue1054

[issue35983] tp_dealloc trashcan shouldn't be called for subclasses

Antoine Pitrou added the comment: By "relatively new thing", you mean less than 20 years old? :-) -- ___ Python tracker <https://bugs.python.o

[issue35967] Better platform.processor support

Antoine Pitrou added the comment: Your proposal sounds fine to me. You could fall back on platform.machine() instead of calling `uname` explicitly. -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue35

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: > SharedMemoryManager does not subclass SyncManager but it did previously. Ah, right. Then it's ok to change the tests IMO. -- ___ Python tracker <https://bugs.python.org/issu

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: Davin: > This is my fault because I altered SharedMemoryManager to no longer support > functionality from SyncManager that I thought could be confusing to include. > I am just now discovering this and am not immediately sure if simply

[issue2771] Test issue

Antoine Pitrou added the comment: notifying a lot of people -- ___ Python tracker <https://bugs.python.org/issue2771> ___ ___ Python-bugs-list mailing list Unsub

[issue35918] multiprocessing's SyncManager.dict.has_key() method is broken

Antoine Pitrou added the comment: That sounds fine to me. -- ___ Python tracker <https://bugs.python.org/issue35918> ___ ___ Python-bugs-list mailing list Unsub

[issue16353] add function to os module for getting path to default shell

Antoine Pitrou added the comment: I think the functionality of getting either the system-wide default shell or the current user's default shell can be useful regardless of whether the specific subprocess issue was fixed. -- nosy: +ncoghlan stage: patch review -> needs patch versi

[issue35943] PyImport_GetModule() can return partially-initialized module

Change by Antoine Pitrou : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue35943> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: Opened issue35943 for PyImport_GetModule(). -- ___ Python tracker <https://bugs.python.org/issue34572> ___ ___ Python-bug

[issue35943] PyImport_GetModule() can return partially-initialized module

New submission from Antoine Pitrou : PyImport_GetModule() returns whatever is in sys.modules, even if the module is still importing and therefore only partially initialized. One possibility is to reuse the optimization already done in PyImport_ImportModuleLevelObject

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: I agree that more generally PyImport_GetModule() should be fixed. But it should be done carefully so as to not to lose the performance benefit of doing it. I think we should open a separate issue about that. PS: one possibility is to reuse

[issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict)

Antoine Pitrou added the comment: You can have both a dict and slots by subclassing: >>> class A: ...: __slot

[issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary

Antoine Pitrou added the comment: New changeset 48769a28ad6ef4183508951fa6a378531ace26a4 by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-35615: Fix crashes when copying a Weak{Key,Value}Dictionary. (GH-11384) (GH-11785) https://github.com/python/cpython/commit

[issue35615] "RuntimeError: Dictionary changed size during iteration" when copying a WeakValueDictionary

Antoine Pitrou added the comment: New changeset 96d37dbcd23e65a7a57819aeced9034296ef747e by Antoine Pitrou (Fish) in branch 'master': bpo-35615: Fix crashes when copying a Weak{Key,Value}Dictionary. (GH-11384) https://github.com/python/cpython/commit/96d37dbcd23e65a7a57819aeced9034296ef747e

[issue35911] add a cell construtor, and expose the cell type in Lib/types.py

Change by Antoine Pitrou : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue35911] add a cell construtor, and expose the cell type in Lib/types.py

Antoine Pitrou added the comment: New changeset df8d2cde63c865446468351f8f648e1c7bd45109 by Antoine Pitrou (Pierre Glaser) in branch 'master': bpo-35911: add cell constructor (GH-11771) https://github.com/python/cpython/commit/df8d2cde63c865446468351f8f648e1c7bd45109

[issue35933] python doc does not say that the state kwarg in Pickler.save_reduce can be a tuple (and not only a dict)

Antoine Pitrou added the comment: Does it still work? With both the C and Python pickler? Can you post an example? -- ___ Python tracker <https://bugs.python.org/issue35

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: (also, OSError will automatically convert to more specific subclasses for some errnos, see PEP 3151: >>> raise OSError(errno.ENOENT

[issue34572] C unpickling bypasses import thread safety

Change by Antoine Pitrou : -- nosy: +brett.cannon, eric.snow, ncoghlan ___ Python tracker <https://bugs.python.org/issue34572> ___ ___ Python-bugs-list mailin

[issue34572] C unpickling bypasses import thread safety

Antoine Pitrou added the comment: Interesting I could not reproduce here, even by throwing Pandas into the mix and spawning 1024 workers... -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue34

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Antoine Pitrou added the comment: New changeset 15526f5be72f547288c16d53526fc74f15ee61ed by Antoine Pitrou in branch '3.7': [3.7] bpo-35917: Test multiprocessing manager classes and shareable types (GH-11772) (GH-11780) https://github.com/python/cpython/commit

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Antoine Pitrou added the comment: Thanks Giampaolo! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker <https://bugs.python.or

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Change by Antoine Pitrou : -- pull_requests: +11761, 11762, 11763 ___ Python tracker <https://bugs.python.org/issue35917> ___ ___ Python-bugs-list mailin

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Change by Antoine Pitrou : -- pull_requests: +11761 ___ Python tracker <https://bugs.python.org/issue35917> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Change by Antoine Pitrou : -- pull_requests: +11761, 11762 ___ Python tracker <https://bugs.python.org/issue35917> ___ ___ Python-bugs-list mailing list Unsub

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Antoine Pitrou added the comment: New changeset 2848d9d29914948621bce26bf0d9a89f2e19b97b by Antoine Pitrou (Giampaolo Rodola) in branch 'master': bpo-35917: Test multiprocessing manager classes and shareable types (GH-11772) https://github.com/python/cpython/commit

[issue35921] Use ccache by default

Antoine Pitrou added the comment: (sorry for the typos; a bit sick today) -- ___ Python tracker <https://bugs.python.org/issue35921> ___ ___ Python-bugs-list m

[issue35921] Use ccache by default

Antoine Pitrou added the comment: > Besides not rebuilding .o[bj] files where the sources have not changed, what > else do these tools do? That's a different caching scheme. MSVC, make, ninja and friend will compare timestamps of the .c and .o files are avoid rebuilding if the .

[issue35921] Use ccache by default

Antoine Pitrou added the comment: This is Unix-only, but the same approach may be possible on Windows using clcache (https://github.com/frerich/clcache). -- nosy: +steve.dower ___ Python tracker <https://bugs.python.org/issue35

[issue35921] Use ccache by default

Change by Antoine Pitrou : -- keywords: +patch, patch pull_requests: +11743, 11744 stage: -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue35921] Use ccache by default

Change by Antoine Pitrou : -- keywords: +patch, patch, patch pull_requests: +11743, 11744, 11745 stage: -> patch review ___ Python tracker <https://bugs.python.org/issu

[issue35921] Use ccache by default

Change by Antoine Pitrou : -- keywords: +patch pull_requests: +11743 stage: -> patch review ___ Python tracker <https://bugs.python.org/issue35921> ___ ___ Py

[issue35921] Use ccache by default

Antoine Pitrou added the comment: I've got a proof-of-concept patch, here are the results: Debug build, uncached real0m50,260s user1m52,663s sys 0m11,305s Debug build, cached real0m4,511s user0m4,009s sys 0m1,547s Non-debug build, uncached real1m18,384s user

[issue35921] Use ccache by default

New submission from Antoine Pitrou : While compiling CPython isn't very slow, enabling ccache if found would produce faster builds when developing. -- components: Build messages: 334973 nosy: pitrou priority: normal severity: normal status: open title: Use ccache by default type

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Antoine Pitrou added the comment: Would probably be worthwhile backporting to 3.7 as well. -- versions: +Python 3.7 ___ Python tracker <https://bugs.python.org/issue35

[issue35917] multiprocessing: provide unit-tests for manager classes and shareable types

Antoine Pitrou added the comment: Interesting. I had never looked too closely and assumed this was already tested. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35902] Forking from background thread

Antoine Pitrou added the comment: By the way, one likely explanation why this happens only when fork() is called from a non-main thread is that the non-main thread (which becomes the main thread in the child process) ends with pthread_exit() while the main thread would end with exit

[issue35902] Forking from background thread

Antoine Pitrou added the comment: It is actually quite an intricate problem. What happens is that child process *main thread* ends, but not its background sleeping thread (the `lambda: time.sleep(3600)`). To diagnose it, you can display the process tree: ``` $ ps fu USER PID %CPU

[issue35902] Forking from background thread

Change by Antoine Pitrou : -- nosy: +pablogsal ___ Python tracker <https://bugs.python.org/issue35902> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35911] add a cell construtor, and expose the cell type in Lib/types.py

Antoine Pitrou added the comment: Hi Pierre, You'll want to submit your patch as a GitHub pull request. Also your PR will have to contain: - tests for the new Python-facing API - documentation for the new API You may want to read more in the developer's guide: https://devguide.python.org

[issue35911] add a cell construtor, and expose the cell type in Lib/types.py

Change by Antoine Pitrou : -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue35911> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types.

Antoine Pitrou added the comment: FYI, I've removed the duplicate message :-) Also adding Serhiy as cc. -- nosy: +serhiy.storchaka ___ Python tracker <https://bugs.python.org/issue35

[issue35900] Add pickler hook for the user to customize the serialization of user defined functions and types.

Change by Antoine Pitrou : -- Removed message: https://bugs.python.org/msg334871 ___ Python tracker <https://bugs.python.org/issue35900> ___ ___ Python-bug

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: Also, I will want to review this as well. Since Alpha 2 is scheduled for 2019-02-24, and this is a sizable piece of work, I would prefer if a full PR was available, say, before 2019-02-15. -- ___ Python tracker

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: And to make things clear, I'm not saying anything about the functionality. Easier shared memory + multiprocessing is definitely an interesting endeavour (and a non-trivial one). -- ___ Python tracker <ht

[issue35813] shared memory construct to avoid need for serialization between processes

Antoine Pitrou added the comment: Yes, I think this was merged too soon. Davin, the convention is that we only merge completed work, not some work-in-progress. You already did this once in https://bugs.python.org/issue28053 . You still haven't completed that piece of work. I'm going

[issue35845] Can't read a F-contiguous memoryview in physical order

Antoine Pitrou added the comment: > So we'd need to restrict to contiguous views anyway, which makes the method less appealing (IOW, it doesn't offer more than an augmented memoryview.cast()). Yes, it would probably be a simpler way of writing `.cast('B', shape=(...), or

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: Ok, this is now pushed to 2.7 as well. Thank you Jeroen! -- ___ Python tracker <https://bugs.python.org/issue25592> ___ ___

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: New changeset 40a101df8c64a1e55cca2780248d7a92bdcccd57 by Antoine Pitrou (Miss Islington (bot)) in branch '2.7': bpo-25592: Improve documentation of distutils data_files (GH-9767) (GH-11734) https://github.com/python/cpython/commit

[issue25592] distutils docs: data_files always uses sys.prefix

Change by Antoine Pitrou : -- stage: patch review -> resolved status: open -> closed versions: +Python 2.7 ___ Python tracker <https://bugs.python.org/i

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: Jeroen you're right. Could you still give it a quick check? Then I'll mark the PR for a 2.7 backport. -- ___ Python tracker <https://bugs.python.org/issue25

[issue25592] distutils docs: data_files always uses sys.prefix

Change by Antoine Pitrou : -- status: closed -> open ___ Python tracker <https://bugs.python.org/issue25592> ___ ___ Python-bugs-list mailing list Unsubscrib

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: New changeset ebae1ce9c40e62ce52dc968f86ed11578d2fcdfd by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-25592: Improve documentation of distutils data_files (GH-9767) (GH-11701) https://github.com/python/cpython/commit

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: Fixing this on 2.7 would require additional investigation (distutils might have diverged), so I'm closing now. -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: -P

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: New changeset 598e15d4feaee3849a91d92c9ca51f17baafe19c by Antoine Pitrou (jdemeyer) in branch 'master': bpo-25592: Improve documentation of distutils data_files (GH-9767) https://github.com/python/cpython/commit/598e15d4feaee3849a91d92c9ca51f17baafe19c

[issue34778] Memoryview for column-major (f_contiguous) arrays from bytes impossible to achieve

Antoine Pitrou added the comment: I think feature creep is ok if it stems from user needs. Slighty related, but simpler, is https://bugs.python.org/issue35845 -- ___ Python tracker <https://bugs.python.org/issue34

[issue35845] Can't read a F-contiguous memoryview in physical order

Antoine Pitrou added the comment: Sorry, my fingers slipped. Let me try again: As for tobytes(), if we want to follow NumPy, we can have 'A' mean 'F' if F-contiguous, 'C' otherwise: [...] -- ___ Python tracker <https://bugs.python.

[issue35845] Can't read a F-contiguous memoryview in physical order

Antoine Pitrou added the comment: Well, raw_memory() would avoid a copy, which is useful. As for tobytes(), if we want to follow NumPy, we can have 'F' mean if F-contiguous, 'C' otherwise: >>> a = np.arange(12, dtype='int8').res

[issue25592] distutils docs: data_files always uses sys.prefix

Antoine Pitrou added the comment: Though it's difficult to say for certain (distutils' option selection logic is obscure and difficult to follow), it seems that Jeroen's analysis is right. -- nosy: +pitrou ___ Python tracker <ht

[issue25592] distutils docs: data_files always uses sys.prefix

Change by Antoine Pitrou : -- versions: +Python 3.7, Python 3.8 -Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issue25592> ___ ___ Python-bug

[issue35845] Can't read a F-contiguous memoryview in physical order

New submission from Antoine Pitrou : This request is motivated in detail here: https://github.com/python/peps/pull/883#issuecomment-458290745 In short: in C, when you have a Py_buffer, you can directly read the memory in whatever order you want (including physical order). It is not possible

[issue34134] multiprocessing memory huge usage

Antoine Pitrou added the comment: This is basically fixed, except that I'll let the Release Manager choose whether 3.6 gets the fix as well. Thanks! -- resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +P

[issue34134] multiprocessing memory huge usage

Antoine Pitrou added the comment: New changeset c2674bf11036af1e06c1be739f0eebcc72dfbf7a by Antoine Pitrou (Miss Islington (bot)) in branch '3.7': bpo-34134: Advise to use imap or imap_unordered when handling long iterables. (gh-8324) (gh-11673) https://github.com/python/cpython/commit

[issue34134] multiprocessing memory huge usage

Antoine Pitrou added the comment: New changeset 3bab40db96efda2e127ef84e6501fda0cdc4f5b8 by Antoine Pitrou (Windson yang) in branch 'master': bpo-34134: Advise to use imap or imap_unordered when handling long iterables. (gh-8324) https://github.com/python/cpython/commit

[issue10915] Make the PyGILState API compatible with multiple interpreters

Antoine Pitrou added the comment: Patch probably doesn't apply anymore. -- stage: patch review -> needs patch versions: +Python 3.8 -Python 3.5, Python 3.6 ___ Python tracker <https://bugs.python.org/issu

[issue35627] multiprocessing.queue in 3.7.2 doesn't behave as it was in 3.7.1

Antoine Pitrou added the comment: > Hi there. I get this behavior as well, although only in a venv. Ah, thanks for the clarification. Then it's a duplicate of issue35797. -- resolution: -> duplicate stage: -> resolved status: open -> close

[issue32146] multiprocessing freeze_support needed outside win32

Antoine Pitrou added the comment: @bbayles Hopefully a Windows user could test if you give a step-by-step guide of what to check for. -- nosy: +paul.moore, steve.dower, tim.golden, zach.ware ___ Python tracker <https://bugs.python.org/issue32

[issue14802] Python fails to compile with VC11 ARM configuration

Antoine Pitrou added the comment: Fixed in master branch. Thank you, Minmin Gong! I don't think this is a candidate for a 3.7 backport. If you think otherwise, though, please say so. You'll also need to check that the backport enables proper compilation on ARM. -- nosy: +ned.deily

[issue35758] Disable x87 control word for MSVC ARM compiler

Antoine Pitrou added the comment: New changeset 7a2368063f25746d4008a74aca0dc0b82f86ff7b by Antoine Pitrou (Minmin Gong) in branch 'master': bpo-35758: Fix building on ARM + MSVC (gh-11531) https://github.com/python/cpython/commit/7a2368063f25746d4008a74aca0dc0b82f86ff7b -- nosy

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

Antoine Pitrou added the comment: Hmm, if multiprocessing exhibits the problem, I wouldn't be surprised if some third-party libraries also do. I think `sys.executable` should really point to the proper executable. > But changing sys.executable to _not_ be the venv one will break anyone

[issue35797] concurrent.futures.ProcessPoolExecutor does not work in venv on Windows

Antoine Pitrou added the comment: Hmm... Out of curiosity, why is the venv's python.exe not simply a symlink to the original python.exe? What is the point of going through py.exe here? Also, is this a regression? Otherwise I don't think it has to be a release blocker

[issue35778] RF: ``pathlib.Path.checksum()`` member

Antoine Pitrou added the comment: Sorry, but it does not make sense to me (not would it make sense to add e.g. a JPEG decoder to pathlib). Each project or application would want their own checksumming specification and pathlib does not have to cater to that. -- resolution

[issue20399] Comparison of memoryview

Antoine Pitrou added the comment: If not wanting to support the whole gamut of PEP 3118 types, one could start by only providing ordered comparisons when format == 'B'. -- stage: -> needs patch versions: +Python 3.8 -Python 3.5 ___ Python trac

[issue20399] Comparison of memoryview

Antoine Pitrou added the comment: Josh, could you say what your use case is? -- ___ Python tracker <https://bugs.python.org/issue20399> ___ ___ Python-bug

[issue35283] "threading._DummyThread" redefines "is_alive" but forgets "isAlive"

Change by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker <https://bugs.python.org/issue35283> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35537] use os.posix_spawn in subprocess

Change by Antoine Pitrou : -- nosy: -pitrou ___ Python tracker <https://bugs.python.org/issue35537> ___ ___ Python-bugs-list mailing list Unsubscribe:

[issue35306] OSError [WinError 123] when testing if pathlib.Path('*') (asterisks) exists

Antoine Pitrou added the comment: I'm fine with swallowing the error in both exists() and resolve(). We should be careful not to swallow errors too broadly, though. The code paths should be audited to check that EINVAL can't mean something else. -- versions: +Python 3.8 -Python 3.6

[issue35692] pathlib.Path.exists() on non-existent drive raises WinError instead of returning False

Antoine Pitrou added the comment: I think exists() should simply return False here. There's no reason a non-existing drive should fail differently than a non-existing parent directory. -- stage: -> needs patch versions: +Python 3.8 ___ Pyt

[issue33944] Deprecate and remove pth files

Antoine Pitrou added the comment: > Is that true outside of virtual environments? Not in my experience. But I'm not sure special-casing virtual environments will make the situation easier to understand ;-) -- ___ Python tracker <

[issue33944] Deprecate and remove pth files

Antoine Pitrou added the comment: As I said: editable installs (`pip install -e`) are an important use case of .pth files. I don't see how namespace packages have anything to do with this, sorry. -- ___ Python tracker <https://bugs.python.

[issue35582] Argument Clinic: inline parsing code for functions with only positional parameters

Antoine Pitrou added the comment: Are there any numbers on higher-level benchmarks? -- nosy: +pitrou ___ Python tracker <https://bugs.python.org/issue35

[issue32146] multiprocessing freeze_support needed outside win32

Antoine Pitrou added the comment: The key here would be to replace function execution with module execution and command-line arguments. So instead of: python -c 'from multiprocessing.forkserver import main; main(ARG1, ARG2...)' you would do: python -m multiprocessing.forkserver ARG1

[issue32146] multiprocessing freeze_support needed outside win32

Antoine Pitrou added the comment: I'm sorry about not seeing your PR before. Would you like to update it against current git master? (note I'm not thrilled by the use of the "ast" module; I hope we can change the command-line args so that this is

[issue33498] pathlib.Path wants an rmtree method

Antoine Pitrou added the comment: Indeed there is no reason to put all useful path informations under the Path class. Writing method calls instead of function calls is not an ideal. -- resolution: -> rejected stage: patch review -> resolved status: open -&g

[issue35493] multiprocessing.Pool._worker_handler(): use SIGCHLD to be notified on worker exit

Antoine Pitrou added the comment: If using Process.sentinel looks easy enough, then go for it. Existing users of multiprocessing.Pool will benefit. -- ___ Python tracker <https://bugs.python.org/issue35

[issue35606] Add prod() function to the math module

Antoine Pitrou added the comment: For the record, I would have to look up the documentation everytime I encounter "comb" and "perm", while the full names are intuitive to me. "prod" and "fact" feel somewhat less obscure. I suppose there are two po

[issue35606] Add prod() function to the math module

Antoine Pitrou added the comment: I agree with Mark that correctness, rather than performance, should be the main attraction of a stdlib implementation. By the way "prod" is slightly obscure (though it's Numpy's chosen spelling), how about "product"? After all, w

<    1   2   3   4   5   6   7   8   9   10   >