Comments (10)
As context, I started a discussion on python.org about this.
I've sent emails to the maintainer of docopt on PyPI seeing what they think about the name transfer, I'll post here with any updates.
from docopt-ng.
@cmurat I'm actively working on a new reference implementation (https://github.com/keleshev/docopt.ml), once it is done, I (or a volunteer) will update docopt.py to be up-to-date with that.
I have been out of touch with Python development, so I'm not aware what maintenance is required for docopt.py except for type annotations.
As for type annotation, I am interested to hear how to make the return type of docopt type-safe in mypy. I think it is a difficult challenge in Python, considering that the return type depends on the docstring. In OCaml I could achieve it with GADTs. In F# it can be done with type-providers.
from docopt-ng.
@keleshev, I thought I'd try reaching out here as well. What do you think an ideal future for docopt
would look like? What would be your hesitations with a name transfer? I think you may find it interesting that I actually just reverted the "magic" stuff that was added after the fork, as I'm trying to get this back to the pure core that you left.
from docopt-ng.
Hi @NickCrews, the last time I checked, docopt.py was basically perfect and didn't need to change. However, I haven't been working actively with Python for a long while, and I know that Python has been moving forward (type annotations, other features), so I'm open to very small pull requests with clear description.
I will try to go through existing pull requests too.
from docopt-ng.
Is there a reason you prefer not to share the burden with a willing team of maintainers @keleshev ? JazzBand is a reliable and experienced crew. You'll still retain all origin credit and copyright, and even maintainer status I imagine if you still want to be involved.
They've modernized the package a repo a lot and will continue to move it forward as python advances.
from docopt-ng.
@keleshev It is understandable that you may not want to spend time on maintaining docopt. But it still needs maintenance otherwise it will be unusable soon. That is why this fork exists. If you are not willing to do it, consider letting others take it over so that the community can continue to benefit from it.
from docopt-ng.
I think that course sounds like an improvement, but I'm still nervous that it still suffers from the same basic problem that a single person is the gatekeeper for all fixes and modernization. Could we come up with a governance strategy that somehow gives the community the ability to at least fix bugs and keep things modern? I totally agree that I think docopt
is feature complete and should only very minimally change. Only 2 people have responded to my question about this, but it sounds like they agree too.
I'm not aware what maintenance is required for docopt.py except for type annotations.
See the differences between your repo and this fork:
- type annotations
- update packaging to use standard and static
pyproject.toml
instead of setuptools-specific and dynamicsetup.py
- move to github actions from travis for CI
- add test coverage
- move to PDM or a more modern project manager tool from tox, venv, etc
I think it is a difficult challenge in Python, considering that the return type depends on the docstring
My understanding is that this is impossible in python. Best we can do is dict[str, Any]
.
from docopt-ng.
I don't think anything on your list except type annotations is observable by users.
The other things are are important for projects in active development, not for a project that is in maintenance mode.
from docopt-ng.
If dict[str, Any]
is all we can do, then it is of very little benefit. The downside is dropping support for older Python versions—I don't have an intuition for how important that is.
from docopt-ng.
The other things are are important for projects in active development
Yeah that is mostly true, though I might modify
- having test coverage is important even for maintenance mode so people can be confident in this lib
- moving to static metadata helps with dependency/static analysis
Also, if we ever take the time to tweak the implementation to improve error messages, then the modern CI and project management stuff is more relevant. But so far I haven't been motivated to do that work yet either :)
If dict[str, Any] is all we can do, then it is of very little benefit.
True, for actually type safety benefits. But adding types has the benefit of reducing boilerplate for users who want to type check the rest of their code: If docopt doesn't have types, then mypy errors for all users saying "couldn't find annotations". Then users have to configure mypy to ignore these errors, or write their own stubs. I personally find this benefit of reducing user boilerplate more compelling than the actual added type safety.
The downside is dropping support for older Python
Type annotations will work for all python versions 3.7+. Version 3.6 stopped getting security patches almost 2 years ago, so I think it is reasonable to break anyone still on that. Not sure if I am off base here, if others have thoughts then chime in.
from docopt-ng.
Related Issues (20)
- Performance penalty: combinatorial explosion in `transform` HOT 3
- Make PEP561 compatible (allow mypy to actually find type hints) HOT 8
- When docopt and docopt-ng are in the same venv, docopt takes precedence HOT 6
- Add @NickCrews to test.pypi.org HOT 1
- docopt-ng fails to parse usage string that worked with docopt HOT 4
- Question: auto formatting & sorting imports HOT 5
- Is it possible to separate options in subsections? HOT 2
- Failing to put two spaces in description sometimes results in very obscure error. HOT 1
- Integrate docopt-dispatch in this project HOT 5
- Spaces in default value HOT 4
- assert instr.opname.startswith("CALL_") throws on Python 3.11 HOT 5
- TODO: port spellchecker to suggest, rather than fix HOT 1
- DISCUSS: future of docopt-ng HOT 17
- docopt.DocoptLanguageError: unmatched '[' HOT 1
- If there is unused data in the command line, the thrown exception doesn't include the collected and left items HOT 1
- command line parsing is storing some options multiple times HOT 2
- Allow dumping of parse tree, to make it easier to check what docopt will actually parse HOT 1
- Support envvar token HOT 1
- docopt to readthedocs / sphinx docstrings HOT 7
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from docopt-ng.