Linting Cython

已查看 771 次
跳至第一个未读帖子

Nelson Liu

未读,
2016年7月18日 14:08:332016/7/18
收件人 cython-users
Hi All,
Is there any tool used to lint Cython in the same vein as Python has pep/flake8? It's difficult to have uniform style for Cython code throughout a codebase with many contributors when there isn't an automated tool to do so for you :)

Thanks,
Nelson Liu

Denis Akhiyarov

未读,
2016年7月20日 02:59:442016/7/20
收件人 cython-users
Have you tried pure python mode?

Otherwise the best you get is PyCharm professional edition with Cython support.


PyCharm has 30% discount promotion until tomorrow:

Stefan Behnel

未读,
2016年7月22日 03:09:082016/7/22
收件人 cython...@googlegroups.com
Besides using pure Python mode, this brings back the (ancient) idea of an
"uncython" tool, which would strip any cython-only syntax and leave only
Python code to be analysed by third party tools. It's not entirely the same
thing as a dedicated Cython linter, but it should still work in most cases.
It would strip cdef's, types in function signatures and pure declarations,
and might also turn things like structs into class declarations or so, to
keep as much of the original code as possible.

Has anyone ever looked into that?

Stefan

Michael WS

未读,
2016年7月24日 14:49:012016/7/24
收件人 cython-users、stef...@behnel.de
I am not sure how practical it is to require everyone on a team to use the same  ide.  Also, I need to have pre commits hooks that my team must run.

Stefan Behnel

未读,
2016年7月24日 15:05:512016/7/24
收件人 cython...@googlegroups.com
Michael WS schrieb am 24.07.2016 um 20:39:
> On Friday, July 22, 2016 at 3:09:08 AM UTC-4, Stefan Behnel wrote:
>> Nelson Liu schrieb am 18.07.2016 um 18:44:
>>> Is there any tool used to lint Cython in the same vein as Python has
>>> pep/flake8? It's difficult to have uniform style for Cython code
>>> throughout
>>> a codebase with many contributors when there isn't an automated tool to
>>> do so for you :)
>>
>> Besides using pure Python mode, this brings back the (ancient) idea of an
>> "uncython" tool, which would strip any cython-only syntax and leave only
>> Python code to be analysed by third party tools. It's not entirely the
>> same
>> thing as a dedicated Cython linter, but it should still work in most
>> cases.
>> It would strip cdef's, types in function signatures and pure declarations,
>> and might also turn things like structs into class declarations or so, to
>> keep as much of the original code as possible.
>>
>> Has anyone ever looked into that?
>
> I am not sure how practical it is to require everyone on a team to use the
> same ide. Also, I need to have pre commits hooks that my team must run.

I'm not sure I understand what you mean. Such a tool would be used as a
preprocessor before running other tools, such as linters. It would
obviously require a bidirectional mapping from Cython code to analysable
Python code and back (well, at least the code positions would have to be
accurate), in order to allow for meaningful output of whatever tool you run
after it. But it would not depend on any specific IDE or so.

I'm not saying this would be trivial. :)

Regarding IDEs, I sat together with a couple of PyCharm developers at
EuroPython this week and it looks like we could easily improve the IDE
support in various ways, such as debugging (stepping through Cython code
worked as a POC) and profiling.

We also discussed integrating the Pure Python syntax with PEP484 type
hints, so that regular Python tools could understand them, at least to a
certain extent. There seems to be a way to do that, although with the usual
limitation of not being able to talk to C libraries in pure mode.

Stefan

Denis Akhiyarov

未读,
2016年7月25日 02:06:202016/7/25
收件人 cython...@googlegroups.com
There are also stub files (.pxd) that can be used like "header" files.
--

---
You received this message because you are subscribed to a topic in the Google Groups "cython-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cython-users/PNuSCgReGLk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cython-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Stefan Behnel

