Thanks for notifying me, and sorry for the late reply. I think it would be awesome if docopt became part of the standard library. However, it's not ready yet. I expect 1.0.0 to be released not earlier than 2014. When it's ready I will definitely write a PEP. According to the schedule the "feature freeze" will occur on Nov 24, 2013 together with 3.4.0 beta 1 release. If "feature freeze" means no new things in standard library, then, neither docopt, nor PEP will be ready by that time. Seems like docopt will need to wait another 2 years. But don't lose harts, docopt 1.0.0 will be much better, the language will be much more predictable and simple, the error messages will be much more clear, it will be more parseable and portable. That's why I think it is worth it to wait. Getopt is now about 33 years old and still widely used; So I want docopt to be ready for the year 2046. Cheers, Vladimir Keleshev 28.09.2013, 11:02, "Chris “Kwpolska” Warrick" :

On Sat, Sep 28, 2013 at 10:10 AM, Steven D'Aprano wrote:

...

 On Sat, Sep 28, 2013 at 07:44:46AM +0300, anatoly techtonik wrote:

...

 This - http://docopt.org/ - should be included with Python 3.4 distribution.  Are you the developer or maintainer of docopt?

He is not.  I CC’d the developer, Vladimir Keleshev.

...

 If so, you'll probably need to write a PEP. Otherwise, you'll need to  ask the maintainer of docopt to write a PEP. Some questions that will  need to be asked:

 - does the maintainer agree to distribute the software under the same  licence as Python?

 - does the maintainer agree to stick to Python's release schedule?

 - is the maintainer happy with keeping the API frozen for the next ten  or fifteen years?

 I see that docopt is now up to version 0.6.1. To me, that indicates that  the API should not be considered stable, it's under version 1. Perhaps  the maintainer disagrees, and would be happy to freeze the API now.

 --  Steven  _______________________________________________  Python-ideas mailing list  Python-ideas@python.org  https://mail.python.org/mailman/listinfo/python-ideas

-- Chris “Kwpolska” Warrick http://kwpolska.tk PGP: 5EAAEA16 stop html mail | always bottom-post | only UTF-8 makes sense

On Sat, Sep 28, 2013 at 12:22 PM, Mark Lawrence wrote:

On 28/09/2013 05:44, anatoly techtonik wrote:

...

This - http://docopt.org/ - should be included with Python 3.4 distribution. -- anatoly t.

Have you had the courtesy to ask the maintainer of this library their opinions prior to placing this?

Courtesy - yes. Time - no. License permits the code to be included in Python distribution. Vladimir is also quite open about it. If docopt name should not be settled to reference to stdlib module, it can be renamed. -- anatoly t.

On 9/28/2013 6:42 AM, Ned Batchelder wrote:

On 9/28/13 12:44 AM, anatoly techtonik wrote:

...

This - http://docopt.org/ - should be included with Python 3.4 distribution.

In addition to the other questions already asked, you haven't answered the fundamental one: Why should docopt be included in the stdlib? It's right there in PyPI where any one can get it. Why is it better in the stdlib than in PyPI?

The stdlib has mostly switched from using optparse to argparse. The next question is what relation docopt has to either?? What is its backend? Anyway, it strikes be as a wrapper module best kept as third party, similar to re and urllib wrappers. -- Terry Jan Reedy

Le Sun, 29 Sep 2013 07:50:35 +0200, Georg Brandl a écrit :

Am 28.09.2013 22:28, schrieb Terry Reedy:

...

On 9/28/2013 6:42 AM, Ned Batchelder wrote:

...

On 9/28/13 12:44 AM, anatoly techtonik wrote:

...

This - http://docopt.org/ - should be included with Python 3.4 distribution.

In addition to the other questions already asked, you haven't answered the fundamental one: Why should docopt be included in the stdlib? It's right there in PyPI where any one can get it. Why is it better in the stdlib than in PyPI?

The stdlib has mostly switched from using optparse to argparse. The next question is what relation docopt has to either?? What is its backend? Anyway, it strikes be as a wrapper module best kept as third party, similar to re and urllib wrappers.

Especially since it's one of the more "magical" argument parsers, which is fine as a library but not something we like to put in the standard library.

Agreed. It's also not the most appealing API IMO. Regards Antoine.

On Mon, Oct 21, 2013 at 7:39 AM, anatoly techtonik wrote:

On Sat, Sep 28, 2013 at 1:42 PM, Ned Batchelder wrote:

...

On 9/28/13 12:44 AM, anatoly techtonik wrote:

This - http://docopt.org/ - should be included with Python 3.4 distribution.

In addition to the other questions already asked, you haven't answered the fundamental one: Why should docopt be included in the stdlib?

Because it is the easiest and most intuitive way to quickly build command line parser with a less amount of writing. It also provides synced help, custom formatting, really short parser definition syntax and subcommands out of the box.

But the main reason that it is a 'fastest way ever to expose script functions to command line user interface'. Writing it is as fast as 10x times on average compared to argparse, optparse and getopt interfaces. 50 minutes on argparse with debug and 5 on docopt. 5 minutes regardless of your experience. For a newbie getting what argparse does may take more that 50 minutes on average, and it is still probably the same 5 minutes for docopt.

...

It's right there in PyPI where any one can get it. Why is it better in the stdlib than in PyPI?

Because you need a Python on your machine. Language with batteries included. Not a C or Java where probably need to download libraries even to work with strings. Setting docopt on every machine where you need to quickly give some variations for execution flow to your one-time command line script is akin to launching the C compiler with appropriate include paths.

Also, the command line interface definition (help on script abilities) in docopt can be easily read by any human without the need to run the script or decipher argparse/optparge function call parameters. -- anatoly t.

On Oct 20, 2013, at 21:39, anatoly techtonik wrote:

Because you need a Python on your machine. Language with batteries included. Not a C or Java where probably need to download libraries even to work with strings.

I take it you've never worked with C or Java? Java has multiple string and related classes that have, if anything, too much functionality for a novice to learn. C comes with an extensive set of string functions that are the inspiration (both positive and negative) for the string classes/modules/etc. of most languages that followed.