[issue1259] string find and rfind methods give a TypeError that is misleading

2007-11-16 Thread Facundo Batista

Facundo Batista added the comment:

Moved the function to find.h, cleaned the whitespace issues and
documented the reference counting.

Commited in trunk, rev 59020.

Thanks everybody!

--
resolution:  -> fixed
status: open -> closed

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-11-01 Thread Barry A. Warsaw

Barry A. Warsaw added the comment:

facundo, robert and i looked at this patch and it seems okay. 
suggestions: document the reference count semantics of
_ParseTupleFinds() and include a definition of that function in a .h
file.  since its non-public, maybe find.h is the right place to put it?

there also some random addition of trailing whitespace in the last hunk
of stringobject.c

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-11-01 Thread Facundo Batista

Facundo Batista added the comment:

Created the patch, also send a mail to python-dev to see if somebody
wants to review it before me applying it.

--
assignee:  -> facundobatista
Added file: http://bugs.python.org/file8672/string_find.patch

__
Tracker <[EMAIL PROTECTED]>

__Index: Objects/unicodeobject.c
===
--- Objects/unicodeobject.c	(revisión: 58710)
+++ Objects/unicodeobject.c	(copia de trabajo)
@@ -6027,6 +6027,46 @@
 return (PyObject*) u;
 }
 
