[issue1261] PEP 3137: make bytesobject.c methods

[Guido van Rossum]

Guido van Rossum added the comment:

Very impressive!

(Apologies if these lines are occasionally out of order.)

+extern PyObject* _bytes_isspace(const char *cptr, const Py_ssize_t len);

IMO all these functions should have names starting with _Py or _Py_,
since they are visible to the linker.

Also, why 'const Py_ssize_t'? It's a scalar!

+/* these store their len sized answer in the given preallocated *result
arg */

Mind using a Capital first letter?

+extern const char isspace__doc__[];

This needs a _Py or _Py_ prefix too.

+extern const unsigned int ctype_table[256];

Now this is no longer static, it also needs a _Py or _Py_ prefix.

+extern const unsigned char ctype_tolower[256];
+extern const unsigned char ctype_toupper[256];

Ditto (the macros are fine though, since they are only visible to code
that #includes this file, which is only a few files).

+Return True if all characters in S are whitespace\n\

Shouldn't that be bytes instead of characters (and consistently
throughout)?  And probably use B for the variable name instead of S.

+/* ------- GPS --------- */

What's this?  Your initials? :-)  I don't think it's needed.  I'm
guessing you 

 /* The nullbytes are used by the stringlib during partition.
  * If partition is removed from bytes, nullbytes and its helper

This comment block refers to something that ain't gonna happen
(partition being removed).  IMO the whole comment block can go, it's a
red herring.

+                /* XXX: this depends on a signed integer overflow to < 0 */
+                /* C compilers, including gcc, do -NOT- guarantee this. */

(And repeated twice more.)  Wouldn't it be better to write this in a way
that doesn't require this XXX comment?  ISTR that we already had one
area where we had to fight with gcc because it had proved to itself that
something could never be negative, even though it could be due to
overflow.  The GCC authors won. :-(

+/* TODO(gps):

Don't you mean XXX(gps)? :-)

+ * These methods still need implementing (porting over from
stringobject.c):
+ *
+ * IN PROGRESS:
+ * .capitalize(), .title(), .upper(), .lower(), .center(), .zfill(),
+ * .expandtabs(), .ljust(), .rjust(), .swapcase(), .splitlines(), 
+ */
+

Hmmm... Aren't these done now?

+    /* XXX(gps): the docstring above says any iterable int will do but the
+     * bytes_setslice code only accepts something supporting PEP 3118.
+     * Is a list or tuple of 0 <= ints <= 255 also supposed to work? */

Yes, it is, and it's a bug that it currently doesn't.

__________________________________
Tracker <report at bugs.python.org>
<http://bugs.python.org/issue1261>
__________________________________