Martin v. Löwis [EMAIL PROTECTED] added the comment:
Is any of the patches believed to be ready?
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1868
___
___
Akira Kitada [EMAIL PROTECTED] added the comment:
The new patch attached renamed Py_GCC_ATTRIBUTE to Py_GCC_FORMAT_ATTRIBUTE.
As Roumen pointed out, the current python code use Py_GCC_ATTRIBUTE
only for 'format(printf(...)) ' attribute., so this change should not
be no harm itself.
Because a
Changes by Akira Kitada [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12124/pyport.h.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4370
___
Tal Einat [EMAIL PROTECTED] added the comment:
First of all, the multiprocessing module doesn't work fully in an
interactive shell.
From the Python2.6 docs:
Note Functionality within this package requires that the __main__
method be importable by the children. This is covered in Programming
Changes by Akira Kitada [EMAIL PROTECTED]:
Added file: http://bugs.python.org/file12160/issue4370.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4370
___
Akira Kitada [EMAIL PROTECTED] added the comment:
Tested my patch on
* FreeBSD 4.11 (gcc version 2.95.4, does not support z)
* FreeBSD 6.3 (gcc version 3.4.6, supports z)
and it worked fine on both. (using trunk)
___
Python tracker [EMAIL PROTECTED]
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I'm opposed to applying this patch to a maintenance branch. It removes
the Py_GCC_ATTRIBUTE macro, which some extension modules might rely on.
I also wonder whether it is really necessary to complicate the code just
so that gcc 2.95 stops
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Reconsidering: I think the needs review keyword should only be applied
if there is a single patch associated with the issue that needs review.
So anybody setting the keyword should remove all patches that don't need
review anymore (as they are
Martin v. Löwis [EMAIL PROTECTED] added the comment:
According to msg76581, the patch fails review (lacking test cases), so
I'm removing the needs review keyword.
--
keywords: -needs review
nosy: +loewis
___
Python tracker [EMAIL PROTECTED]
David M. Beazley [EMAIL PROTECTED] added the comment:
I agree with previous comments that write() should definitely write all
data when in blocking mode.
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4428
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I don't think this is quite right yet. If I run
import socket
s=socket.socket()
s.connect(('www.python.org',80))
x=s.makefile()
del x
del s
and put a print statement into real_close, I don't see that real_close
is invoked.
--
nosy:
Akira Kitada [EMAIL PROTECTED] added the comment:
Martin,
Thank you for the feedback.
I think we can avoid the problem that would be introduced by the removal
of Py_GCC_ATTRIBUTE by leaving it as is
(probably adding #warning this macro is deprecated. Please use
Py_GCC_FORMAT_ATTRIBUTE instead).
Martin v. Löwis [EMAIL PROTECTED] added the comment:
Ok. Removing 2.5.3 from the target releases until a decision is made
(and potentially a new patch is available).
--
versions: -Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
Amaury Forgeot d'Arc [EMAIL PROTECTED] added the comment:
But real_close() is not called either in the trivial socket use:
import socket
s=socket.socket()
s.connect(('www.python.org',80))
del s
OTOH, I added some printf statements in socketmodule.c, near all usages
of SOCKETCLOSE(). They show
New submission from John5342 [EMAIL PROTECTED]:
When using bdist_rpm the %build section of the generated spec file
contains the following:
env CFLAGS=$RPM_OPT_FLAGS python setup.py build
This works fine until the python is installed using altinstall. In this
situation the spec file will use
Christian Heimes [EMAIL PROTECTED] added the comment:
I was wrong and the patch is right. Something is wrong in
multiprocessings connection_recvbytes_into() function for the old buffer
protocol. Somehow PyArg_ParseTuple(args, w#| ...) fucks up the
process' memory.
Martin, are you fine with the
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I don't think I understand this report. The TransportSubclassTestCase
class tests the behavior of overridable methods that don't exist in
Python 3.0. Is this really a Python 3.0 problem? I'm not sure why we
expect it to work there.
Jeremy
Benjamin Peterson [EMAIL PROTECTED] added the comment:
On Sat, Nov 29, 2008 at 10:21 AM, Jeremy Hylton [EMAIL PROTECTED] wrote:
Jeremy Hylton [EMAIL PROTECTED] added the comment:
I don't think I understand this report. The TransportSubclassTestCase
class tests the behavior of overridable
Changes by Benjamin Peterson [EMAIL PROTECTED]:
--
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4456
___
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Modules/_sre.c(match_getindex)
Line 2766
The parameter of PyInt_AsSsize_t() is not checked to see if it is NULL.
--
components: None
messages: 76600
nosy: CWRU_Researcher1
severity: normal
status: open
title: The
Roumen Petrov [EMAIL PROTECTED] added the comment:
My idea was not to remove Py_GCC_ATTRIBUTE but the new macro with
specific name that use Py_GCC_ATTRIBUTE.
If macro name is Py_GCC_FORMAT_ATTRIBUTE then something similar to :
#if !defined(PY_FORMAT_SIZE_T)
#define Py_GCC_FORMAT_ATTRIBUTE(type,
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Python/ast.c(parsenumber)
Line 3061
The parameters of PyLong_FromString() are not checked for NULL before
the method is called.
--
components: None
messages: 76602
nosy: CWRU_Researcher1
severity: normal
status: open
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Python/import.c(find_module)
Lines 1171
PyString_Check() is not called on the result of PyList_GetItem(), nor is
the result checked to see if it is NULL.
--
components: None
messages: 76603
nosy: CWRU_Researcher1
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Python/import.c(get_path_importer)
Lines 1079
PyString_Check() is not called on the result of PyList_GetItem() and the
parameters of PyList_GetItem() are not validated before the method is
called.
--
components: None
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Python/codecs.c(_PyCodec_Lookup)
Lines 106, 144
PyString_Check() is not called on the result of PyList_GetItem() and the
first parameter of PyList_GetItem() does not have PyList_Check() called
on it.
(See
Changes by Akira Kitada [EMAIL PROTECTED]:
--
versions: +Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4368
___
___
Python-bugs-list
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Objects/setobject.c
Line 1204
The result of set_copy() is not checked for NULL.
[See Objects/setobject.c(set_difference) for example of correct usage]
--
components: None
messages: 76606
nosy: CWRU_Researcher1
severity:
Mark Dickinson [EMAIL PROTECTED] added the comment:
I'm confused. I'm probably missing something, but why do you think such a
check is necessary? The code I'm seeing at around line 2766 is:
static Py_ssize_t
match_getindex(MatchObject* self, PyObject* index)
{
Py_ssize_t i;
if
Mark Dickinson [EMAIL PROTECTED] added the comment:
I believe the code is correct as it is. The relevant lines are in
set_intersection:
if ((PyObject *)so == other)
return set_copy(so);
If the result of the set_copy is NULL then the NULL is passed directly
back to the
Brian Szuter [EMAIL PROTECTED] added the comment:
abstract.c(PyNumber_AsSsize_t) shows this check of PyInt_AsSsize_t()'s
parameter:
980:if (value == NULL)
981:return -1;
982:
983:/* We're done if PyInt_AsSsize_t() returns without error. */
984:result =
Raymond Hettinger [EMAIL PROTECTED] added the comment:
The code is correct as-is.
--
nosy: +rhettinger
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4465
___
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Modules/posixmodule.c(posix_tmpfile)
Line 6841
The return value of PyFile_FromFile is not checked for NULL
See the following where it is checked:
tokenizer.c(fp_setreadl) 429
fileobject.c(PyFile_FromString) 300
Mark Dickinson [EMAIL PROTECTED] added the comment:
abstract.c(PyNumber_AsSsize_t) shows this check of PyInt_AsSsize_t()'s
parameter:
Yup. And that's because 'value' is the return value from
PyNumber_Index. PyNumber_Index might return NULL, so the check is
necessary.
Am closing this as
Mark Dickinson [EMAIL PROTECTED] added the comment:
See explanation for issue 4465.
--
nosy: +marketdickinson
resolution: - invalid
status: open - closed
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4466
New submission from Brian Szuter [EMAIL PROTECTED]:
Python-2.5.2/Objects/unicodeobject.c(unicode_str)
Line 6816
The return value of PyUnicode_AsEncodedString() is not checked for NULL.
According to
http://www.python.org/doc/2.5.2/api/builtinCodecs.html#l2h-519 this
indicates an exception
Mark Dickinson [EMAIL PROTECTED] added the comment:
See explanation for issue 4466.
It seems to me that you have some misunderstandings about the way that
Python works. Please could you refrain from introducing new issues here
unless you're sure that they really *are* issues.
If you're
Raymond Hettinger [EMAIL PROTECTED] added the comment:
PyObject *hook = PyList_GetItem(meta_path, i);
loader = PyObject_CallMethod(hook, find_module,
sO, fullname, path != NULL ? path : Py_None);
The hook pointer is checked for NULL in PyObject_CallMethod() -- see
line 1947 in
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Python/codecs.c line 144-147:
func = PyList_GetItem(interp-codec_search_path, i);
if (func == NULL)
goto onError;
result = PyEval_CallObject(func, args);
The func result is expected to be a callable, not
Raymond Hettinger [EMAIL PROTECTED] added the comment:
Python/import.c lines: 1078-1082:
for (j = 0; j nhooks; j++) {
PyObject *hook = PyList_GetItem(path_hooks, j);
if (hook == NULL)
return NULL;
importer =
Tal Einat [EMAIL PROTECTED] added the comment:
Attaching a new patch against a more recent revision (resolved minor
conflict).
Only 3 extremely minor changes from previous patch: fixed two more
places where the parent was being passed explicitly (no longer required)
and changed two tabs -
Raymond Hettinger [EMAIL PROTECTED] added the comment:
This is an internal call, so am not worried about const char *s being
NULL -- that duty belongs to the caller who creates the pointer in the
first place. That being said, it wouldn't hurt to add an assertion at
the beginning of the
Mark Dickinson [EMAIL PROTECTED] added the comment:
Patch looks fine. (!)
Okay just to apply this to 2.6 and up? It's not a bugfix.
--
versions: -Python 2.5.3
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4461
John Smith [EMAIL PROTECTED] added the comment:
Hi, when will this patch be checkedin?
--
versions: +Python 2.5.3, Python 2.6, Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1706039
___
Akira Kitada [EMAIL PROTECTED] added the comment:
I'm just curious to know which is the right behavior.
# Python 3.0
Traceback (most recent call last):
File bad_range.py, line 7, in module
print(range(MyInt(2**3), MyInt(2**3+10)))
TypeError: 'MyInt' object cannot be interpreted as an
Robert Bradshaw [EMAIL PROTECTED] added the comment:
I think *both* behaviors are wrong, the 3.0 one is backwards
incompatible, and the 2.7 one is inconsistent (accepting MyInt if it's
32 bits, rejecting it for 64 bits).
For our particular use case, it is very annoying to not be able to use
Gregory P. Smith [EMAIL PROTECTED] added the comment:
Martin: socket.socket has no destructor so a call to
socket.socket._real_close() is not guaranteed. Thats fine as its parent
class from socketmodule.c _socket.socket does the right thing in its
destructor.
Amaury: The case you show doesn't
Mark Dickinson [EMAIL PROTECTED] added the comment:
So the obvious quick fix is, on OS X only, to set the locale to e.g.
en_US.UTF-8 instead of just before the mbstowcs call.
Here's a patch that does this.
I don't like this much, though. For one thing, I don't have any reason
to believe
Changes by Antoine Pitrou [EMAIL PROTECTED]:
--
nosy: +pitrou
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4426
___
___
Python-bugs-list mailing list
Changes by Antoine Pitrou [EMAIL PROTECTED]:
--
nosy: +pitrou
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue4425
___
___
Python-bugs-list mailing list
Antoine Pitrou [EMAIL PROTECTED] added the comment:
It's not /exactly/ nonsense, it seems to assume an utf8 encoding pass is
necessary:
b'\xe1\x80\x80'.decode('utf8') == '\u1000'
True
IMO, while accepting unicode strings instead of bytes for the a2b_xx
functions is understandable (because in
Antoine Pitrou [EMAIL PROTECTED] added the comment:
Hmm, I obviously meant:
[...] In other words, it might/should be ok for
`binascii.a2b_base64('YWFh\n')` to return the same as
`binascii.a2b_base64(b'YWFh\n')` (that is, b'aaa') [...]
___
Python tracker
Akira Kitada [EMAIL PROTECTED] added the comment:
Updating versions.
--
versions: +Python 2.5.3, Python 2.6, Python 2.7, Python 3.0
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue1533
___
Gregory P. Smith [EMAIL PROTECTED] added the comment:
gps05.diff includes the fix and unittests.
Added file: http://bugs.python.org/file12165/issue3826_gps05.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3826
Changes by Gregory P. Smith [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12154/issue3826_socket-gps03.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3826
___
Changes by Gregory P. Smith [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12156/test_makefileclose.patch
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3826
___
Changes by Gregory P. Smith [EMAIL PROTECTED]:
Removed file: http://bugs.python.org/file12163/issue3826_socket-gps04.diff
___
Python tracker [EMAIL PROTECTED]
http://bugs.python.org/issue3826
___
Martin v. Löwis [EMAIL PROTECTED] added the comment:
I don't like this much, though. For one thing, I don't have any reason
to believe that the particular locale en_US.UTF-8 will be supported on
any given installation of OS X.
I'm opposed to this patch for the same reason.
Anyone have
Gabriel Genellina [EMAIL PROTECTED] added the comment:
--- El vie 28-nov-08, Gregory P. Smith [EMAIL PROTECTED] escribió:
P.S. Gabriel Genellina (gagenellina) - Your comment
sounded like you
had a unit test for this but it never got attached. Still
have it?
I've found it; it uses
58 matches
Mail list logo
