[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: Victor: I’m booting with the isolcpus and rcu_nocbs flags, and running pyperformance with the --affinity flag to pin the benchmark to the isolated CPU cores. I’ve also run `perf system tune`. And the OS is Ubuntu 17.10. Thanks for the tip on using perf timeit ins

[issue32534] Speed-up list.insert: use memmove()

STINNER Victor added the comment: > I’ve run the benchmark that you've suggested with a minor change (to avoid > the cost of LOAD_ATTR) Be careful. Moving "l.insert" lookup of the loop might make the code slower. I never looked why. But Python 3.7 was also optimized in many places to call me

[issue32534] Speed-up list.insert: use memmove()

Jeethu Rao added the comment: > Be careful. Moving "l.insert" lookup of the loop might make the code slower. > I never looked why. But Python 3.7 was also optimized in many places to call > methods, so I'm not sure anymore :) Thanks again! Here's a gist without the hack[1]. [1]: https://gist

[issue32516] Add a shared library mechanism for win32

Steve Dower added the comment: I am very okay with it not being Python's responsibility to do this. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker __

[issue14976] queue.Queue() is not reentrant, so signals and GC can cause deadlocks

Gregory P. Smith added the comment: https://bugs.python.org/issue32576 filed for that -- ___ Python tracker ___ ___ Python-bugs-list

[issue32576] concurrent.futures.thread potential deadlock due to Queue in weakref callback

New submission from Gregory P. Smith : As a follow up to https://bugs.python.org/issue14976 which just introduced queue.SimpleQueue: concurrent.futures.thread currently uses a queue.Queue() from weakref callbacks which could in theory lead to a deadlock when periodic gc triggers a cleanup inv

[issue32516] Add a shared library mechanism for win32

Nathaniel Smith added the comment: Steve said: > The import hook was my proposal to let you only preload DLLs when the > extension module is being loaded, rather than having to load all the DLLs on > the first "import scipy" just in case one of its submodules gets imported > later. A hook can

[issue32573] sys.argv documentation should include caveat for embedded environments

Pedro added the comment: My first inclination would be no. An argv value of [''] means "zero command-line arguments" (not even a filename), which implies the following as far as I know: 1. Python was called as an executable rather than a library, because you can't pass command-line arguments

[issue32573] sys.argv documentation should include caveat for embedded environments

Pedro added the comment: My comment above uses "code that we provide for supporting embedding," not "third party code," as the definition of embedded. -- ___ Python tracker __

[issue32516] Add a shared library mechanism for win32

xoviat added the comment: For the record, moving the DLL path manipulation code into the interpreter would address the concern that importing a module would not manipulate the search path because the behavior would move into Python itself. -- ___ P

[issue32516] Add a shared library mechanism for win32

Steve Dower added the comment: The import hook could theoretically modify the search path before and after loading the module, though that could make debugging a real pain. I was also thinking of just having an explicit list of DLLs to load, rather than inspecting the binary. Per-module prelo

[issue28521] _PyEval_RequestCodeExtraIndex should return a globally valid index, not a ThreadState specific one

Change by Jeethu Rao : -- nosy: +jeethu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue30604] co_extra_freefuncs is stored thread locally and can lead to crashes

Change by Jeethu Rao : -- nosy: +jeethu ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.or

[issue32516] Add a shared library mechanism for win32

Nathaniel Smith added the comment: > it still won't help if another import has loaded a different DLL by the same > name. This is where you can't avoid recompilation or activation contexts. Ah, there's an important bit of context you're missing: there is actually a third option :-) https://g

[issue29319] Embedded 3.6.0 distribution cannot run pyz files

Nick Coghlan added the comment: Tweaking metadata to make it clear Py3.5 was also updated. -- versions: +Python 3.5 ___ Python tracker ___ _

[issue32516] Add a shared library mechanism for win32

Steve Dower added the comment: That looks like recompilation (or at least how recompilation would look if you'd been granted permission). Assuming you can recompile the binary, you could rename the dependency and regenerate the import library so that you can link directly against the new name

[issue32551] Zipfile & directory execution in 3.5.4 also adds the parent directory to sys.path

Nick Coghlan added the comment: Good catch Eryk, I misdiagnosed what was going on, since the current directory and the parent directory were the same location in Ned's particular example. I double checked, and we resolve symlinks in path entries *before* performing the incorrect directory tra

[issue32516] Add a shared library mechanism for win32

xoviat added the comment: Just to be clear, I'm not considering doing this with respect to the C/C++ runtimes, but all of the other shared libraries. And in case you weren't aware, this is exactly what auditwheel does (except that I believe it uses patchelf, whereas I will be using Nathaniel'

[issue32516] Add a shared library mechanism for win32

Nathaniel Smith added the comment: > That looks like recompilation (or at least how recompilation would look if > you'd been granted permission). Assuming you can recompile the binary, you > could rename the dependency and regenerate the import library so that you can > link directly against

[issue32534] Speed-up list.insert: use memmove()

Raymond Hettinger added the comment: FWIW, we've encountered a number of situations in the past when something that improved the timings on one compiler would make timings worse on another compiler. There was also variance between timings on 32-bit builds versus 64-bit builds. -- _

[issue32559] logging - public function to get level from name

Raymond Hettinger added the comment: > The request is not to set the level but to get the level > given the level name aka textual representation. > For example, passing in INFO should return 20 and passing > in CRITICAL should return 50. Why do we care about this? -- __

[issue32573] sys.argv documentation should include caveat for embedded environments

Nick Coghlan added the comment: There are actually 3 attributes that may be absent when CPython itself isn't managing the C level entry point: sys.argv, sys.warnoptions, and sys._xoptions. I'd be more inclined to make the implementation match the docs though, and have these all be empty lists

[issue32577] Pip creates entry point commands in the wrong place when invoked in a venv nested in a virtualenv

New submission from Tzu-ping Chung : (I’m not sure whether this is a venv or virtualenv problem. Asking here first.) To reproduce: $ python3.6 -m virtualenv outer $ ./outer/bin/python -m venv inner $ ls inner/bin activate activate.csh activate.fish python python3 In compari

[issue32575] IDLE cannot locate certain SyntaxErrors raised by f-string expressions

Terry J. Reedy added the comment: Syntax errors come from Python, not IDLE. Except for the pseudofile name ('' versus ''), the message is the same as the interactive interpreter. Anytime one thinks IDLE has a bug, one should check the standard interactive interpreter as a 'control'. --

[issue32559] logging - public function to get level from name

Vinay Sajip added the comment: I don't think a strong enough case has been made for adding this enhancement. -- resolution: -> rejected stage: -> resolved status: open -> closed ___ Python tracker _

<    1   2