Hi! I have just built Cython but haven’t used it yet.
I want to check I understand what it does whilst examing the sources in the
repository.
Please let me know if I have it wrong!
Given a Python file, Cython parses it, and translates it to the equivalent C,
which can
then be compiled to binary
> On 27 Jan 2020, at 20:23, Greg Ewing wrote:
>
> On 27/01/20 6:56 pm, John Skaller2 wrote:
>> Felix binds C/C++ code with statements like:
>> type PyObject = “PyObject*”;
>> fun add: PyObject * PyObject -> PyObject = “Py_AddLong($1)”;
&g
Ok, quick pass on Cython reference .. pretty good.
Easy to read, good coverage, well written.
Beginning to understand the design.
Interesting thing is the limitations are the best clue. For example:
"The “?” indicates that the value -1 only indicates a possible error.
In this case, Cython gene
What’s a “descr” when its at home?
There are some special words in pxd files like “list” which mean
PyObject that happens to be a list. Is there a list of these somewhere?
—
John Skaller
skal...@internode.on.net
___
cython-devel mailing list
cython
> On 28 Jan 2020, at 21:07, Stefan Behnel wrote:
>
> John Skaller2 schrieb am 28.01.20 um 10:57:
>> What’s a “descr” when its at home?
>
> A descriptor, a special protocol in Python.
>
> https://docs.python.org/3/howto/descriptor.html
Got it, thanks!
>
>
So I just had a thought, I might try something to enhance the bindings.
Not sure if it will work.
My system supports subtyping. For bindings and other nominal types
you can simple define a subtyping coercion.
Now in Python we have subtyping rules like:
dictionary -> mapping -> object
If I impl
>
> For your system, you may need a way of annotating function
> declarations with refcounting rules where they differ from
> the defaults.
Yeah, and i have to encode that to some extent in the type system.
However I have two techs to play with: Felix and C++. Both can,
for example, do subtyping
Ok, I have processed most of the Cython/Include/python/*.pxd files.
Seems these were mechanically derived from docs? Because some
of the bugs in the docs are also in these files. Not sure what you
would like to do so I’ll ask here before doing github issues.
1. Its not all there. I couldn’t find
Just FYI, trying to load my extension I get “ModuleNotFound”.
A test *.py file in the same directory can be imported.
A check on the shared library (dylib on MacOS) shows that the required function
is exported.
Maybe my layout of the module table is wrong, its hard to say given so much
informatio
> On 30 Jan 2020, at 17:20, John Skaller2 wrote:
>
> Just FYI, trying to load my extension I get “ModuleNotFound”.
using Cython I get a different result.
~/felix>cat oldtest.py
def testit():
print("Testit”)
Note the original name was test.py, changed so it cannot be
> On 30 Jan 2020, at 18:44, John Skaller2 wrote:
>
>
>
>> On 30 Jan 2020, at 17:20, John Skaller2 wrote:
>>
>> Just FYI, trying to load my extension I get “ModuleNotFound”.
>
> ~/felix>/usr/local/opt/python/Frameworks/Python.framework/Versions/3.6
> On 30 Jan 2020, at 18:00, Yury V. Zaytsev wrote:
>
> On 30. Jan 2020, at 03:52, John Skaller2 wrote:
>>
>> However the shared library extensions I generate will always be linked
>> against a shared library. My build tech does not permit flat namespaces
>>
OMG. I don’t believe it.
Renaming the binary from *.dylib to *.so fixed it.
Both the Cython and Felix shared libraries can be imported and both run.
Sorry for the noise. Just didn’t occur to me that Python would want *.so
filenames on MacOS.
Until I remembered seeing some in Cython build direct
> On 31 Jan 2020, at 00:22, Stefan Behnel wrote:
>
>> Seems these were mechanically derived from docs?
>
> They were manually copied over time.
Ouch. A lot of work.
>> 2. pyport is plain wrong. It contains conflicting C typedefs.
>
> PRs welcome.
Is this your prefered method (pull request)
> On 30 Jan 2020, at 22:23, Greg Ewing wrote:
>
> On 30/01/20 8:58 pm, John Skaller2 wrote:
> >>>> import oldtest
> > Traceback (most recent call last):
> >File "", line 1, in
> > ModuleNotFoundError: No module named 'oldtest
> The mystery to me is why MacOSX introduced .dylib instead of
> sticking with .so.
There were *.so files and hacks to load them. But the structure od dylib
is different and uses a slightly different loader, dyld. I guess they wanted
to make a distinction. The had some kind of Obj C dynamic plugi
> On 31 Jan 2020, at 16:51, Greg Ewing wrote:
>
> On 31/01/20 9:47 am, John Skaller2 wrote:
>
>>>> 2. pyport is plain wrong. It contains conflicting C typedefs.
>>>
>>> PRs welcome.
>> Is this your prefered method (pull request)?
>
> I&#
ob should be PyObject*
>>>
>>> No, the declaration looks correct to me. The input is an object.
>> I don’t understand. ob isn’t a type, is it? A type is required.
>
> It's a (dummy) parameter name. Cython defaults to "object" when a
> type isn't specified.
>
> Looking at the other decla
> On 1 Feb 2020, at 00:36, Greg Ewing wrote:
>
> On 1/02/20 12:25 am, John Skaller2 wrote:
>> cdef extern from "Python.h":
>> ctypedef int int32_t
>> ctypedef int int64_t
>> ctypedef unsigned int uint32_t
>> ctypedef unsigned in
>
> Yes, there is -- the default type in C is int.
I don’t think that is true in C99 but I’m not sure.
Its definitely not allowed in C++.
I know because I actually moved the motion on the C++ ISO committee
to disallow it :-)
In any case its a bad idea in an interface specification even if it’
When I ran Cython on a two line Python function I got this from wc:
4276 13798 161338 oldtest.c
It took a while to actually find the implementation of the function.
A lot of the emitted code appeared to be run time and compile
time support code which wasn’t actually used.
Eliminating stu
> On 1 Feb 2020, at 09:49, Greg Ewing wrote:
>
> On 1/02/20 3:03 am, John Skaller2 wrote:
>> So this is some kind of hack way
>> of getting something a bit like Haskell type classes,
>> you’re basically saying int32_t and int64_t are of class “Integer”.
>
>
>
>> Is there an option to use an #include for the standard stuff?
>
> There are upsides and downsides to that as well.
Hence an option. But it could be work to implement so I’m just
exploring at the moment.
> The way
> things are, the generated file is self-contained, and can
> be shipped with
> I agree there's some fat that could be trimmed there, but not sure
> it'd be worth the effort.
You’re probably right. Its a problem writing a compiler in a language
wholy unsuited for the job. Even with a more suitable language,
emitting code, in the right order, with just the things actually r
OMG. Python is moving backwards. Some people just have no understanding
of tech. As of 3.8, extensions must not be dynamically linked to libpython.
This doesn’t apply to Windows or MacOS because that’s the only way on those
platforms.
But Debian/Ubuntu was always wrong and now the error is being
> given target. Removing the final 0.5% of code that is "unused in some
> cases" is really not something I would want to invest days into, each time
> we make a change in Cython.
But its not 0.5%. My problem is trying to read the generated code.
A possibility might be an option which puts the bo
> On 1 Feb 2020, at 20:00, Greg Ewing wrote:
>
> On 1/02/20 3:29 pm, John Skaller2 wrote:
>> But the all hell breaks loose for pointers. Your hack only
>> works for rvalues.
>
> Yes, using these it's possible for Cython to accept something
> that will later
> On 2 Feb 2020, at 02:23, Stefan Behnel wrote:
>
> John Skaller2 schrieb am 01.02.20 um 15:32:
>> My problem is trying to read the generated code.
>
> You might be looking for "cython -a".
OK. I see these:
~/felix>../cython/cython.py
usage: cython.py [-
>>
>> My concern is that the C compiler wont reject it, the program
>> will corrupt data or crash:
>>
>> int32_t *x=..; *x = 42;
>> int64_t *x=..; *x = 42;
>>
>> The C compiler will overwrite 4 or 8 bytes. Which one matters.
>
> As stated before, the C compiler will see the correct d
> On 2 Feb 2020, at 03:06, Prakhar Goel wrote:
>
> Isn't it?
> https://cython.readthedocs.io/en/latest/src/tutorial/cython_tutorial.html#primes:
> Jump down to the part where it has "annotate=True" and it describes it
> in some detail.
>
> Also this takes all of thirty-seconds to try out and
30 matches
Mail list logo
