[issue22107] tempfile module misinterprets access denied error on Windows
Roger Upole added the comment: It doesn't actually do anything, so why do it at all? In order to distinguish why it failed, you might try checking if the file actually exists, and if it is a folder. -- ___ Python tracker <http://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
Roger Upole added the comment: os.access doesn't check filesystem permissions, so the patch will not catch the condition that creates the problem. -- ___ Python tracker <http://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue22107] tempfile module misinterprets access denied error on Windows
New submission from Roger Upole: _mkstemp_inner assumes that an access denied error means that it has generated a filename that matches an existing foldername. However, in the case of a folder for which you don't have permissions to create a file, this means it will loop thru the maximum possible number of files. This causes it to hang for several seconds and eventually return a bogus FileExistsError. Similar behaviour exists in 2.7.7, but it throws an IOError instead. http://bugs.python.org/issue18849 seems to be where this was introduced. -- components: Windows messages: 224304 nosy: rupole priority: normal severity: normal status: open title: tempfile module misinterprets access denied error on Windows versions: Python 2.7, Python 3.4 ___ Python tracker <http://bugs.python.org/issue22107> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue16253] Docs for PyArg_ParseTupleAndKeywords say it doesn't accept nested tuples
New submission from Roger Upole: The docs for this function state "Nested tuples cannot be parsed when using keyword arguments!" but this restriction was removed some time ago. -- assignee: docs@python components: Documentation messages: 173081 nosy: docs@python, rupole priority: normal severity: normal status: open title: Docs for PyArg_ParseTupleAndKeywords say it doesn't accept nested tuples ___ Python tracker <http://bugs.python.org/issue16253> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] get_shape0 in memoryobject.c not checked for error return
Roger Upole added the comment: While on the subject, the docs for PyMemoryView_FromBuffer state that the resulting memoryview takes ownership of the Py_buffer struct and is responsible for freeing any associated memory. It does not do so, which is not surprising. The absence of a standard for allocation makes it absolutely impossible for it to do so safely. -- ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Roger Upole added the comment: I know this has been closed, but I disagree with the fix. Py_FatalError is designed to give a clean exit with a readable error message when the state of the interpreter is known to be compromised. Calling *any* python functions or accessing *any* python internals is only likely to lead to more issues that obscure the original problems. IMO the PyErr_Occurred needs to be removed entirely. -- ___ Python tracker <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] get_shape0 in memoryobject.c not checked for error return
Roger Upole added the comment: The culprit wrt copying Py_buffer structs seems mainly to be dup_buffer, which is called in memory_getbuf. This seems unnecessary in the case where there's an underlying object and it has returned the view thru its own tp_as_buffer. The underlying object at that point is solely responsible for releasing the buffer, so memory_getbuf shouldn't mess with it at all. In the case where there is no underlying object (mainly thru PyMemoryView_FromBuffer), it probably should allocate any memory in the view in such a way that it can be freed in memory_releasebuf when the view->obj is NULL. -- ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue10181] get_shape0 in memoryobject.c not checked for error return
New submission from Roger Upole : There are a number of places in memoryobject.c where get_shape0 is used without the return value being checked. If it fails, this leads to hanging exceptions and crashes. -- components: Interpreter Core messages: 119460 nosy: rupole priority: normal severity: normal status: open title: get_shape0 in memoryobject.c not checked for error return type: crash versions: Python 3.2 ___ Python tracker <http://bugs.python.org/issue10181> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3946] PyObject_CheckReadBuffer crashes on memoryview object
New submission from Roger Upole <[EMAIL PROTECTED]>:
Sample code:
PyObject *b=PyBytes_FromString("eh ?");
PyObject *mv=PyMemoryView_FromObject(b);
PyObject_CheckReadBuffer(mv);
>From following the chain of calls in PyObject_CheckReadBuffer,
a few things are unclear.
It calls bf_getbuffer with a NULL Py_Buffer pointer, although the PEP
explicitely states that is should never be NULL.
PyBuffer_FillInfo immediately returns success if the view pointer is
NULL. I'm guessing this is to just determine if the operation could be
completed, but it returns before any checks are done.
It then attempts to release a hardcoded NULL Py_buffer pointer
which of course crashes.
--
messages: 73640
nosy: rupole
severity: normal
status: open
title: PyObject_CheckReadBuffer crashes on memoryview object
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3946>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3906] lib2to3\main.py will not run
New submission from Roger Upole <[EMAIL PROTECTED]>: On first try: File "H:\Python-3.0rc1\Lib\lib2to3\main.py", line 10, in from . import refactor ValueError: Attempted relative import in non-package And after changing that line to from lib2to3 import refactor it still dies with File "H:\Python-3.0rc1\Lib\lib2to3\main.py", line 86, in sys.exit(main()) TypeError: main() takes at least 1 positional argument (0 given) -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 73412 nosy: collinwinter, rupole severity: normal status: open title: lib2to3\main.py will not run versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3906> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Roger Upole <[EMAIL PROTECTED]> added the comment: Aha, thanks. I'll go that route for now. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Roger Upole <[EMAIL PROTECTED]> added the comment: As background, what I need is an equivalent of PyBuffer_New(size), which creates an object that manages its own buffer memory, and is not based on another object at all. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
Roger Upole <[EMAIL PROTECTED]> added the comment: Well it existed up until a couple hours ago ;). Looks like it was recently changed to PyMemoryView_FromBuffer. However, it still has the same issue. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3608] memoryview constructor has no deallocator
New submission from Roger Upole <[EMAIL PROTECTED]>: When using PyMemoryView_FromMemory to create a new object, you have to pass in a preallocated buffer. However, there's no way to specify a routine to free the memory, and it leaks when the object is destroyed. -- components: Interpreter Core messages: 71495 nosy: rupole severity: normal status: open title: memoryview constructor has no deallocator type: resource usage versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3608> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Roger Upole <[EMAIL PROTECTED]> added the comment: Well, you asked for a simple case. In practice, I'm dealing with much more complicated code that contains callbacks which may need to acquire or release the theadlock. This problem makes it very difficult to debug such code. Also, the PyErr_Occurred is not present in 2.5.2, probably for this very same reason. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
Roger Upole <[EMAIL PROTECTED]> added the comment: Py_BEGIN_ALLOW_THREADS PyErr_SetString(PyExc_SystemError, "bork bork bork"); Py_END_ALLOW_THREADS ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3453] PyType_Ready doesn't ensure that all bases are ready
Roger Upole <[EMAIL PROTECTED]> added the comment: This doesn't address the discrepancy between tp_base and tp_bases. If multiple bases are used, it's no longer 'good practice', it's an absolute requirement. IMO, it should call PyType_Ready for all bases, or none of them. Since the code assumes that all bases have been initialized, it could at least ASSERT so, rather than crashing deep within the mro calculations. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3605] Py_FatalError causes infinite loop
New submission from Roger Upole <[EMAIL PROTECTED]>: Py_FatalError calls PyErr_Occurred() which requires a current thread state. This mean that if the original error was a thread state error Py_FatalError is triggered again, ad infinitum. -- components: Interpreter Core messages: 71478 nosy: rupole severity: normal status: open title: Py_FatalError causes infinite loop versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3605> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3537] dict creation failure causes crash
New submission from Roger Upole <[EMAIL PROTECTED]>:
If the first item can't be inserted the interpreter will crash
eventually.
while 1:
try:
d = { 'a':a,
'b':'b',
'c':'c',
'd':'d',
'e':'e',
'f':'f',
'g':'g',
'h':'h',
'i':'i',
'j':'j',
'k':'k',
'l':'l',
'm':'m',
'n':'n',
'o':'o'
}
except:
pass
As best I can tell, this only happens for the first item.
In a debug build, this assert fails on the second time thru
the loop (dictobject.c, line 247):
assert (mp->ma_table == mp->ma_smalltable);
Apparently something is leaving one of the entries in the list
of preallocated dict objects in an inconsistent state.
--
messages: 70990
nosy: rupole
severity: normal
status: open
title: dict creation failure causes crash
versions: Python 3.0
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.python.org/issue3537>
___
___
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3534] refactor.py can lose indentation for relative imports
Roger Upole <[EMAIL PROTECTED]> added the comment: I was using 3.0b2. The output is correct with latest updates, sorry for the trouble. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3534] refactor.py can lose indentation for relative imports
New submission from Roger Upole <[EMAIL PROTECTED]>: Here's an excerpt from the output when run with --verbose. @@ -138,7 +136,7 @@ def _MakeColorizer(self): ext = os.path.splitext(self.GetDocument().GetPathName()) - import formatter +from . import formatter return formatter.BuiltinPythonSourceFormatter(self, ext) -- assignee: collinwinter components: 2to3 (2.x to 3.0 conversion tool) messages: 70947 nosy: collinwinter, rupole severity: normal status: open title: refactor.py can lose indentation for relative imports versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3534> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3453] PyType_Ready doesn't ensure that all bases are ready
Roger Upole <[EMAIL PROTECTED]> added the comment: If that were the case, it wouldn't need to call PyType_Ready for tp_base either. From stepping thru the code, there are several places in the interpreter core that PyType_Ready is called for types whose tp_base has not been initialized yet. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3453] PyType_Ready doesn't ensure that all bases are ready
New submission from Roger Upole <[EMAIL PROTECTED]>: If a type's tp_base has not been initialized yet, PyType_Ready calls itself for tp_base. However, it doesn't do the same for members of tp_bases. The inheritance determinations assume that all bases are ready, in particular that tp_mro is not null. -- components: Interpreter Core messages: 70322 nosy: rupole severity: normal status: open title: PyType_Ready doesn't ensure that all bases are ready versions: Python 2.4, Python 2.5, Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3453> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3120] subprocess module truncates handles on AMD64
Roger Upole <[EMAIL PROTECTED]> added the comment: This fixes the problem I had on 64-bit Vista, and all of python's own tests still pass. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3279] import of site.py fails on startup
New submission from Roger Upole <[EMAIL PROTECTED]>: In pythonrun.c, initstdio injects 'open' into builtins. However, initsite is called before initstdio and site.py uses open. Running with -v, this traceback is printed: Traceback (most recent call last): File "j:\python30\lib\site.py", line 518, in main() File "j:\python30\lib\site.py", line 501, in main known_paths = addsitepackages(known_paths) File "j:\python30\lib\site.py", line 281, in addsitepackages addsitedir(sitedir, known_paths) File "j:\python30\lib\site.py", line 178, in addsitedir addpackage(sitedir, name, known_paths) File "j:\python30\lib\site.py", line 141, in addpackage f = open(fullname, "rU") NameError: global name 'open' is not defined -- messages: 69240 nosy: rupole severity: normal status: open title: import of site.py fails on startup versions: Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3279> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3240] IDLE environment corrupts string.letters
Roger Upole <[EMAIL PROTECTED]> added the comment: It introduces high characters that cause comparisons to fail under IDLE that succeed from the normal python prompt: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import string >>> u'a' in string.letters True IDLE 1.2.2 >>> import string >>> u'a' in string.letters Traceback (most recent call last): File "", line 1, in u'a' in string.letters UnicodeDecodeError: 'ascii' codec can't decode byte 0x83 in position 52: ordinal not in range(128) Or am I misunderstanding how the locale works with string comparisons ? ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3240] IDLE environment corrupts string.letters
New submission from Roger Upole <[EMAIL PROTECTED]>: The problem seems to stem from this line in IOBinding.py: locale.setlocale(locale.LC_CTYPE, "") >From the command prompt: Python 2.5.2 (r252:60911, Feb 21 2008, 13:11:45) [MSC v.1310 32 bit (Intel)] on win32 Type "help", "copyright", "credits" or "license" for more information. >>> import string, locale >>> print repr(string.letters) 'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ' >>> locale.setlocale(locale.LC_CTYPE, "") 'English_United States.1252' >>> print repr(string.letters) 'ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz\x83 \x8a\x8c\x8e\x9a\x9c\x9 e\x9f\xaa\xb5\xba\xc0\xc1\xc2\xc3\xc4\xc5\xc6\xc7\xc8\xc9 \xca\xcb\xcc\xcd\xce\xc f\xd0\xd1\xd2\xd3\xd4\xd5\xd6\xd8\xd9\xda\xdb\xdc\xdd\xde\xdf\xe0\xe1 \xe2\xe3\xe 4\xe5\xe6\xe7\xe8\xe9\xea\xeb\xec\xed\xee\xef\xf0\xf1\xf2\xf3\xf4\xf5 \xf6\xf8\xf 9\xfa\xfb\xfc\xfd\xfe\xff' >>> -- components: IDLE messages: 68977 nosy: rupole severity: normal status: open title: IDLE environment corrupts string.letters versions: Python 2.3, Python 2.4, Python 2.5 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3240> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue3120] subprocess module truncates handles on AMD64
New submission from Roger Upole <[EMAIL PROTECTED]>: HANDLEs are pointer sized values, but there are several places in _subprocess.c where it assumes they are the same size as longs which are still 4 bytes on win64. -- components: Windows messages: 68263 nosy: rupole severity: normal status: open title: subprocess module truncates handles on AMD64 versions: Python 2.5, Python 2.6, Python 3.0 ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue3120> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue1474454] Allow PyArg_ParseTupleAndKeywords to unpack tuples
Roger Upole <[EMAIL PROTECTED]> added the comment: This functionality is subsumed in patch 1691070 (which has since been applied), so this can be closed. ___ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1474454> ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
