openapi-python-client
Lark
openapi-python-client | Lark | |
---|---|---|
6 | 35 | |
1,075 | 4,497 | |
3.9% | 1.6% | |
9.0 | 7.5 | |
8 days ago | 21 days ago | |
Python | Python | |
MIT License | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
openapi-python-client
-
GraphQL is for Backend Engineers
On the backend, developers either need to manually document the entire API or rely on auto-generation tools that don’t fully meet their needs. Consumers face the same choice, write code by hand or workaround the bugs in their SDK generator (stated, lovingly, as the maintainer of an OpenAPI client generator). On top of this, these solutions result in inconsistent understandings of the API. Reproducing errors becomes time-consuming and frustrating, which feels like a battle instead of a collaboration. What we need is a shared language to describe how the API works—one that doesn’t add unnecessary layers of abstraction or manual work.
-
Microsoft Kiota: CLI for generating an API client to call OpenAPI-described API
Has anyone tried Kiota, specifically the Python support? How does it compare to https://github.com/openapi-generators/openapi-python-client ?
-
Python toolkits
I think we use these - https://github.com/openapi-generators/openapi-python-client
-
YAML: It's Time to Move On
Thanks for the link, but not necessarily.
How WSDL and the code generation around it worked, was that you'd have a specification of the web API (much like OpenAPI attempts to do), which you could feed into any number of code generators, to get output code which has no coupling to the actual generator at runtime, whereas Pyotr is geared more towards validation and goes into the opposite direction: https://pyotr.readthedocs.io/en/latest/client/
The best analogy that i can think of is how you can also do schema first application development - you do your SQL migrations (ideally in an automated way as well) and then just run a command locally to generate all of the data access classes and/or models for your database tables within your application. That way, you save your time for 80% of the boring and repetitive stuff while minimizing the risks of human error and inconsistencies, while nothing preventing you from altering the generated code if you have specific needs (outside of needing to make it non overrideable, for example, a child class of a generated class). Of course, there's no reason why this can't be applied to server code either - write the spec first and generate stubs for endpoints that you'll just fill out.
Similarly there shouldn't be a need for a special client to generate stubs for OpenAPI, the closest that Python in particular has for now is this https://github.com/openapi-generators/openapi-python-client
However, for some reason, model driven development never really took off, outside of niche frameworks, like JHipster: https://www.jhipster.tech/
Furthermore, for whatever reason formal specs for REST APIs also never really got popular and aren't regarded as the standard, which to me seems silly: every bit of client code that you write will need a specific version to work against, which should be formalized.
-
Replacing FastAPI with Rust: Part 2 - Research
Tallying up the results, we get 7/8 "MUST" requirements met. I think that Paperclip + actix-web seems like the most promising candidate. I'm really not opposed to writing the OpenAPI v3 construction myself as I've worked with the structure a fair bit in my openapi-python-client project (shameless plug).
-
Replacing FastAPI with Rust: Part 1 - Intro
Automatic documentation via OpenAPI, which lets you do things like generate Python code that knows how to talk to your API.
Lark
-
Show HN: I wrote a RDBMS (SQLite clone) from scratch in pure Python
Lark supports, and recommends, writing and storing the grammar in a .lark file. We have syntax highlighting support in all major IDEs, and even in github itself. For example, here is Lark's built-in grammar for Python: https://github.com/lark-parser/lark/blob/master/lark/grammar...
You can also test grammars "live" in our online IDE: https://www.lark-parser.org/ide/
The rationale is that it's more terse and has less visual clutter than a DSL over Python, which makes it easier to read and write.
-
Oops, I wrote yet another SQLAlchemy alternative (looking for contributors!)
First, let me introduce myself. My name is Erez. You may know some of the Python libraries I wrote in the past: Lark, Preql and Data-diff.
-
Hey guys, have any of you tried creating your own language using Python? I'm interested in giving it a shot and was wondering if anyone has any tips or resources to recommend. Thanks in advance!
It's not super maintained but you might enjoy building something with ppci, Pure Python Compiler Infrastructure. It has some front-ends and some back-ends. There's also PeachPy for an assembler. People like using Lark for parsing, I hear.
-
Is it possible to propagate higher level constructs (+, *) to the generated parse tree in an LR-style parser?
lark, a parsing library where I am somewhat involved has a really nice solution to this: Rules starting with _ are inlined in a post processing step.
-
can you create your own program language in python, if yes how?
Lark is a good library to assist with this.
- Lark a Python lexer/parser library
-
Create your own scripting language in Python with Sly
If I may ask, did you consider Lark, and if so, why wasn't it fit for your purposes?
- Creating a language with Python.
-
Not Your Grandfather’s Perl
A grammar provides the high level constructs you need to define the "shape" of your data, and it largely takes care of the rest. Grammar libraries exist in other language (eg. lark or Parsimonius in Python) and they weren't created just to make XML parsing easier.
-
Earley Parsing Explained
I made a solid attempt at an Earley parser framework of my own, but apparently to get the most reliable performance from Earley parsing you need to implement Joop Leo's improvement for right-recursive grammars, which nobody has been able to adequately explain to me. I've read Kegler's open letter to Vaillant, I've tried to read other implementations, I've even tried to beat my head against the original academic paper, but I don't have the background knowledge to make sense of it all.
What are some alternatives?
sqlx - 🧰 The Rust SQL Toolkit. An async, pure Rust SQL crate featuring compile-time checked queries without a DSL. Supports PostgreSQL, MySQL, and SQLite.
pyparsing - Python library for creating PEG parsers [Moved to: https://github.com/pyparsing/pyparsing]
starlark - Starlark Language
PLY - Python Lex-Yacc
paperclip - WIP OpenAPI tooling for Rust. [Moved to: https://github.com/paperclip-rs/paperclip]
pydantic - Data validation using Python type hints
okapi - OpenAPI (AKA Swagger) document generation for Rust projects
sqlparse - A non-validating SQL parser module for Python
warp - A super-easy, composable, web server framework for warp speeds.
Atoma - Atom, RSS and JSON feed parser for Python 3
yaml-reference-parser
Construct - Construct: Declarative data structures for python that allow symmetric parsing and building