Message91556
| Author |
mark.dickinson |
| Recipients |
alexandre.vassalotti, benjamin.peterson, mark.dickinson |
| Date |
2009年08月14日.16:12:18 |
| SpamBayes Score |
6.944364e-10 |
| Marked as misclassified |
No |
| Message-id |
<1250266340.49.0.283287503534.issue6687@psf.upfronthosting.co.za> |
| In-reply-to |
| Content |
+1 from me too; I agree the current API of PyBytes_FromObject is ugly.
Is there still a need for a separate C function for creating a zero-
initialized bytes object from a Py_ssize_t or a Python integer? It's a
fairly simple operation (PyBytes_FromStringAndSize + memset), so perhaps
it doesn't need its own public function.
I'm not sure about the extra PyUnicode_Check: this seems to go against
Python's philosophy of duck-typing. After all, the empty string *is* an
iterable all of whose elements are integers. And this check doesn't cover
other, similar, cases: for example, list('') will still be converted by
PyBytes_FromObject, while list('123') won't. What's the benefit?
If this check is going to stay, there should probably also be a unit test
for this behaviour.
Apart from the reservation about the PyUnicode_Check, the patch looks good
to me. All tests pass on my machine (OS X 10.5) with this patch applied. |
|
History
|
|---|
| Date |
User |
Action |
Args |
| 2009年08月14日 16:12:20 | mark.dickinson | set | recipients:
+ mark.dickinson, alexandre.vassalotti, benjamin.peterson |
| 2009年08月14日 16:12:20 | mark.dickinson | set | messageid: <1250266340.49.0.283287503534.issue6687@psf.upfronthosting.co.za> |
| 2009年08月14日 16:12:19 | mark.dickinson | link | issue6687 messages |
| 2009年08月14日 16:12:18 | mark.dickinson | create |
|