未读,
2016年7月25日 03:49:442016/7/25
收件人 cython...@googlegroups.com
Denis Akhiyarov schrieb am 24.07.2016 um 23:49:
> There are also stub files (.pxd) that can be used like "header" files.

"stub files" is a term used in PEP 484, so I'm not sure if you really meant
".pxd" (Cython) files or ".pyi" (PEP 484) files. The idea is to use the
latter to describe Cython's own type system, at least as good as possible
within the bounds that PEP484 sets. That would make the type declarations
of Cython's pure Python mode compatible with the PEP 484.

A proof of feasibility is still pending, though. It seems doable in
general, but it remains unclear how far we will get with this and how
usable the result will be.

Stefan

vincent...@googlemail.com

未读,
2018年11月30日 09:12:082018/11/30
收件人 cython-users
Am Freitag, 22. Juli 2016 09:09:08 UTC+2 schrieb Stefan Behnel:
Besides using pure Python mode, this brings back the (ancient) idea of an
"uncython" tool, which would strip any cython-only syntax and leave only
Python code to be analysed by third party tools. It's not entirely the same
thing as a dedicated Cython linter, but it should still work in most cases.
It would strip cdef's, types in function signatures and pure declarations,
and might also turn things like structs into class declarations or so, to
keep as much of the original code as possible.


This is exactly the tool I'm looking for. Has there been any progress on this idea?

We have a set of Cython modules, partly as a wrapper for underlying C++ libraries, partly with functionality implemented in Python/Cython.
We would like to generate Python-only code from these Cython modules to be able to use code completion etc using any IDE (not just PyCharm Professional).

It would already be a great benefit to have function/class signatures and docstrings in Python-only syntax.

My first attempt was to use the cython Compiler to access the Cython AST manually to extract signatures and docstrings and generate corresponding stub modules. This is probably not the most elegant approach, though.

Any suggestions would be much appreciated,

best regards
Detlef Maurel
已删除帖子

Marko Loparic

未读,
2018年11月30日 10:02:162018/11/30
收件人 cython...@googlegroups.com
Hi,

In our development team, we are happy using pyorcy.
https://github.com/markolopa/pyorcy

It is not exactly what you want, since the Cython lines need to be in comments.

But we get pylint/flake8 and can easily switch between Cython and pure
Python, without having to use the Cython pure python syntax.

Note: Not everyone likes the pyximport mechanism and the decorator (I
plan to remove them). You don't need them and can use extract_cython
in your setup.py.

Greetings,
Marko
On Fri, Nov 30, 2018 at 3:12 PM vincentmalloy23 via cython-users
<cython...@googlegroups.com> wrote:
>
> Am Freitag, 22. Juli 2016 09:09:08 UTC+2 schrieb Stefan Behnel:
>>
>> Besides using pure Python mode, this brings back the (ancient) idea of an
>> "uncython" tool, which would strip any cython-only syntax and leave only
>> Python code to be analysed by third party tools. It's not entirely the same
>> thing as a dedicated Cython linter, but it should still work in most cases.
>> It would strip cdef's, types in function signatures and pure declarations,
>> and might also turn things like structs into class declarations or so, to
>> keep as much of the original code as possible.
>>
>
> This is exactly the tool I'm looking for. Has there been any progress on this idea?
>
> We have a set of Cython modules, partly as a wrapper for underlying C++ libraries, partly with functionality implemented in Python/Cython.
> We would like to generate Python-only code from these Cython modules to be able to use code completion etc using any IDE (not just PyCharm Professional).
>
> It would already be a great benefit to have function/class signatures and docstrings in Python-only syntax.
>
> My first attempt was to use the cython Compiler to access the Cython AST manually to extract signatures and docstrings and generate corresponding stub modules. This is probably not the most elegant approach, though.
>
> Any suggestions would be much appreciated,
>
> best regards
> Detlef Maurel
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups "cython-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to cython-users...@googlegroups.com.

Stefan Behnel

