summaryrefslogtreecommitdiffstats
path: root/Objects/stringobject.c
Commit message (Collapse)AuthorAgeFilesLines
...
* Prevent expandtabs() on string and unicode objects from causing a segfault whenNeal Norwitz2007-06-091-3/+14
| | | | | | | a large width is passed on 32-bit platforms. Found by Google. It would be good for people to review this especially carefully and verify I don't have an off by one error and there is no other way to cause overflow.
* SF 1193128: Let str.translate(None) be an identity transformationRaymond Hettinger2007-04-121-8/+16
|
* Backport from Py3k branch: fix refleak in PyString_Format.Georg Brandl2007-02-261-1/+5
|
* Variation of patch # 1624059 to speed up checking if an object is a subclassNeal Norwitz2007-02-251-1/+1
| | | | | | | | | | | | | | | | | | of some of the common builtin types. Use a bit in tp_flags for each common builtin type. Check the bit to determine if any instance is a subclass of these common types. The check avoids a function call and O(n) search of the base classes. The check is done in the various Py*_Check macros rather than calling PyType_IsSubtype(). All the bits are set in tp_flags when the type is declared in the Objects/*object.c files because PyType_Ready() is not called for all the types. Should PyType_Ready() be called for all types? If so and the change is made, the changes to the Objects/*object.c files can be reverted (remove setting the tp_flags). Objects/typeobject.c would also have to be modified to add conditions for Py*_CheckExact() in addition to each the PyType_IsSubtype check.
* Whitespace only changesNeal Norwitz2007-02-251-3/+2
|
* Add more details when releasing interned stringsNeal Norwitz2007-02-251-1/+8
|
* Patch [ 1586791 ] better error msgs for some TypeErrorsGeorg Brandl2006-11-191-6/+10
|
* Forward-port of r52136,52138: a review of overflow-detecting code.Armin Rigo2006-10-041-6/+19
| | | | | | | | | | | | | | | | | | | | | | | * unified the way intobject, longobject and mystrtoul handle values around -sys.maxint-1. * in general, trying to entierely avoid overflows in any computation involving signed ints or longs is extremely involved. Fixed a few simple cases where a compiler might be too clever (but that's all guesswork). * more overflow checks against bad data in marshal.c. * 2.5 specific: fixed a number of places that were still confusing int and Py_ssize_t. Some of them could potentially have caused "real-world" breakage. * list.pop(x): fixing overflow issues on x was messy. I just reverted to PyArg_ParseTuple("n"), which does the right thing. (An obscure test was trying to give a Decimal to list.pop()... doesn't make sense any more IMHO) * trying to write a few tests...
* Fix endcase for str.rpartition()Raymond Hettinger2006-09-041-2/+2
|
* Fix refleak introduced in rev. 51248.Georg Brandl2006-08-141-1/+3
|
* Fix segfault when doing string formatting on subclasses of long ifNeal Norwitz2006-08-131-1/+4
| | | | | | __oct__, __hex__ don't return a string. Klocwork 308
* Patch #1538606, Patch to fix __index__() clipping.Neal Norwitz2006-08-121-5/+2
| | | | | | | I modified this patch some by fixing style, some error checking, and adding XXX comments. This patch requires review and some changes are to be expected. I'm checking in now to get the greatest possible review and establish a baseline for moving forward. I don't want this to hold up release if possible.
* Whitespace normalizationNeal Norwitz2006-07-301-35/+32
|
* Bug #1515471: string.replace() accepts character buffers again.Neal Norwitz2006-07-301-71/+51
| | | | Pass the char* and size around rather than PyObject's.
* Update doc to make it agree with code.Neal Norwitz2006-06-111-10/+4
| | | | Bottom factor out some common code.
* Apply perky's fix for #1503157: "/".join([u"", u""]) raising OverflowError.Georg Brandl2006-06-101-1/+1
| | | | Also improve error message on overflow.
* RFE #1491485: str/unicode.endswith()/startswith() now accept a tuple as ↵Georg Brandl2006-06-091-60/+90
| | | | first argument.
* Remove ; at end of macro. There was a compiler recently that warnedNeal Norwitz2006-06-011-1/+1
| | | | | about extra semi-colons. It may have been the HP C compiler. This file will trigger a bunch of those warnings now.
* needforspeed: added Py_MEMCPY macro (currently tuned for Visual C only),Fredrik Lundh2006-05-281-37/+37
| | | | | and use it for string copy operations. this gives a 20% speedup on some string benchmarks.
* needforspeed: stringlib refactoring: use find_slice for stringobjectFredrik Lundh2006-05-271-12/+15
|
* needforspeed: replace improvements, changed to Py_LOCAL_INLINEFredrik Lundh2006-05-271-16/+16
| | | | where appropriate
* cleanup - removed trailing whitespaceAndrew Dalke2006-05-271-1/+1
|
* needforspeed: more stringlib refactoringFredrik Lundh2006-05-271-55/+39
|
* Added description of why splitlines doesn't use the prealloc strategyAndrew Dalke2006-05-261-0/+8
|
* Added limits to the replace code so it does not count all of the matchingAndrew Dalke2006-05-261-22/+19
| | | | patterns in a string, only the number needed by the max limit.
* needforspeed: stringlib refactoring: use stringlib/find for string findFredrik Lundh2006-05-261-19/+6
|
* needforspeed: stringlib refactoring, continued. added count andFredrik Lundh2006-05-261-2/+2
| | | | find helpers; updated unicodeobject to use stringlib_count
* substring split now uses /F's fast string matching algorithm.Andrew Dalke2006-05-261-40/+57
| | | | | | | | | | (If compiled without FAST search support, changed the pre-memcmp test to check the last character as well as the first. This gave a 25% speedup for my test case.) Rewrote the split algorithms so they stop when maxsplit gets to 0. Previously they did a string match first then checked if the maxsplit was reached. The new way prevents a needless string search.
* needforspeed: added rpartition implementationFredrik Lundh2006-05-261-0/+36
|
* needforspeed: remove remaining USE_FAST macros; if fastsearch wasFredrik Lundh2006-05-261-67/+2
| | | | broken, someone would have noticed by now ;-)
* needforspeed: cleanupFredrik Lundh2006-05-261-4/+8
|
* needforspeed: stringlib refactoring (in progress)Fredrik Lundh2006-05-261-34/+5
|
* needforspeed: stringlib refactoring (in progress)Fredrik Lundh2006-05-261-92/+7
|
* needforspeed: use Py_LOCAL on a few more locals in stringobject.cFredrik Lundh2006-05-261-26/+27
|
* Eeked out another 3% or so performance in split whitespace by cleaning up ↵Andrew Dalke2006-05-261-35/+38
| | | | the algorithm.
* Changes to string.split/rsplit on whitespace to preallocate space in theAndrew Dalke2006-05-261-56/+75
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | results list. Originally it allocated 0 items and used the list growth during append. Now it preallocates 12 items so the first few appends don't need list reallocs. ("Here are some words ."*2).split(None, 1) is 7% faster ("Here are some words ."*2).split() is is 15% faster (Your milage may vary, see dealership for details.) File parsing like this for line in f: count += len(line.split()) is also about 15% faster. There is a slowdown of about 3% for large strings because of the additional overhead of checking if the append is to a preallocated region of the list or not. This will be the rare case. It could be improved with special case code but we decided it was not useful enough. There is a cost of 12*sizeof(PyObject *) bytes per list. For the normal case of file parsing this is not a problem because of the lists have a short lifetime. We have not come up with cases where this is a problem in real life. I chose 12 because human text averages about 11 words per line in books, one of my data sets averages 6.2 words with a final peak at 11 words per line, and I work with a tab delimited data set with 8 tabs per line (or 9 words per line). 12 encompasses all of these. Also changed the last rstrip code to append then reverse, rather than doing insert(0). The strip() and rstrip() times are now comparable.
* use Py_LOCAL also for string and unicode objectsFredrik Lundh2006-05-261-13/+1
|
* needforspeed: use Py_ssize_t for the fastsearch counter and skipFredrik Lundh2006-05-261-1/+1
| | | | | length (thanks, neal!). and yes, I've verified that this doesn't slow things down ;-)
* needforspeed: use METH_O for argument handling, which made partition someFredrik Lundh2006-05-261-6/+2
| | | | | ~15% faster for the current tests (which is noticable faster than a corre- sponding find call). thanks to neal-who-never-sleeps for the tip.
* needforspeed: partition implementation, part two.Fredrik Lundh2006-05-261-15/+15
| | | | feel free to improve the documentation and the docstrings.
* needforspeed: partition for 8-bit strings. for some simple tests,Fredrik Lundh2006-05-251-5/+66
| | | | | | | | this is on par with a corresponding find, and nearly twice as fast as split(sep, 1) full tests, a unicode version, and documentation will follow to- morrow.
* squelch gcc4 darwin/x86 compiler warningsBob Ippolito2006-05-251-1/+1
|
* needforspeed: use insert+reverse instead of appendFredrik Lundh2006-05-251-16/+8
|
* * eliminate warning by reverting tmp_s type to 'const char*'Jack Diederich2006-05-251-1/+1
|
* needforspeed: use fastsearch also for find/index and contains. theFredrik Lundh2006-05-251-1/+25
| | | | related tests are now about 10x faster.
* Added overflow test for adding two (very) large strings where theAndrew Dalke2006-05-251-2/+7
| | | | | new string is over max Py_ssize_t. I have no way to test it on my box or any box I have access to. At least it doesn't break anything.
* Comment typoAndrew M. Kuchling2006-05-251-1/+1
|
* needforspeed: use "fastsearch" for count. this results in a 3x speedupFredrik Lundh2006-05-251-1/+122
| | | | for the related stringbench tests.
* Fixed problem identified by Georg. The special-case in-place code for replaceAndrew Dalke2006-05-251-2/+5
| | | | | | | | | | | made a copy of the string using PyString_FromStringAndSize(s, n) and modify the copied string in-place. However, 1 (and 0) character strings are shared from a cache. This cause "A".replace("A", "a") to change the cached version of "A" -- used by everyone. Now may the copy with NULL as the string and do the memcpy manually. I've added regression tests to check if this happens in the future. Perhaps there should be a PyString_Copy for this case?
* needforspeed: new replace implementation by Andrew Dalke. replace isFredrik Lundh2006-05-251-182/+605
| | | | | now about 3x faster on my machine, for the replace tests from string- bench.
generated by cgit v0.12 at 2025-08-09 14:10:37 (GMT)