Proposed patch factors out the implementation of bytes and bytearray by moving common code in separate files. This is not new approach, the part of the code is already shared.

The patch decreases the size of the source code by 862 lines.

If I follow this correctly, then it seems like there are two
main pieces to this patch:

1. Consolidating the following methods into bytes_methods.c:

   a. {bytes, bytearray}_find_internal

   b. {bytes, bytearray}_find

   c. {bytes, bytearray}_count

   d. {bytes, bytearray}_index

   e. {bytes, bytearray}_rfind

   f. {bytes, bytearray}_rindex

   g. {bytes, bytearray}_contains

   h. (_bytes, _bytearray}_tailmatch

   i. {bytes, bytearray}_startswith

   j. {bytes, bytearray}_endswith

2. Consolidating the redundant implementations of the following functions
   into the stringlib:

   a. return_self

   b. countchar

   c. replace_interleave

   d. replace_delete_single_character

   e. replace_delete_substring

   f. replace_single_character_in_place

   g. replace_substring_in_place

   h. replace_single_character

   i. replace_substring

   j. replace

If so, then that seems reasonable to me and a nice cleanup.

A few comments:

1. The diffs are fairly large. It might be easier to follow if you stage
   the two steps above as separate commits (if possible).

2. Why are some of the namings in stringlib inconsistent? For example,
   stringlib_method_find and stringlib_index. In other words, why
   do some names have the method part?

1. The diffs are fairly large. It might be easier to follow if you stage
   the two steps above as separate commits (if possible).

OK. Here is the first part of the patch. It moves common code and docstrings in bytes_methods.c.

2. Why are some of the namings in stringlib inconsistent? For example,
   stringlib_method_find and stringlib_index. In other words, why
   do some names have the method part?

There were conflicts with existing names stringlib_find and stringlib_rfind.

New changeset 41969033eb9d by Serhiy Storchaka in branch 'default':
Issue bpo-26765: Moved common code and docstrings for bytes and bytearray methods
https://hg.python.org/cpython/rev/41969033eb9d

Here is the second part of the patch. It moves common code for replace() method to template file Objects/stringlib/transmogrify.h.

LGTM.

New changeset f4406d746d27 by Serhiy Storchaka in branch 'default':
Issue bpo-26765: Moved common code for the replace() method of bytes and bytearray
https://hg.python.org/cpython/rev/f4406d746d27

Thank you Meador.

Stage 3 patch is simple. It just adds guards in bytes-specific and unicode-specific template files to be sure that they are not used with wrong type.

Stage 4 patch moves thin wrappers around functions from bytes_methods.c to Objects/stringlib/transmogrify.h. The _method_ suffix is added to some names to distinguish them from existing stringlib names.

I'm not sure this is a good place. It may be better to add separate file (I'm going to move more simple wrappers here), but I don't have good name for it (bytes_methods.h is already used). Any ideas?

New changeset c6c1882ecc77 by Serhiy Storchaka in branch 'default':
Issue bpo-26765: Ensure that bytes- and unicode-specific stringlib files are used
https://hg.python.org/cpython/rev/c6c1882ecc77

New changeset b0087e17cd5e by Serhiy Storchaka in branch 'default':
Issue bpo-26765: Moved wrappers for bytes and bytearray methods to common header
https://hg.python.org/cpython/rev/b0087e17cd5e

Serhiy, compiling 3.6 on Windows after this patch lets it start, but causes it to crash both importing tkinter and running patchcheck. Compiling 3.6 after your previous patch for bpo-27007 and the test suite runs without error.

Checking, I see that 3 of 4 Windows buildbots ran with this patch, so there must be something significantly different about my VS install with respect to this particular patch. bpo-26624 might or might not have something to do with it (see my posts today). I can't tell from the logs which update the buildbots are running.

The fourth, x86windows7 crashed before running anything (http://buildbot.python.org/all/builders/x86%20Windows7%203.x/builds/11283/steps/test/logs/stdio), after having previously run part way through the tests. It *might* have a similar problem, or might not.

New changeset 0638047c0c36 by Serhiy Storchaka in branch 'default':
Issue bpo-26765: Fixed parsing Py_ssize_t arguments on 32-bit Windows.
https://hg.python.org/cpython/rev/0638047c0c36

New changeset 6c4c0a23fabb by Serhiy Storchaka in branch 'default':
Backed out changeset b0087e17cd5e (issue bpo-26765)
https://hg.python.org/cpython/rev/6c4c0a23fabb

I don't know what is wrong with this patch. Backed out just for the case.