+/*
+This function is a helper for the "find" family (find, rfind, index,
+rindex), because they all have the same behaviour for the arguments.
+
+It does not touch the variables received until it knows everything 
+is ok.
+*/
+
+int 
+_ParseTupleFinds (PyObject *args, PyObject **substring, 
+  Py_ssize_t *start, Py_ssize_t *end) {
+PyObject *tmp_substring;
+Py_ssize_t tmp_start = 0;
+Py_ssize_t tmp_end = PY_SSIZE_T_MAX;
+PyObject *obj_start=Py_None, *obj_end=Py_None;
+
+if (!PyArg_ParseTuple(args, "O|OO:find", &tmp_substring,
+ &obj_start, &obj_end))
+return 0;
+
+/* To support None in "start" and "end" arguments, meaning
+   the same as if they were not passed.
+*/
+if (obj_start != Py_None)
+if (!_PyEval_SliceIndex(obj_start, &tmp_start))
+return 0;
+if (obj_end != Py_None)
+if (!_PyEval_SliceIndex(obj_end, &tmp_end))
+return 0;
+
+tmp_substring = PyUnicode_FromObject(tmp_substring);
+if (!tmp_substring)
+return 0;
+
+*start = tmp_start;
+*end = tmp_end;
+*substring = tmp_substring;
+return 1;
+}
+
 PyDoc_STRVAR(find__doc__,
 "S.find(sub [,start [,end]]) -> int\n\
 \n\
@@ -6040,16 +6080,12 @@
 unicode_find(PyUnicodeObject *self, PyObject *args)
 {
 PyObject *substring;
-Py_ssize_t start = 0;
-Py_ssize_t end = PY_SSIZE_T_MAX;
+Py_ssize_t start;
+Py_ssize_t end;
 Py_ssize_t result;
 
-if (!PyArg_ParseTuple(args, "O|O&O&:find", &substring,
-		_PyEval_SliceIndex, &start, _PyEval_SliceIndex, &end))
+if (!_ParseTupleFinds(args, &substring, &start, &end))
 return NULL;
-substring = PyUnicode_FromObject(substring);
-if (!substring)
-	return NULL;
 
 result = stringlib_find_slice(
 PyUnicode_AS_UNICODE(self), PyUnicode_GET_SIZE(self),
@@ -6110,15 +6146,11 @@
 {
 Py_ssize_t result;
 PyObject *substring;
-Py_ssize_t start = 0;
-Py_ssize_t end = PY_SSIZE_T_MAX;
+Py_ssize_t start;
+Py_ssize_t end;
 
-if (!PyArg_ParseTuple(args, "O|O&O&:index", &substring,
-		_PyEval_SliceIndex, &start, _PyEval_SliceIndex, &end))
+if (!_ParseTupleFinds(args, &substring, &start, &end))
 return NULL;
-substring = PyUnicode_FromObject(substring);
-if (!substring)
-	return NULL;
 
 result = stringlib_find_slice(
 PyUnicode_AS_UNICODE(self), PyUnicode_GET_SIZE(self),
@@ -6781,16 +6813,12 @@
 unicode_rfind(PyUnicodeObject *self, PyObject *args)
 {
 PyObject *substring;
-Py_ssize_t start = 0;
-Py_ssize_t end = PY_SSIZE_T_MAX;
+Py_ssize_t start;
+Py_ssize_t end;
 Py_ssize_t result;
 
-if (!PyArg_ParseTuple(args, "O|O&O&:rfind", &substring,
-		_PyEval_SliceIndex, &start, _PyEval_SliceIndex, &end))
-return NULL;
-substring = PyUnicode_FromObject(substring);
-if (!substring)
-	return NULL;
+if (!_ParseTupleFinds(args, &substring, &start, &end))
+	return NULL;
 
 result = stringlib_rfind_slice(
 PyUnicode_AS_UNICODE(self), PyUnicode_GET_SIZE(self),
@@ -6812,16 +6840,12 @@
 unicode_rindex(PyUnicodeObject *self, PyObject *args)
 {
 PyObject *substring;
-Py_ssize_t start = 0;
-Py_ssize_t end = PY_SSIZE_T_MAX;
+Py_ssize_t start;
+Py_ssize_t end;
 Py_ssize_t result;
 
-if (!PyArg_ParseTuple(args, "O|O&O&:rindex", &substring,
-		_PyEval_SliceIndex, &start, _PyEval_SliceIndex, &end))
-return NULL;
-substring = PyUnicode_FromObject(substring);
-if (!substring)
-	return NULL;
+if (!_ParseTupleFinds(args, &substring, &start, &end))
+	return NULL;
 
 result = stringlib_rfind_slice(
 PyUnicode_AS_UNICODE(self), PyUnicode_GET_SIZE(self),
Index: Objects/stringobject.c
===
--- Objects/stringobject.c	(revisión: 58710)
+++ Objects/stringobject.c	(copia de trabajo)
@@ -1879,16 +1879,28 @@
 	const char *sub;
 	Py_ssize_t sub_len;
 	Py_ssize_t start=0, end=PY_SSIZE_T_MAX;
+	PyObject *obj_start=Py_None, *obj_end=Py_None;
 
-	if (!PyArg_ParseTuple(args, "O|O&O&:find/rfind/index/rindex", &subobj,
-		_PyEval_SliceIndex, &start, _PyEval_SliceIndex, &end))
+	if (!PyArg_ParseTuple(args, "O|OO:find/rfind/index/rindex", &subobj,
+		&obj_start, &obj_end))
 		return -2;
+	/* To support None in "start" and "e

[issue1259] string find and rfind methods give a TypeError that is misleading

2007-10-16 Thread Wummel

Wummel added the comment:

I also hit this bug. The .index() methods have the same issue,
as well as the methods in the string and strop modules:

>>> "123".index("2", None)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: slice indices must be integers or None
>> import strop, string
>>> strop.rfind("123", "2", None)
Traceback (most recent call last):
  File "", line 1, in ?
TypeError: an integer is required
>>> string.rfind("123", "2", None)
Traceback (most recent call last):
  File "", line 1, in ?
  File "/usr/lib/python2.4/string.py", line 374, in rfind
return s.rfind(*args)
TypeError: slice indices must be integers or None
>>>

--
nosy: +calvin

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-10-15 Thread Robert Collins

Robert Collins added the comment:

> The error message is wrong: it's a TypeError, but the message should say
> something like...
> 
>   TypeError: slice indices must be integers or have an __index__ method

This would be a false message, as, as my report demonstrated, slice
indices *can* be None. And there is a very good reason for accepting
None in the second parameter in slice notation as there is no value for
'-0' to represent the end of the region being sliced, and None meaning
'default' fills that need most effectively.

Surely the right fix is as Barry noted, to handle None correctly within
this function?

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-10-15 Thread Facundo Batista

Facundo Batista added the comment:

Documentation for find():

str.find(sub[, start[, end]])
Return the lowest index in the string where substring sub is found,
such that sub is contained in the range [start, end]. Optional arguments
start and end are interpreted as in slice notation. Return -1 if sub is
not found.

I think that it shouldn't be possible to call it with None arguments. 

The error message is wrong: it's a TypeError, but the message should say
something like...

  TypeError: slice indices must be integers or have an __index__ method

If you're ok with this change, assign this bug to me and I'll fix it.

Regards,

--
nosy: +facundobatista

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-10-10 Thread Barry A. Warsaw

Barry A. Warsaw added the comment:

I believe this is because string_find_internal() uses an O& with
_PyEval_SliceIndex() to convert its start and end arguments, but the
latter function does not accept None.  To fix this, you'd have to change
string_find_internal() to do its own argument checking for None before
calling _PyEval_SliceIndex.

--
nosy: +barry

__
Tracker <[EMAIL PROTECTED]>

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



[issue1259] string find and rfind methods give a TypeError that is misleading

2007-10-10 Thread Robert Collins

New submission from 
Robert Collins
:

Python 2.5.1 (r251:54863, May  2 2007, 16:56:35) 
[GCC 4.1.2 (Ubuntu 4.1.2-0ubuntu4)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> 'asd'.find('s', None, None)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: slice indices must be integers or None or have an __index__
method
>>> 'asd'.rfind('s', None, None)
Traceback (most recent call last):
  File "", line 1, in 
TypeError: slice indices must be integers or None or have an __index__
method
>>> # Note that this works, at the price of a memory copy,
>>> # and on large strings that is undesirable.
>>> 'asd'[None:None].find('s')
1
>>> 'asd'[None:None].rfind('s')
1
>>>

--
messages: 56332
nosy: rbcollins
severity: normal
status: open
title: string find and rfind methods give a TypeError that is misleading
versions: Python 2.5

__
Tracker <[EMAIL PROTECTED]>

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