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 rep...@bugs.python.org
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 rep...@bugs.python.org
http://bugs.python.org/issue22107
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
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
Roger Upole rup...@hotmail.com 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
Roger Upole rup...@hotmail.com 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
Roger Upole rup...@hotmail.com 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
New submission from Roger Upole rup...@hotmail.com:
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
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
New submission from Roger Upole [EMAIL PROTECTED]:
On first try:
File H:\Python-3.0rc1\Lib\lib2to3\main.py, line 10, in module
from . import refactor
ValueError: Attempted relative import in non-package
And after changing that line to
from lib2to3 import refactor
it still dies
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
27 matches
Mail list logo
