On Thu, 2010-10-21 12:04, Tim Waugh wrote:
> But we had problems with the fact, that pysmbc doesn't work
with Python
> 3.x versions, which we wanted to use for our future releases. Therefore
> I've ported pysmbc to support both Python 2.x and Python 3.x versions.
Thank you very much! I have some questions about the patch:
+#if PY_MAJOR_VERSION>= 3
+#define PyString_FromString PyUnicode_FromString
+#define PyString_Check PyUnicode_Check
+#define PyString_GetSize PyUnicode_GetSize
+#define PyInt_FromLong PyLong_FromLong
+#define PyInt_Check PyLong_Check
+#define PyInt_AsLong PyLong_AsLong
+#endif
Does it make sense to just use Unicode and Long types throughout, rather
than it being different depending on which Python version is used? Then
things like this would not need ifdefs either:
+ #if PY_MAJOR_VERSION>= 3
+ wchar_t* w_name;
+ Py_ssize_t size = PyUnicode_AsWideChar((PyUnicodeObject*)value,
w_name, PyUnicode_GetSize(value));
+ wcstombs(name, w_name, size);
+ #else
+ name = strdup (PyString_AsString (value));
+ #endif
and could just be written in terms of wcstombs() and not strdup().
To tell the
truth, for whatever reason I didn't think about solving the
problem like this, but of course, it would make things much more clear.
I'll look over it and send you a new patch file later today.
Similarly, with the type object declarations,
PyVarObject_HEAD_INIT()
seems to be available in at least Python 2.6 -- does it make sense to
switch to using that unconditionally?
Well, it is in fact available since Python
2.6.
Python 2.5.x doesn't have PyVarObject_HEAD_INIT().
And as long as that many stable systems use Python 2.5 releases, I'd
prefer it to keep them supported, even if this causes type object
definitons to be much more complicated.
Sincerely,
Patrick