[issue14597] Cannot unload dll in ctypes until script exits

Eryk Sun added the comment: > My setup.py creates a .dll then later loads the dll for testing > using ctypes. Subsequent runs of setup.py that would force > rebuilding the .dll attempt to delete the old dll first if it > exists, but I get permission denied. > > Oddly, if I put the load library

[issue23718] strptime() can produce invalid date with negative year day

Serhiy Storchaka added the comment: Could you provide a patch? See also my comment on Rietveld (the "review" link). -- ___ Python tracker ___

[issue14597] Cannot unload dll in ctypes until script exits

Eryk Sun added the comment: The _ctypes extension module provides dlclose on POSIX and FreeLibrary on Windows. For the reasons already stated in this issue, ctypes should not automatically call these functions, but maybe they should be documented and imported to the ctypes module instead of be

[issue14597] Cannot unload dll in ctypes until script exits

Eryk Sun added the comment: As to not being able to delete a loaded DLL on Windows, a workaround that may help in some instances is to rename it to a temporary name on the same volume. This is useful for upgrading in place. If you have admin privileges you can even flag the renamed DLL to be d

[issue15873] datetime: add ability to parse RFC 3339 dates and times

Mathieu Dupuy added the comment: OK, I know I post a lot, but this one should be the good one: * recoded from scratch. Apart the algorithm, nothing come from Django anymore. * help me fill the docstring, I'm not inspired * datetime has few tests since it use the implementation of time._parse_time

[issue26366] Use “.. versionadded” over “.. versionchanged” where appropriate

Berker Peksag added the comment: I agree with Georg and Ezio. We should update the devguide. Tony, would you like to propose a patch? The repo is at https://hg.python.org/devguide -- nosy: +berker.peksag ___ Python tracker

[issue24911] Context manager of socket.socket is not documented

Berker Peksag added the comment: socket-context.patch looks good to me. There is no need to add a NEWS entry for this. -- nosy: +berker.peksag stage: patch review -> commit review versions: -Python 3.4 ___ Python tracker

[issue26369] doc for unicode.decode and str.encode is unnecessarily confusing

New submission from Ben Spiller: It's well known that lots of people struggle writing correct programs using non-ascii strings in python 2.x, but I think one of the main reasons for this could be very easily fixed with a small addition to the documentation for str.encode and unicode.decode, wh

[issue23718] strptime() can produce invalid date with negative year day

Tamás Bence Gedai added the comment: I've added a new patch, it uses an other way to calculate the number of days in a given year. I updated the tests, so now it doesn't fail, I also added some extra test cases to test leap years. -- Added file: http://bugs.python.org/file41936/julian_

[issue26369] doc for unicode.decode and str.encode is unnecessarily confusing

Steven D'Aprano added the comment: Perhaps you could suggest a specific change to the docstrings for str.encode and unicode.decode? (BTW, I presume you are aware that the equivalent of (bytes)str.encode and unicode.decode are gone in Python 3?) -- nosy: +steven.daprano __

[issue26369] doc for unicode.decode and str.encode is unnecessarily confusing

Changes by Ezio Melotti : -- nosy: +ezio.melotti ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.p

[issue26370] shelve filename inconsistent between platforms

