[issue26360] Deadlock in thread.join

[Mark Dickinson]

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 for the GIL, and (as you point 
out), for thread 1 to be where it is, it must have also released the GIL by 
that point.

Agreed about the gdb results for the -O3 build.

So it looks as though something's gone wrong with the "I've just released the 
GIL; now someone else can pick it up" signaling mechanism.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26280] ceval: Optimize list

[STINNER Victor]

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[int] (subscript) operation similarly to CPython 2.7 
-> ceval: Optimize list

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Zach Byrne]

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 penalty.

[0]byrnez@byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = 
[1,2,3,4,5,6]" "l[3]"
1000 loops, best of 3: 0.0306 usec per loop
[0]byrnez@byrnez-laptop:~/git/python$ ./python -m timeit -s "l = [1,2,3,4,5,6]" 
"l[3]"
1000 loops, best of 3: 0.0243 usec per loop

[0]byrnez@byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = 
(1,2,3,4,5,6)" "l[3]"
1000 loops, best of 3: 0.0291 usec per loop
[0]byrnez@byrnez-laptop:~/git/python$ ./python -m timeit -s "l = (1,2,3,4,5,6)" 
"l[3]"
1000 loops, best of 3: 0.0241 usec per loop

[0]byrnez@byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = 
'asdfasdf'" "l[3]"
1000 loops, best of 3: 0.034 usec per loop
[0]byrnez@byrnez-laptop:~/git/python$ ./python -m timeit -s "l = 'asdfasdf'" 
"l[3]"
1000 loops, best of 3: 0.0366 usec per loop

[0]byrnez@byrnez-laptop:~/git/python$ ./python.orig -m timeit -s "l = 
[1,2,3,4,5,6]" "l[:3]"
1000 loops, best of 3: 0.124 usec per loop
[0]byrnez@byrnez-laptop:~/git/python$ ./python -m timeit -s "l = [1,2,3,4,5,6]" 
"l[:3]"
1000 loops, best of 3: 0.125 usec per loop

--
Added file: http://bugs.python.org/file41939/subscr1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26360] Deadlock in thread.join

[STINNER Victor]

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 reliable when Python is compiled with -O0 (./configure 
--with-pydebug is enough for Python 2.7).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26360] Deadlock in thread.join

[STINNER Victor]

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, until this Python 2 issue is fixed (if we 
are able to fix it!).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26372] Popen.communicate not ignoring BrokenPipeError

[Memeplex]

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 the behavior of communicate with a timeout, which 
doesn't raise the  exception. Moreover, there is even a comment near the point 
of the exception stating that communicate must ignore BrokenPipeError:

def _stdin_write(self, input):
if input:
try:
self.stdin.write(input)
except BrokenPipeError:
# communicate() must ignore broken pipe error
pass

self.stdin.close()

Obviously, the problem is that self.stdin.close() is outside the except clause.

--
components: Library (Lib)
messages: 260373
nosy: memeplex
priority: normal
severity: normal
status: open
title: Popen.communicate not ignoring BrokenPipeError
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26360] Deadlock in thread.join

[STINNER Victor]

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/threadmodule.c:52:

Py_BEGIN_ALLOW_THREADS
i = PyThread_acquire_lock(self->lock_lock, i);
Py_END_ALLOW_THREADS

Note: I backported enhancements of python-gdb.py from Python 3, but I'm not 
sure that "Waiting for the GIL" line is reliable :-/ I recall vaguely a 
technical issue specific to Python 2 to check if a thread is waiting on the GIL 
or not.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26360] Deadlock in thread.join

[STINNER Victor]

Changes by STINNER Victor :


--
nosy: +haypo

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Frederick Wagner]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Manuel Jacob]

Changes by Manuel Jacob :


Added file: http://bugs.python.org/file41938/relimport-3.6.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Manuel Jacob]

Changes by Manuel Jacob :


--
keywords: +patch
Added file: http://bugs.python.org/file41937/relimport-3.5.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Nathan West]

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
(env) user@host ~/test> deactivate
user@host ~/test> true
user@host ~/test> false
user@host ~/test [1]>

Notice that, after running the `false` command the first time, the command 
prompt includes a "[1]", indicating the exit status of the `false` command. 
However, after activating the virtual environment, the command prompt no longer 
shows the error code from the `false` command. After deactivating the 
virtualenv, the command prompt once again displays the error code from `false`.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Guido van Rossum]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[STINNER Victor]

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 to only touch asynchat doc to explain well that 
asyncore and asynchat are not thread-safe.

--
components: +asyncio
nosy: +gvanrossum, haypo, yselivanov

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[NGG]

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 both threads will call this.

It can result in sending (part of) the message multiple times or not sending 
part of it.

