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.py
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/is
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 ma
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
priori
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
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
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 obje
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
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
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 d
Roger Upole <[EMAIL PROTECTED]> added the comment:
Aha, thanks. I'll go that route for now.
___
Python tracker <[EMAIL PROTECTED]>
<http://bugs.
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
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 PROTECTE
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.
--
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.
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://
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,
o
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:
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':'
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.pytho
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
+fr
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 init
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 particula
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.
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:\python
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", "cop
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
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:
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.o
29 matches
Mail list logo
