Hi, instead of overriding an existing definition of "PyIndex_Check" like this: """ +#if PY_VERSION_HEX < 0x02050000 + /* NumPy headers define PyIndex_Check incorrectly */ + #undef PyIndex_Check + #define PyIndex_Check(o) (PyNumber_Check(o) && !PyFloat_Check(o) && !PyComplex_Check(o)) +#endif """ which may or may not have come from NumPy, shouldn't we be using our own definition of a "__Pyx_PyIndex_Check" in our code instead? Stefan
Hi, I just sent this to python-dev. Please comment over there if you have an opinion on this. http://thread.gmane.org/gmane.comp.python.devel/135764 Stefan -------- Original-Message -------- Hi, I suspect that this will be put into a proper PEP at some point, but I'd like to bring this up for discussion first. This came out of issues 13429 and 16392. http://bugs.python.org/issue13429 http://bugs.python.org/issue16392 Stefan The problem =========== Python modules and extension modules are not being set up in the same way. For Python modules, the module is created and set up first, then the module code is being executed. For extensions, i.e. shared libraries, the module init function is executed straight away and does both the creation and initialisation. This means that it knows neither the __file__ it is being(Continue reading)
mark florisson, 05.11.2012 12:02: > On 4 November 2012 22:32, Olivier Parcollet wrote: >> I would like to write some automatic C++/python conversionsfor the >> classes of my project >> in addition to std::vector and others std:: objects. >> >> Conversions for std:: objects are written in >> Cython/Utility/CppConvert.pyx, i.e. an internal cython file. >> >> The question is then simply to load another CppConvert.pyx file that >> would be project dependent. >> Is there already a way to do it ? >> or a plan to do provide such user defined conversions ? >> >> I made a simple patch to load also another CppConvert.pyx from the >> current directory, >> which works for my code, but I would welcome a more general solution... >> > > Great. Ideally, Cython would be plugable, allowing one to use a > documented API and to insert new visitors at certain points in the > pipeline, allowing custom transformations and utilities I wouldn't call that "ideal". In case we want to support this kind of extensions, it should happen at the source code level, not hook into the compiler pipeline as part of the build process. IMHO, the right way to provide custom type conversions is by declaring them, e.g. as part of a C++ class declaration.(Continue reading)
Hello, I would like to write some automatic C++/python conversionsfor the classes of my project in addition to std::vector and others std:: objects. Conversions for std:: objects are written in Cython/Utility/CppConvert.pyx, i.e. an internal cython file. The question is then simply to load another CppConvert.pyx file that would be project dependent. Is there already a way to do it ? or a plan to do provide such user defined conversions ? I made a simple patch to load also another CppConvert.pyx from the current directory, which works for my code, but I would welcome a more general solution... Best, Olivier
Hi, I added a CHANGES.rst file now that collects the changes for each release. Please add to it as you see fit. The content is reversed engineered from the Wiki pages. It would be good if others could give it a glance - I'm sure there are things to improve. Stefan
Hi, just wanted to mention that I met many happy Cython users at the conference. Some of them came to me after my talks to say "thanks!" for this great tool and enthusiastically told me how much work it saved them. I'm warmly forwarding this to all of you who made Cython what it is today. Stefan
Hello list, Recently I've worked on translating cython documents into Japanese, and just finished for quickstart/tutorial. It was mainly for me and my colleagues, but I think it would be useful for all cython users speaking Japanese, so I'd like to publish it via my company's unofficial site: http://omake.accense.com/static/doc-ja/cython/ I suppose that docs are permissible for translation, redistribution and publish, but if you authors of original docs have troubles, please let me know... Thanks for great library (and, of course, documents)! -- -- Yasushi Masuda http://ymasuda.jp/ whosaysni at twitter/gmail
After successfully porting mpi4py to PyPy 1.9, I want to share a few
issues I've encountered. The most serious onesare on PyPy's side, but
Cython do require a cuple of very minor fixes.
1) Cython uses _PyLong_AsByteArray() to convert integers of unknown
sizeof larger than long long. I had to cinclude the following code to
get the C sources compile:
static int
_PyLong_AsByteArray(PyLongObject* v, unsigned char* bytes, size_t n,
int little_endian, int is_signed)
{
PyErr_SetString(PyExc_RuntimeError,
"PyPy: _PyLong_AsByteArray() not available");
return -1;
}
2) PyPy's implementation of PyBuffer_FillInfo() has a bug, it ignores
the "readonly" parameter instead of generating an error if readonly=1
and PyBUF_WRITABLE is on. I had to to cinclude the following code to
monkeypatch it:
static int
PyBuffer_FillInfo_PyPy(Py_buffer *view, PyObject *obj, void *buf,
Py_ssize_t len, int readonly, int flags)
{
if (view == NULL) return 0;
if (((flags & PyBUF_WRITABLE) == PyBUF_WRITABLE) &&
(readonly == 1)) {
PyErr_SetString(PyExc_BufferError,
(Continue reading)
RSS Feed37 | |
|---|---|
129 | |
87 | |
75 | |
31 | |
30 | |
33 | |
45 | |
56 | |
154 | |
128 | |
124 | |
279 | |
235 | |
158 | |
146 | |
125 | |
20 | |
43 | |
196 | |
116 | |
184 | |
245 | |
72 | |
220 | |
294 | |
217 | |
105 | |
200 | |
237 | |
377 | |
62 | |
124 | |
232 | |
288 | |
88 | |
135 | |
230 | |
222 | |
181 | |
111 | |
253 | |
245 | |
607 | |
360 | |
219 | |
206 | |
357 | |
639 | |
527 | |
678 | |
406 | |
181 | |
274 | |
291 | |
418 | |
256 | |
320 | |
215 | |
284 | |
705 | |
398 | |
223 | |
65 | |
133 | |
137 | |
82 | |
49 | |
151 | |
32 |