Possible solution:
asyncore.dispatcher_with_send.out_buffer and asynchat.async_chat.producer_fifo 
should be guarded with a lock (it should be locked even in writable())

--
components: Library (Lib)
messages: 260367
nosy: ngg
priority: normal
severity: normal
status: open
title: asynchat.async_chat and asyncore.dispatcher_with_send are not thread-safe
type: behavior
versions: Python 2.7, Python 3.2, Python 3.3, Python 3.4, Python 3.5, Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

Changes by Paul Moore :


--
keywords: +easy

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[francisco]

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 the State of this issue is "test needed". 
Shouldn't State be "patch review" instead?

--
type:  -> behavior
versions: +Python 3.6

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Mark Mikofski]

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))
except OSError as err:
sys.stderr.write('%s\n' % err)

`core.py`
-
# load the DLL
solposAM_dll = ctypes.cdll.LoadLibrary(SOLPOSAMDLL)
_solposAM = solposAM_dll.solposAM

After deleting files, setup.py tries to build, then runs test_cdlls.py a 
unittest that contains test_solposAM() that calls solposAM() and imports 
core.py that contains solposAM.

Case 1:
---
I put the load library calls inside the function solposAM().
Function calls works as expected.
I am able to delete dlls after interpreter exits and restarts using os.remove()

Case 2:
---
I put the load library calls at the module level.
Function calls works as expected.
If I try to delete dlls after interpreter exits and restarts using os.remove() 
I get access denied, but I can delete them from windows explorer.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Paul Moore]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Yury Selivanov]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Brian Curtin]

Changes by Brian Curtin :


--
nosy:  -brian.curtin

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue26370] shelve filename inconsistent between platforms