New submission from Dima Tisnek: shelve.open("foo.db") creates "foo.db" on Linux and "foo.db.db" on OSX. Something to that extent is even documented: """d = shelve.open(filename) # open, with (g)dbm filename -- no suffix""" and """As a side-effect, an extension may be added to the filename and

[issue14597] Cannot unload dll in ctypes until script exits

Changes by Brian Curtin : -- nosy: -brian.curtin ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.

[issue24911] Context manager of socket.socket is not documented

Yury Selivanov added the comment: The patch looks good. It would also be cool if you can add a short code snippet somewhere: sock = socket.socket() with sock: sock.bind(('127.0.0.1', 8080)) sock.listen() ... -- nosy: +yselivanov ___

[issue25713] Setuptools included with 64-bit Windows installer is outdated

Paul Moore added the comment: Just to clarify, it's intended that you simply "python -m pip install --upgrade pip setuptools" to get the latest version. -- nosy: +paul.moore ___ Python tracker

[issue14597] Cannot unload dll in ctypes until script exits

Mark Mikofski added the comment: Snippets of "proprietary" code `setup.py` -- # run clean or build libraries if they don't exist if 'clean' in sys.argv: try: os.remove(os.path.join(LIB_DIR, SOLPOSAM_LIB_FILE)) os.remove(os.path.join(LIB_DIR, SPECTRL2_LIB_FILE)) ex

[issue13276] bdist_wininst-created installer does not run the postinstallation script when uninstalling

francisco added the comment: I believe that this bug—which I reported in 2011—is not correctly tagged, what may explain why it has not been fixed yet. Despite the fact that the original issue report contains a script to reproduce the bug and that msg148674 contains a patch to fix the issue th

[issue26336] Expose regex bytecode as attribute of compiled pattern object

Changes by Paul Moore : -- keywords: +easy ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.

[issue26371] asynchat.async_chat and asyncore.dispatcher_with_send are not thread-safe

New submission from NGG: The initiate_send() method in both asynchat.async_chat and asyncore.dispatcher_with_send is not a thread-safe function, but it can be called from multiple threads. For example if asyncore.loop() runs in a background thread, and the main thread sends a message then bot

[issue26371] asynchat.async_chat and asyncore.dispatcher_with_send are not thread-safe

STINNER Victor added the comment: asynchat is now deprecated in favor of asyncio. Almost all asyncio functions are not thread-safe, it's now well documented, see the general info: https://docs.python.org/dev/library/asyncio-dev.html#concurrency-and-multithreading If we do something, I suggest

[issue26371] asynchat.async_chat and asyncore.dispatcher_with_send are not thread-safe

Guido van Rossum added the comment: I don't believe the original issue is a bug. There is nothing in the docs for asyncore or asynchat that suggests they would be thread-safe. -- resolution: -> not a bug status: open -> closed ___ Python tracker

[issue25671] Fix venv activate.fish to maintain $status

Nathan West added the comment: Not quite, no. The issue looks like this: user@host ~/test> python3 -mvenv env user@host ~/test> true user@host ~/test> false user@host ~/test [1]> source env/bin/activate.fish (env) user@host ~/test> true (env) user@host ~/test> false

[issue26367] importlib.__import__ does not fail for invalid relative import

Changes by Manuel Jacob : -- keywords: +patch Added file: http://bugs.python.org/file41937/relimport-3.5.patch ___ Python tracker ___

[issue26367] importlib.__import__ does not fail for invalid relative import

Changes by Manuel Jacob : Added file: http://bugs.python.org/file41938/relimport-3.6.patch ___ Python tracker ___ ___ Python-bugs-list mailing

[issue26347] BoundArguments.apply_defaults doesn't handle empty arguments

Frederick Wagner added the comment: All right, looks like I have the asterisk now! Looking forward to officially contributing to the Python standard library :) -- ___ Python tracker ___

[issue26360] Deadlock in thread.join

Changes by STINNER Victor : -- nosy: +haypo ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python

[issue26360] Deadlock in thread.join

STINNER Victor added the comment: debug-build-stacktrace.txt: * Thread 1 is waiting on threading_hang.py:21: thread.join() * Thread 2-6 (5 threads) are waiting for the GIL The thread 1 is not supposed to hold the GIL: thread.join() is implemented by lock_PyThread_acquire_lock() at Modules/threa

[issue26372] Popen.communicate not ignoring BrokenPipeError

New submission from Memeplex: When not using a timeout, communicate will raise a BrokenPipeError if the command returns an error code. For example: sp = subprocess.Popen('cat --not-an-option', shell=True, stdin=subprocess.PIPE) time.sleep(.2) sp.communicate(b'hi\n') This isn't consistent with

[issue26360] Deadlock in thread.join

STINNER Victor added the comment: > I've also not yet managed to reproduce on Python 3, but I haven't tried that > hard. I suspect it's a Python 2-only problem, though. Python 3.2 got a new GIL and many bugs related to the GIL were fixed in Python 3 too. The "workaround" is to use Python 3, u

[issue26360] Deadlock in thread.join

STINNER Victor added the comment: >> lock=0x0 looks suspicious. > Agreed. I think that *could* possibly be a consequence of the earlier > multiple GILs, though I haven't figured out exactly how yet. Don't trust gdb output when Python is compiled in release mode (with -O3). gdb output is only

[issue26280] ceval: Optimize list[int] (subscript) operation similarly to CPython 2.7

Zach Byrne added the comment: Here's a patch that looks likes Victor's from the duplicate, but with tuples covered as well. I ran some straight forward micro benchmarks but haven't bothered running the benchmark suite yet. Unsurprisingly, optimized paths are faster, and the others take a penal

[issue26280] ceval: Optimize list

STINNER Victor added the comment: I suggest to try to inline PyList_GetItem: use PyList_GET_ITEM and raise the exception manually if needed. I'm not sure that it's ok to add PyLong_AsSize_t() to the slow path. Copy the code in each if? A macro can help. -- title: ceval: Optimize list[in

[issue26360] Deadlock in thread.join

Mark Dickinson added the comment: > I'm not sure that "Waiting for the GIL" line is reliable Right; I was interpreting that line more as "I don't have the GIL at the moment", which I think applies to all threads, including the main thread. It's pretty clear that threads 2-5 really are waiting