On Sat, Feb 1, 2020 at 6:33 AM John Skaller2 wrote:
>
> > 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 gene
> 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
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 the result is
pretty self explanatory.
--
___
Interesting it’s not documented well, it definitely should be.
It corresponds to this compiler option:
https://cython.readthedocs.io/en/latest/src/userguide/source_files_and_compilation.html#Cython.Compiler.Options.annotate
When you turn that option on or pass -a or —annotate to the compiler,
c
> 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 [-h] [-V] [-l] [-I INCLUDE_PATH] [-o OUT
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".
Stefan
___
cython-devel mailing list
cython-devel@python.org
https://mail.python.org/mailman/listinfo/cython-devel
> 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
Robert Bradshaw schrieb am 01.02.20 um 00:49:
> Taking a quick glance at an auto-generated file for an empty .pyx, we have
> [...]
> ~300 lines module setup code. Even for trivial modules, we still
> declare and call functions for creating globals, preparing types, etc.
> even if we don't have any
> 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
>
>> 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
On Fri, Jan 31, 2020 at 3:17 PM Greg Ewing wrote:
>
> On 1/02/20 3:17 am, John Skaller2 wrote:
> > When I ran Cython on a two line Python function I got this from wc:
> >
> > 4276 13798 161338 oldtest.c
>
> That seems a bit excessive.
>
> > A lot of the emitted code appeared to be run time
On 1/02/20 3:17 am, John Skaller2 wrote:
When I ran Cython on a two line Python function I got this from wc:
4276 13798 161338 oldtest.c
That seems a bit excessive.
A lot of the emitted code appeared to be run time and compile
time support code which wasn’t actually used.
Not sure
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
13 matches
Mail list logo