未读,
2018年11月30日 10:59:212018/11/30
收件人 cython...@googlegroups.com
vincentmalloy23 via cython-users schrieb am 30.11.18 um 15:10:
> Am Freitag, 22. Juli 2016 09:09:08 UTC+2 schrieb Stefan Behnel:
>>
>> Besides using pure Python mode, this brings back the (ancient) idea of an
>> "uncython" tool, which would strip any cython-only syntax and leave only
>> Python code to be analysed by third party tools. It's not entirely the
>> same
>> thing as a dedicated Cython linter, but it should still work in most
>> cases.
>> It would strip cdef's, types in function signatures and pure declarations,
>> and might also turn things like structs into class declarations or so, to
>> keep as much of the original code as possible.
>>
>>
> This is exactly the tool I'm looking for. Has there been any progress on
> this idea?
>
> We have a set of Cython modules, partly as a wrapper for underlying C++
> libraries, partly with functionality implemented in Python/Cython.
> We would like to generate Python-only code from these Cython modules to be
> able to use code completion etc using any IDE (not just PyCharm
> Professional).
>
> It would already be a great benefit to have function/class signatures and
> docstrings in Python-only syntax.
>
> My first attempt was to use the cython Compiler to access the Cython AST
> manually to extract signatures and docstrings and generate corresponding
> stub modules. This is probably not the most elegant approach, though.
>
> Any suggestions would be much appreciated,

Apart from preprocessing, which was already proposed, have you tried using
Python PEP 484/526 typing syntax? Might get you close to what you want.
Problems you'll face are cimports and anything else that's strictly not
Python, but if your editor's / IDE's lexer is somewhat resilient, you might
get away with it. Also, we are interested in user reports (and especially
PRs) that help us improve the typing in Python syntax. It's a bit more
verbose and not 100% feature complete (I never tried it with anything
C++ish), but it seems worth a try.

Stefan

Denis Akhiyarov

未读,
2018年11月30日 11:04:432018/11/30
收件人 cython...@googlegroups.com
Is it possible to lint the generated C-code instead?

Michael W Schatzow

未读,
2018年11月30日 11:36:232018/11/30
收件人 cython...@googlegroups.com
the c generated code you don't want to lint. I think the big thing for me is having some linter for c++ syntax in cython

You received this message because you are subscribed to a topic in the Google Groups "cython-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/cython-users/PNuSCgReGLk/unsubscribe.
To unsubscribe from this group and all its topics, send an email to cython-users...@googlegroups.com.

Vincent Malloy

未读,
2018年12月13日 17:17:272018/12/13
收件人 cython...@googlegroups.com
Am 30.11.18 um 16:59 schrieb Stefan Behnel:
>> This is exactly the tool I'm looking for. Has there been any progress on
>> this idea?
>>
>> We have a set of Cython modules, partly as a wrapper for underlying C++
>> libraries, partly with functionality implemented in Python/Cython.
>> We would like to generate Python-only code from these Cython modules to be
>> able to use code completion etc using any IDE (not just PyCharm
>> Professional).
>>
>> It would already be a great benefit to have function/class signatures and
>> docstrings in Python-only syntax.
>>
>> My first attempt was to use the cython Compiler to access the Cython AST
>> manually to extract signatures and docstrings and generate corresponding
>> stub modules. This is probably not the most elegant approach, though.
>>
>> Any suggestions would be much appreciated,
>
> Apart from preprocessing, which was already proposed, have you tried using
> Python PEP 484/526 typing syntax? Might get you close to what you want.
> Problems you'll face are cimports and anything else that's strictly not
> Python, but if your editor's / IDE's lexer is somewhat resilient, you might
> get away with it. Also, we are interested in user reports (and especially
> PRs) that help us improve the typing in Python syntax. It's a bit more
> verbose and not 100% feature complete (I never tried it with anything
> C++ish), but it seems worth a try.
>
> Stefan
>

thank you very much for your suggestions. I will need some time to try
these out. I will let you know about the status / result.

best regards
Detlef Maurel
回复全部
回复作者
转发
0 个新帖子