[Dima Tisnek]

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 more than 
one file may be created."""


Still, it's super-quirky, it's almost as if the message was "don't use shelve."


Some ways out:
* ValueError if "." in basename(filaneme)  # a hammer
* ValueError if filename.endswith((".db", ".gdbm", ...))  # block only known 
extensions
* strip extension if it's known that underlying library is going to add it
* patch underlying library to always use filename verbatim

--
components: Extension Modules
messages: 260362
nosy: Dima.Tisnek
priority: normal
severity: normal
status: open
title: shelve filename inconsistent between platforms
type: behavior
versions: Python 3.5

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ezio Melotti]

Changes by Ezio Melotti :


--
nosy: +ezio.melotti

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Steven D'Aprano]

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

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Tamás Bence Gedai]

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_date_v1.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Ben Spiller]

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, which is currently quite vague. 

The decode/encode methods really make most sense when called on a unicode 
string i.e. unicode.encode() to produce a byte string, or on a byte string e.g. 
str.decode() to produce a unicode object from a byte string. 

However, the additional presence of the opposite methods str.encode() and 
unicode.decode() is quite confusing, and a frequent source of errors - e.g. 
calling str.encode('utf-8') first DECODES the str object (which might already 
be in utf8) to a unicode string **using the default encoding of "ascii"** (!) 
before ENCODING to a utf-8 byte str as requested, which of course will fail at 
the first stage with the classic error "UnicodeDecodeError: 'ascii' codec can't 
decode byte" if there are any non-ascii chars present. It's unfortunate that 
this initial decode/encode stage ignores both the "encoding" argument (used 
only for the subsequent encode/decode) and the "errors" argument (commonly used 
when the programmer is happy with a best-effort conversion e.g. for logging 
purposes).

Anyway, given this behaviour, a lot of time would be saved by a simple sentence 
on the doc for str.encode()/unicode.decode() essentially warning people that 
those methods aren't that useful and they probably really intended to use 
str.decode()/unicode.encode() - the current doc gives absolutely no clue about 
this extra stage which ignores the input arguments and sues 'ascii' and 
'strict'. It might also be worth stating in the documentation that the pattern 
(u.encode(encoding) if isinstance(u, unicode) else u) can be helpful for cases 
where you unavoidably have to deal with both kinds of input, string calling 
str.encode is such a bad idea. 

In an ideal world I'd love to see the implementation of 
str.encode/unicode.decode changed to be more useful (i.e. instead of using 
ascii, it would be more logical and useful to use the passed-in encoding to 
perform the initial decode/encode, and the apss-in 'errors' value). I wasn't 
sure if that change would be accepted so for now I'm proposing better 
documentation of the existing behaviour as a second-best.

--
assignee: docs@python
components: Documentation
messages: 260359
nosy: benspiller, docs@python
priority: normal
severity: normal
status: open
title: doc for unicode.decode and str.encode is unnecessarily confusing
type: behavior
versions: Python 2.7

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Berker Peksag]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Berker Peksag]

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 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Mathieu Dupuy]

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, 
which is heavily tested in time unittests.
* I now handle lowercase T and Z. (I know I could do "if tzinfo[0] in ('Z', 
'z')", but to me it feel like imposing a micro performance penalty to 
implementation correctly sending an uppercase Z)

I'm impatient to receive your feedback.

--
Added file: http://bugs.python.org/file41935/fromisoformat_new.patch

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Eryk Sun]

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 deleted when the system reboots:

MoveFileExW(renamed_dll_path, NULL, MOVEFILE_DELAY_UNTIL_REBOOT)

Renaming a loaded DLL succeeds because the system opens the file with delete 
sharing, which allows renaming (i.e. relinking) an open file. 

To verify this, let's check the associated file object that's used by the 
mapping for python35.dll. We can see this in a local kernel debugging session. 
The following is in 64-bit Windows 7.

Attach to the Python process address space:

lkd> .tlist python.exe
 0n2296 python.exe
lkd> !process 0n2296 0
Searching for Process with Cid == 8f8
Cid handle table at f8a003506000 with 951 entries in use

PROCESS fa800712fb10
SessionId: 0  Cid: 08f8Peb: 7fdf000  ParentCid: 02b8
DirBase: 20780d000  ObjectTable: f8a0189fe1a0  HandleCount:  67.
Image: python.exe

lkd> .process /p /r 0xfa800712fb10 
Implicit process is now fa80`0712fb10
Loading User Symbols
...

Get the base address for python35.dll.

lkd> lm m python35
start end module name
`66fb `67393000   python35   (deferred)

Get the associated Virtual Address Descriptor (VAD).

lkd> !vad 66fb
VAD level  start  endcommit
fa800855f230 (-1)  66fb0  67392  151 Mapped  Exe
 EXECUTE_WRITECOPY
 \Program Files\Python35\python35.dll

Get the File object reference from the associated control area.

lkd> ?? ((nt!_MMVAD 
*)0xfa800855f230)->Subsection->ControlArea->FilePointer
struct _EX_FAST_REF
   +0x000 Object   : 0xfa80`093f1503 Void
   +0x000 RefCnt   : 0y0011
   +0x000 Value: 0xfa80`093f1503

The low nibble in the above address is information that needs to be masked out, 
so the address is actually 0xfa80`093f1500. Verify we have the correct file 
object by checking the filename.
   
lkd> ?? ((nt!_FILE_OBJECT *)0xfa80`093f1500)->FileName
struct _UNICODE_STRING
 "\Program Files\Python35\python35.dll"
   +0x000 Length   : 0x48
   +0x002 MaximumLength: 0x78
   +0x008 Buffer   : 0xf8a0`04b23690
 "\Program Files\Python35\python35.dll"

Finally, check the sharing mode. We see below that the file for a DLL mapping 
is loaded with read and delete sharing, but not write sharing.

lkd> ?? ((nt!_FILE_OBJECT *)0xfa80`093f1500)->SharedRead
unsigned char 0x01 ''
lkd> ?? ((nt!_FILE_OBJECT *)0xfa80`093f1500)->SharedDelete
unsigned char 0x01 ''
lkd> ?? ((nt!_FILE_OBJECT *)0xfa80`093f1500)->SharedWrite
unsigned char 0x00 ''

Thus when deleting a DLL fails, it's not due to ERROR_SHARING_VIOLATION (32). 
The sharing mode would actually permit deleting the file. Instead the error is 
ERROR_ACCESS_DENIED (5), which results from the system call 
NtSetInformationFile returning STATUS_CANNOT_DELETE (0xC121), because the 
file currently has a mapped image or data section. But that doesn't stop us 
from renaming it to get it out of the way of an in-place upgrade.

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Eryk Sun]

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 being buried in the private _ctypes 
extension module. You could also implement them with ctypes itself, but the 
existing functions in the _ctypes module already set a proper exception if the 
call fails and properly use pointers (an HMODULE is a pointer).

--
assignee:  -> docs@python
components: +Documentation
nosy: +docs@python
versions: +Python 2.7, Python 3.5, Python 3.6 -Python 3.3

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

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

[Serhiy Storchaka]

Serhiy Storchaka added the comment:

Could you provide a patch? See also my comment on Rietveld (the "review" link).

--

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

[issue14597] Cannot unload dll in ctypes until script exits

[Eryk Sun]

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 call inside a function, then, 
> after exiting the interpreter the dll can be deleted.

I'm having trouble imagining what the problem could be here. Can you attach a 
minimal example script that reproduces the problem?

--
nosy: +eryksun

___
Python tracker 

___
___
Python-bugs-list mailing list
Unsubscribe: 
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com