docutils-develop — For developer discussions of the implementation.

[Docutils-develop] [docutils:bugs] Re: #444 Table column width rounding can result in uneven column widths

[Günter M. <mi...@us...>]

> that's not a problem.  The bigger issue, however, is that Arch Linux
> appears to be holding back the docutils package due to some issue
> between docutils and recommonmark

Sphinx introduced an upper bound on the Docutils version as a precaution.
If you want to experiment, you may install a repository snapshot
https://docutils.sourceforge.io/#snapshots

It should work with a not too old Sphinx but may need customization of the
CSS style sheets due to recent changes in HTML5 writer.


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Sun Feb 20, 2022 05:55 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

I have pushed the changes from the review and Publisher.get_components into https://github.com/AA-Turner/docutils/pull/8 

A


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sun Feb 20, 2022 05:53 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Alex F. <afo...@us...>]

The only information I have found so far is

https://github.com/archlinux/svntogit-community/commit/efcd10954b3fe906dd7395e6b7fbdc4f5c7b1a69

which references

https://github.com/sphinx-doc/sphinx/issues/9049

I don't know if there is an Arch issue anywhere that references this.


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Sun Feb 20, 2022 12:54 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

Replying to comments from the review file here:

> * Use single quotes for strings (""" for docstrings) (↗policies.txt).
> * Avoid line length > 79 chars.

Yep, will fix

> Missing the "usage" [argument].

Added back, I removed it as it overrides the more helpful message that argparse provides by default but yes there is a remote possibility someone might be using it

> Not needed.  Note the "Filenames will be tilde-expanded later." in the docstring.

I moved the tilde expansion to the class constructor for a minor performance boost.  What I forgot to do was remove the docstring comment.

> Changed behaviour: Users may set ``$DOCUTILSCONFIG=~/.config/docutils.conf``.

I don't think it is, as the "DOCUTILSCONFIG" in environment path includes tilde expansion. The fast path is only when "DOCUTILSCONFIG" does not exist (likely the majority of cases).

> Place at end of file. 

Sure

> We have 3 settings sources: components, config files, command line: * Are settings after updating from config files still "default" settings?

You could argue yes, the settings are the default for the particular environment. Happy to take better suggestions, though.

> I propose a more versatile variant that allows for "settings_overrides" and customization of the config file names.

I see the idea, but I would very strongly advise against -- this is meant to be a simple convinience function. If the more complex functionality is needed later, we can always either add it to the same function, or add a new one. 

> I propose a more general helper function ... Publisher.get_components()

This looks good. I would document it as a private / provisional, method, but I think this could be used now.

A


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Tue Feb 08, 2022 05:15 PM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Adam T. <aa-...@us...>]

> Arch Linux appears to be holding back the docutils package due to some issue between docutils and recommonmark

Do you have a link to a tracker issue for Arch at all? Equally, would it be of any use to have a statement from a Docutils maintainer to help with this?

A


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Sun Feb 20, 2022 12:34 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Alex F. <afo...@us...>]

Thanks for the fix!  All I need is that there is a way to specify things in the rst so that both the HTML and the LaTeX output look OK, so if that means specifying :widths: grid or explicit widths, then that's not a problem.  The  bigger issue, however, is that Arch Linux appears to be holding back the docutils package due to some issue between docutils and recommonmark, which is particularly annoying as recommonmark seems to be deprecated.  But that's beyond the scope of this issue.


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Sat Feb 19, 2022 11:42 PM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Günter M. <mi...@us...>]

- **status**: open --> open-fixed
- **Comment**:

Fixed in [r9009].
The Docutils LaTeX writer already uses 3 digit precision and fixed the "ignored width" bug with the new algorithm for table column widths in release 0.18 (cf. [bugs:#422]). Sphinx uses a LaTeX writer fork so using Docutils >= 0.18 will not fix Sphinx behaviour "automagically".

Thank you for your report.



---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open-fixed
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Fri Feb 11, 2022 09:25 PM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #189 Remove 'prest'

[Günter M. <mi...@us...>]

- **status**: pending-remind --> closed



---

** [patches:#189] Remove 'prest'**

**Status:** closed
**Group:** None
**Created:** Thu Jan 06, 2022 02:23 PM UTC by Adam  Turner
**Last Updated:** Wed Feb 16, 2022 03:38 AM UTC
**Owner:** nobody


xref sourceforge.net/p/docutils/mailman/message/36748625 -- an earlier attempt.

It has now been 11 years (08/12/2010), and no changes. The code will remain in the souce control history should anyone want to revive it.

The first commit removes all the files under /prest and the second removes a final reference in the docs.

This code was quite confusing to me when I was first looking throuh the Docutils source tree - I hestitated to contribute for a while as I thought I might need to know Perl or need to translate any contributions. 

As a current contributor, when searching through the full codebase, there are spurious results from prest that are annoying -- not insurmountable, but a common annoyance, and I think dropping this would solve both issues of clarity (Docutils is purely a Python project) and developer experience.

A

https://github.com/AA-Turner/docutils/pull/5 // https://github.com/AA-Turner/docutils/pull/5.patch


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Docutils-develop] Drop docutils==0.15.1.post1

[Guenter M. <mi...@us...>]

On 2022-02-11, Alex Xela wrote:

> Hey folks,
> Could some one drop docutils==0.15.1.post1 , please.

I recommend changing the dependency descriptor in whatever wants to install
version 0.15.1:

The latest bugfix release for the 0.15 series is 0.15.2.

The latest stable release is Docutils 0.18.

> Collecting docutils==0.15.1.post1

>   Using cached docutils-0.15.1-post1.tar.gz (1.7 MB)

>   Preparing metadata (setup.py) ... error

>   *error*: *subprocess-exited-with-error*


>   × python setup.py egg_info did not run successfully.
>   │ exit code: *1*
>   ╰─> [4 lines of output]
>       Error: The "distutils" standard module, which is required for the
>       installation of Docutils, could not be found.  You may need to
>       install a package called "python-devel" (or similar) on your
>       system using your package manager.
>       [end of output]

Do you have the "distutils" module installed in the system that prints this
error?

...

Günter

[Docutils-develop] [docutils:patches] Re: #187 Rename .txt files to .rst

[engelbert g. <gr...@us...>]

thanks for the reminder

we still have the two opinions (developers and readers)
and I don't have a clue :-)


---

** [patches:#187] Rename .txt files to .rst**

**Status:** pending-remind
**Group:** None
**Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam  Turner
**Last Updated:** Wed Feb 16, 2022 03:41 AM UTC
**Owner:** David Goodger


This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass.

The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion.

Docutils itself of course does not care which file extension is used. 

I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code)

A

Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] #189 Remove 'prest'

[Adam T. <aa-...@us...>]

This can now be closed -- thanks Günter!
A


---

** [patches:#189] Remove 'prest'**

**Status:** pending-remind
**Group:** None
**Created:** Thu Jan 06, 2022 02:23 PM UTC by Adam  Turner
**Last Updated:** Fri Jan 28, 2022 06:12 PM UTC
**Owner:** nobody


xref sourceforge.net/p/docutils/mailman/message/36748625 -- an earlier attempt.

It has now been 11 years (08/12/2010), and no changes. The code will remain in the souce control history should anyone want to revive it.

The first commit removes all the files under /prest and the second removes a final reference in the docs.

This code was quite confusing to me when I was first looking throuh the Docutils source tree - I hestitated to contribute for a while as I thought I might need to know Perl or need to translate any contributions. 

As a current contributor, when searching through the full codebase, there are spurious results from prest that are annoying -- not insurmountable, but a common annoyance, and I think dropping this would solve both issues of clarity (Docutils is purely a Python project) and developer experience.

A

https://github.com/AA-Turner/docutils/pull/5 // https://github.com/AA-Turner/docutils/pull/5.patch


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:patches] Re: #187 Rename .txt files to .rst

[Adam T. <aa-...@us...>]

> :-) yes nag in early February

We're getting dangerously close to mid-late February! Sorry for my brief absence -- deadlines and real life, sadly. Hence this post with said nag ;-)

A


---

** [patches:#187] Rename .txt files to .rst**

**Status:** pending-remind
**Group:** None
**Created:** Wed Jan 05, 2022 05:51 PM UTC by Adam  Turner
**Last Updated:** Fri Jan 07, 2022 10:39 AM UTC
**Owner:** David Goodger


This change is in two parts -- the first commit does the rename and the second goes through and updates references to .txt files. All tests pass.

The benefit of this change is primarily for people -- on user interfaces with syntax highlighting (e.g. IntelliJ / VSCode / Notepad++ editors, code mirrors, etc), the text is presented natively as reStructuredText, and editor features can assist with e.g. autocompletion.

Docutils itself of course does not care which file extension is used. 

I have not renamed any of the include files or template files in `docutils.parsers` or `docutils.writers`, as they form part of the public API and would need a deprecation cycle (or aliasing in the parsing code)

A

Please see https://github.com/AA-Turner/docutils/pull/3 and https://github.com/AA-Turner/docutils/pull/3.patch for the commits and patch.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/patches/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/patches/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:feature-requests] Re: #89 Public API, versioning, and deprecation

[Adam T. <aa-...@us...>]

Sorry for the (long) delay. I've posted my redrafted suggestion at https://github.com/AA-Turner/docutils/pull/14

In my personal opinion (informed by (limited) experience as a PEP editor, but not with that hat on) I don't think we need the formality of "Docutils Enhancement Proposals". That is useful for a project with a large and diffuse team where a single design document can be used as a rallyign point and reference. Docutils currently has 3 active contributors to the code from what I can tell (you, me, and Engelbert), only two of whom are "project developers".

I think the level of discussion we have on issues is reasonable to reach a good conclusion, and the work needed to write a "DEP" might just be better spent on the issue tracker.

A


---

** [feature-requests:#89] Public API, versioning, and deprecation**

**Status:** open
**Group:** Default
**Created:** Sun Jan 16, 2022 01:39 AM UTC by Adam  Turner
**Last Updated:** Sat Jan 29, 2022 12:07 PM UTC
**Owner:** nobody


As requested by @milde in https://sourceforge.net/p/docutils/bugs/441/#7043/cdb8/8742/6e7f I'm opening this issue to allow for discussion on Docutils' public API, versioning policy, and deprecation.

This also relates to FR 87 on type annotations. 

From Günter, 

> The idea is to reconcile the reality (Docutils is used as if it were mature) and the version number (<1) once the API sufficiently defined a deprecation policy is agreed.

The only text I can find on library versioning is at https://docutils.sourceforge.io/docs/dev/policies.html#version-identification, excerpt below:

> **Major releases** (x.0, e.g. 1.0) will be rare, and will
represent major changes in API, functionality, or commitment.  The
major number will be bumped to 1 when the project is
feature-complete, and may be incremented later if there is a major
change in the design or API.  When Docutils reaches version 1.0,
the major APIs will be considered frozen.
For details, see the `backwards compatibility policy`_.

> Releases that change the minor number (x.y, e.g. 0.5) will be
**feature releases**; new features from the `Docutils core`_ will
be included.

> Releases that change the micro number (x.y.z, e.g. 0.4.1) will be
**bug-fix releases**.  No new features will be introduced in these
releases; only bug fixes will be included.

The proposed backwards compatability policy reads:

> Docutils' backwards compatibility policy follows the rules for Python in
PEP 387. ... The scope of the public API is laid out at the start of the backwards
  compatibility rules

I propose two modifications to the policies, which will make future changes to Docutils easier to review and reason about, for project members as well as outside contributors. 

Firstly, I propose adopting a formal versioning "system" such as Sematic Versioning ([SemVer](https://semver.org/)) or Calendar Versioning ([CalVer](https://calver.org/)). 

Semantic versioning is nearly identical to the current versioning policy, and has the benefit of being a known quantity, reducing misunderstandings. A potential phrasing would be:

**"Docutils follows SemVer. All changes must also follow the backwards compatability policy."**

What this does change is that the API is never considered complete, as in the original phrasing. Docutils [isn't slated for inclusion](https://www.python.org/dev/peps/pep-0258/#rejection-notice) in the standard library any more, and there will always be potential improvements and changes -- new parsers, new node types, changes in the HTML specification, et cetera. 

The 1.0 release then does not need to be a "big deal", and future breaking changes can go to 2.0, 3.0, etc -- setuptools is now on `60.5.0`!

Semantic versioning does have some drawbacks (https://snarky.ca/why-i-dont-like-semver/), so projects like pip have adopted calendar based versioning -- the major version is the year (22), and the minor version is either the current month or an increasing number.  This relies on strong documentation and changelogs, so that when users upgrade it is obvious what changed (the idea being that every change breaks someone, so there is no contract that version numbers within a certain range mean no breakage). Luckily, Docutils has a good culture around changelogs and histories etc, so this would be easy to adopt.

______


I also suggest enumerating all modules, classes, and functions that form the public API. The current backwards compatability policy references PEP 387, which is specifically for the Python project itself. Checking through the documentation on every change to identify if a name is public or private is error prone (we are all human, and can miss things with no malintent) and time consuming.

At the very least I would suggest, `docutils.nodes`, the reader/writer/parser aliases, `docutils.core`,  and the front end tools. (I'm happy to write out the full list if you give me modules/etc that should be part of the public API). It would also be useful to identify what parts of Docutils large downstream consumers use, and either create higher level abstractions or mark those as public API. (I would suggest Sphinx and MyST-parser). 

It is also the [established practice](https://www.python.org/dev/peps/pep-0008/#descriptive-naming-styles) to mark names as private by prefixing them with an underscore. I suggest adopting this, as it gives strong guidance to downstream library authors what Docutils considers private and public. Making a private name public is far easier than going through a deprecation cycle for the reverse.

I'd suggest adding the ability to have exceptions to the policy, with removal after one minor version. My full suggested text is:

**"Removal or significant alteration of any members of the public API will only take place after the behaviour has been marked as deprecated for two minor releases. Certain changes may have a shorter deprecation period of one minor release. This requires at least two project members to be in favour of doing so, and no members against.**

**Changes that may affect end-users (e.g. by requiring changes to the configuration file or potentially breaking custom style sheets) should be announced with a FutureWarning."**

This post is intentionally opinionated so as to provide something to talk over / edit -- I'm not massively attached to any one thing!

A

----
for reference, amongst others, I took inspiration from:
https://setuptools.pypa.io/en/latest/development/releases.html
https://pip.pypa.io/en/latest/development/release-process/
https://numpy.org/neps/nep-0023-backwards-compatibility.html



---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/feature-requests/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/feature-requests/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Alex F. <afo...@us...>]

Here is what I have tried, all in combination with :width: 100%:

With no :widths:, all columns in HTML output are 13%, so the last column is too narrow.  In LaTeX output, the table doesn't fit the page width (:width: 100% seems to be ignored).

With :widths auto, the column widths in HTML are not specified, and hence the columns are all different widths, depending on the contents.  In LaTeX output, the table doesn't fit the page width (:width: 100% seems to be ignored).

With :widths: 1 1 1 1 1 1 1 1 or :widths: grid, all columns in HTML output are 13%, so the last column is too narrow.  In LaTeX output, the table fits the full page width and all columns are the same width.

Also note that I am using docutils via sphinx, I'm not sure if sphinx messes with anything in between.


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Thu Feb 10, 2022 06:18 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] Drop docutils==0.15.1.post1

[Alex X. <dev...@gm...>]

Hey folks,
Could some one drop docutils==0.15.1.post1 , please.

Collecting docutils==0.15.1.post1

  Using cached docutils-0.15.1-post1.tar.gz (1.7 MB)

  Preparing metadata (setup.py) ... error

  *error*: *subprocess-exited-with-error*



  × python setup.py egg_info did not run successfully.

  │ exit code: *1*

  ╰─> [4 lines of output]

      Error: The "distutils" standard module, which is required for the

      installation of Docutils, could not be found.  You may need to

      install a package called "python-devel" (or similar) on your

      system using your package manager.

      [end of output]



  *note*: This error originates from a subprocess, and is likely not a
problem with pip.

*error*: *metadata-generation-failed*


× Encountered error while generating package metadata.

╰─> See above for output.


*note*: This is an issue with the package mentioned above, not pip.

*hint*: See above for details.

Regards,
Oleksii

[Docutils-develop] [docutils:bugs] Re: #444 Table column width rounding can result in uneven column widths

[Günter M. <mi...@us...>]

Thank you for the report.

Unless the problem is fixed, there is a workaround:

Tables works fine with Docutils 0.18.1 and `rst2html5.py` "out of the box",
because of the new default (colwidths-auto).
https://docutils.sourceforge.io/RELEASE-NOTES.html#release-0-18-2021-10-26

With "html4css1" and "latex", you can use the config setting
`table-style: colwidths-auto` or command line option
`--table-style=colwidth-auto` (for the complete document) 
or ``:widths: auto`` on individual tables.
This should also work for Docutils 0.17.

Compare:

~~~
.. table::
   :width: 100%
   :widths: auto
   
   ===  ===  ===  ===  ===  ===  ===  ===
    x    x    x    x    x    x    x    x 
   ===  ===  ===  ===  ===  ===  ===  ===

.. table::
   :width: 100%
   :widths: grid
   
   ===  ===  ===  ===  ===  ===  ===  ===
    x    x    x    x    x    x    x    x 
   ===  ===  ===  ===  ===  ===  ===  ===
~~~


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Thu Feb 10, 2022 06:18 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] Print info and prompt when waiting for input from terminal (patch).

[Guenter M. <mi...@us...>]

Dear Docutils developers,

please find attached a patch suggestion improving the front-end tool user
experience.

Feedback welcome,

Günter

Subject: [PATCH] core.Publisher.publish(): Prompt when waiting for input from a terminal.

When front-end tools are used without arguments, Docutils reads
from stdin. After calling `rst2html.py`, say, from a terminal
there was no response until the user guessed right and
pressed Ctrl-D (or Ctrl-Z on Windows) or aborted with Ctrl-C.

With the addition, Doctils tells the user what it expects and where to
get more help.
---
 docutils/HISTORY.txt                                 |  5 +++++
 docutils/docs/dev/todo.txt                           | 10 ++++++++++
 docutils/docutils/core.py                            | 40 +++++++++++++++++++++++++---------------
 docutils/docutils/io.py                              | 12 ++++++++++++
 docutils/docutils/parsers/rst/__init__.py            |  2 +-
 docutils/docutils/writers/html5_polyglot/__init__.py |  2 +-
 docutils/docutils/writers/pseudoxml.py               |  2 +-
 docutils/docutils/writers/xetex/__init__.py          |  2 +-
 8 files changed, 56 insertions(+), 19 deletions(-)

diff --git a/docutils/HISTORY.txt b/docutils/HISTORY.txt
index 1f3879d..7e85d33 100644
--- a/docutils/HISTORY.txt
+++ b/docutils/HISTORY.txt
@@ -32,4 +32,9 @@ Changes Since 0.18.1
     __ https://www.python.org/dev/peps/pep-0621/#entry-points
 
+* docutils/core.py:
+
+  Publisher.publish(): Print info and prompt when waiting for input from
+  a terminal cf. https://clig.dev/#interactivity.
+
 * docutils/parsers/__init__.py
 
diff --git a/docutils/docs/dev/todo.txt b/docutils/docs/dev/todo.txt
index 5f175d2..eda93a4 100644
--- a/docutils/docs/dev/todo.txt
+++ b/docutils/docs/dev/todo.txt
@@ -2867,4 +2867,14 @@ Front-End Tools
   line option then.
 
+* Implement the following suggestions from clig.dev?
+
+     Display output on success, but keep it brief.
+     provide a --quiet option to suppress all non-essential output.
+   
+     Consider chaining several args as input and use --output
+     (or redirection) for output.
+   
+     -- https://clig.dev/#help
+
 .. _partial parsing:
    https://docs.python.org/3/library/argparse.html#partial-parsing
diff --git a/docutils/docutils/core.py b/docutils/docutils/core.py
index 6301cf4..b7694c4 100644
--- a/docutils/docutils/core.py
+++ b/docutils/docutils/core.py
@@ -15,4 +15,5 @@ custom component objects first, and pass *them* to
 __docformat__ = 'reStructuredText'
 
+import os
 import sys
 import pprint
@@ -77,4 +78,5 @@ class Publisher:
         self._stderr = io.ErrorOutput()
 
+
     def set_reader(self, reader_name, parser, parser_name):
         """Set `self.reader` by name."""
@@ -203,4 +205,5 @@ class Publisher:
                     **(settings_overrides or {}))
             self.set_io()
+            self.prompt()
             self.document = self.reader.read(self.source, self.parser,
                                              self.settings)
@@ -252,4 +255,26 @@ class Publisher:
                 'raw_unicode_escape'), file=self._stderr)
 
+    def prompt(self):
+        """Print info and prompt when waiting for input from a terminal."""
+        try:
+            if not (self.source.isatty() and self._stderr.isatty()):
+                return
+        except AttributeError:
+            return
+        eot_key = 'Ctrl+Z' if os.name == 'nt' else 'Ctrl+D on an empty line'
+        in_format = 'plaintext'
+        out_format = 'useful formats'
+        try:
+            in_format = self.parser.supported[0]
+            out_format = self.writer.supported[0]
+        except (AttributeError, IndexError):
+            pass
+        print(f'Docutils {__version__}  '
+              f'converting {in_format} into {out_format}.\n'
+              'See <https://docutils.sourceforge.io> '
+              f'or use option "--help" for more info.\n'
+              f'.. Type/paste source text (finish with {eot_key}):',
+              file=self._stderr)
+
     def report_Exception(self, error):
         if isinstance(error, utils.SystemMessage):
@@ -317,19 +342,4 @@ default_description = ('Reads from <source> (default is stdin) and writes to '
                        'the full reference.')
 
-# TODO:
-# require source ('-' for stdin)?
-#
-# print usage if there is no arg
-# (always or if sys.stdout.isatty() ?)
-# Alternatively, print a log message to stderr.
-#
-# Display output on success, but keep it brief.
-# provide a -q option to suppress all non-essential output.
-#
-# Consider chaining several args as input
-# and use --output (or redirection) for output
-# argparser.add_argument('source', nargs='+')
-#
-# -- https://clig.dev/#help
 
 def publish_cmdline(reader=None, reader_name='standalone',
diff --git a/docutils/docutils/io.py b/docutils/docutils/io.py
index 7f65df6..c73c550 100644
--- a/docutils/docutils/io.py
+++ b/docutils/docutils/io.py
@@ -175,4 +175,10 @@ class Input(TransformSpec):
         return None
 
+    def isatty(self):
+        try:
+            return self.source.isatty()
+        except AttributeError:
+            return False
+
 
 class Output(TransformSpec):
@@ -303,4 +309,10 @@ class ErrorOutput:
             pass
 
+    def isatty(self):
+        try:
+            return self.destination.isatty()
+        except AttributeError:
+            return False
+
 
 class FileInput(Input):
diff --git a/docutils/docutils/parsers/rst/__init__.py b/docutils/docutils/parsers/rst/__init__.py
index 7831752..4d2a294 100644
--- a/docutils/docutils/parsers/rst/__init__.py
+++ b/docutils/docutils/parsers/rst/__init__.py
@@ -82,5 +82,5 @@ class Parser(docutils.parsers.Parser):
     """The reStructuredText parser."""
 
-    supported = ('restructuredtext', 'rst', 'rest', 'restx', 'rtxt', 'rstx')
+    supported = ('rst', 'rest', 'restructuredtext', 'restx', 'rtxt', 'rstx')
     """Aliases this parser supports."""
 
diff --git a/docutils/docutils/writers/html5_polyglot/__init__.py b/docutils/docutils/writers/html5_polyglot/__init__.py
index 2771a84..fca141e 100644
--- a/docutils/docutils/writers/html5_polyglot/__init__.py
+++ b/docutils/docutils/writers/html5_polyglot/__init__.py
@@ -37,5 +37,5 @@ from docutils.writers import _html_base
 class Writer(writers._html_base.Writer):
 
-    supported = ('html', 'html5', 'xhtml')
+    supported = ('html5', 'xhtml', 'html')
     """Formats this writer supports."""
 
diff --git a/docutils/docutils/writers/pseudoxml.py b/docutils/docutils/writers/pseudoxml.py
index b10a2d0..6f4a507 100644
--- a/docutils/docutils/writers/pseudoxml.py
+++ b/docutils/docutils/writers/pseudoxml.py
@@ -15,5 +15,5 @@ from docutils import writers, frontend
 class Writer(writers.Writer):
 
-    supported = ('pprint', 'pformat', 'pseudoxml')
+    supported = ('pseudoxml', 'pprint', 'pformat')
     """Formats this writer supports."""
 
diff --git a/docutils/docutils/writers/xetex/__init__.py b/docutils/docutils/writers/xetex/__init__.py
index 4dadbc7..f785e07 100644
--- a/docutils/docutils/writers/xetex/__init__.py
+++ b/docutils/docutils/writers/xetex/__init__.py
@@ -32,5 +32,5 @@ class Writer(latex2e.Writer):
     """A writer for Unicode-aware LaTeX variants (XeTeX, LuaTeX)"""
 
-    supported = ('lxtex', 'xetex', 'xelatex', 'luatex', 'lualatex')
+    supported = ('latex', 'tex', 'xetex', 'xelatex', 'luatex', 'lualatex')
     """Formats this writer supports."""
 
--
libgit2 1.1.0

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Alex F. <afo...@us...>]

And if it's necessary for the width to be an integer for some reason, then an alternative fix could be to keep track of the accumulated error, and round up or down depending on which would minimize the error.  In this case, the column widths should get set to 13, 12, 13, 12, etc. which would distribute the error across the columns, instead of having the last column off by such a large amount.  


---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Thu Feb 10, 2022 06:13 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #444 Table column width rounding can result in uneven column widths

[Alex F. <afo...@us...>]

---

** [bugs:#444] Table column width rounding can result in uneven column widths**

**Status:** open
**Created:** Thu Feb 10, 2022 06:13 AM UTC by Alex Forencich
**Last Updated:** Thu Feb 10, 2022 06:13 AM UTC
**Owner:** nobody


In the HTML generated for a table with 8 equal-width columns, the column widths in the generated colgroups are all rounded up from 12.5% to 13%, resulting in the last column being much too narrow (0.5 * 7 = 3.5, 3.5/12.5 = 0.28, so the accumulated error is almost 30%).  The fix would be to revise the rounding in `depart_colspec` in `_html_base.py` to produce at least one decimal place, instead of rounding to the nearest integer.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Günter M. <mi...@us...>]

Attached a review and patch proposal.
More "high-level" planning and proof-of-concept files under sandbox/enhancement-proposals/settings-API


Attachments:

- [Add-helper-methods-for-frontend-and-core-review.txt](https://sourceforge.net/p/docutils/bugs/_discuss/thread/c76f9a2618/45c6/3ffa/attachment/Add-helper-methods-for-frontend-and-core-review.txt) (5.8 kB; text/plain)
- [argparse-gm.patch](https://sourceforge.net/p/docutils/bugs/_discuss/thread/c76f9a2618/45c6/3ffa/attachment/argparse-gm.patch) (19.1 kB; text/x-patch)


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Feb 05, 2022 10:26 PM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] #441 Move from "optparse" to "argparse".

[Günter M. <mi...@us...>]

On 2022-02-05, Adam Turner wrote:

> High level review:

> - The header states the GPL licence rather than public domain […]

This is from my standard template for new Python files. For Docutils, I use
the 2-clause BSD for new files and the orignal permissions for patches to
existing files.

> - Strong negative on validation within ConfigParser. I think we should
>   make validation distinct from parsing, but that should be a different
>   change

A strong point for validation in the parse stage is, that you can
have per-configfile error messages/warnings. It is suboptimal when an
invalid value (an out-of-bound interger, say) could be from any of the
configuration files or the command line but the warning/error does not tell.
Processing should go ahead, though with the faulty value ignored (maybe it is from a  config file  inaccessible to the user but overridden in a project or personal config file or on the command line).

Per-file warnings are also possible, if the ArgParser instance calls the
ConfigParser instance in a loop::

    for cf in configuration_files:
        cf_parser.read(file)
        validate(cf_parser['ACTIVE'])

The alternative concept would be a "stand-alone" ConfigParser that:

* parses SettingsSpecs for active sections, validation functions,
  and side-effects
* reads config files
* merges active settings from active sections
* converts and validates the values

This way, applications that don't parse the command line would not need to
set up an ArgumentParser instance at all.

For this, the new SettingsSpecs.argument_spec format should be:

* easy to code/read and understand in the component files
* easy to convert into `ArgumentParser.add_argument()` calls.
* easy to parse by the ConfigParser (for active sections, validation functions,  and side-effects ).

A common utility would convert the current SettingsSpecs.settings_spec
format into the new one.


> - I think the "ACTIVE" section could be a method or an `@property` --
>   `ConfigParser.active_config` or suchlike, that would be accessed by
>   `OptionParser`.

I would prefer to stay with the common interface from "configparser":

1. set up <instance> (here, also pass info about components)
2. <instance>.read()  (this will also merge the settings)
3. Get the data as <instance>[section] (or <instance>.<dict instance attribute>).

> - Explicit side effect handling -- this is fine but we should document
>   that only "XXX" is allowed to have side effects for backwards
>   compatability purposes, and ideally we would deprecate the idea of
>   side effects.

I would keep the additional "overrides" keyword as well as the
"validate_encoding_and_error_handler()" action open for use in
settings-specifications. Maybe discourage its use, though.

> - let me know if you want a review of the specific implementation
>   (there's a few things I'd change but I don't want to derail the
>   discussion)

A peer-review of the implementation would be welcome. You may send a
patch/link in private mail or just mention me at github to keep the
discussion here more on the high-level aspects.

Thanks, Günter


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Feb 05, 2022 02:18 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

Re: [Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Guenter M. <mi...@us...>]

On 2022-02-05, Adam Turner wrote:

> High level review:

> - The header states the GPL licence rather than public domain -- would
>   you be happy to say public domain instead?

This is from my standard template for new Python files. For Docutils, I use
the 2-clause BSD for new files and the orignal license for patches to
existing files.

> - Strong negative on validation within ConfigParser. I think we should
>   make validation distinct from parsing, but that should be a different
>   change

A strong point for validation in the parse stage is, that you can
have per-configfile error messages/warnings. It is suboptimal when an
invalid value (a negative interger, say) could be from any of the
configuration files + command line but the warning/error does not tell.

Per-file warnings are also possible, if the arg_parser calls the
ConfigParser instance in a loop::

    for cf in configuration_files:
        cf_parser.read(file)
	validate(cf_parser['ACTIVE'])
	
The alternative concept would be a "stand-alone" ConfigParser that would:

* parse SettingsSpecs for active sections, validation functions,
  and side-effects
* read config files
* merge active settings from active sections
* convert and validate the values

This way, applications that don't parse the command line would not need to
set up an ArgumentParser instance at all.

For this, the new SettingsSpecs.argument_spec format should be:

* easy to code/read and understand in the component files
* easy to convert into `ArgumentParser.add_argument()` calls.
* easy to parse for active sections, validation functions,
  and side-effects in the ConfigParser.
  
A common utility would convert the current SettingsSpecs.settings_spec
format into the new one.


> - I think the "ACTIVE" section could be a method or an `@property` --
>   `ConfigParser.active_config` or suchlike, that would be accessed by
>   `OptionParser`.

I would prefer to stay with the common interface from "configparser":

1. set up <instance> (here, also pass info about components)
2. <instance>.read()  (this will also merge the settings)
3. Get the data as <instance>[section] (or <instance>.<dict instance attribute>).

> - Explicit side effect handling -- this is fine but we should document
>   that only "XXX" is allowed to have side effects for backwards
>   compatability purposes, and ideally we would deprecate the idea of
>   side effects.

I would keep the additional "overrides" keyword as well as the
"validate_encoding_and_error_handler()" action open for use in
settings-specifications. Maybe discourage its use, though.

> - let me know if you want a review of the specific implementation
>   (there's a few things I'd change but I don't want to derail the
>   discussion)

A peer-review of the implementation would be welcome. You may send a
patch/link in private mail or just mention me at github to keep the
discussion here more on the high-level aspects.

Thanks, Günter

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

High level review:

- The header states the GPL licence rather than public domain -- would you be happy to say public domain instead? It would be really bad to add GPL code into the core of Docutils, which is currently public domain / BSD. 
- Strong negative on validation within ConfigParser. I think we should make validation distinct from parsing, but that should be a different change
- I think the "ACTIVE" section could be a method or an `@property` -- `ConfigParser.active_config` or suchlike, that would be accessed by `OptionParser`.
- Explicit side effect handling -- this is fine but we should document that only "XXX" is allowed to have side effects for backwards compatability purposes, and ideally we would deprecate the idea of side effects.
- apart from that it seems reasonable at a high level, let me know if you want a review of the specific implementation (there's a few things I'd change but I don't want to derail the discussion)

A


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Feb 05, 2022 01:47 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

Meta -- is there a better way to review/work on these patches than the SF interface? Could I be given access to a `sandbox/blah` folder that we could use for prototyping instead of uploading loads of files here?

A


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Feb 05, 2022 01:44 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.

[Docutils-develop] [docutils:bugs] Re: #441 Move from "optparse" to "argparse".

[Adam T. <aa-...@us...>]

For reference "these" are the two patches 0001-Small... and 0002-Clean... -- I reviewed these locally. I assumed that these replaced the earlier "argparse-gm.patch"

A


---

** [bugs:#441] Move from "optparse" to "argparse".**

**Status:** open
**Created:** Thu Jan 06, 2022 03:02 PM UTC by Günter Milde
**Last Updated:** Sat Feb 05, 2022 01:40 AM UTC
**Owner:** Günter Milde


The optparse documentation says:
> Deprecated since version 3.2: The optparse module is deprecated and will not be developed further; development will continue with the argparse module.

We are currently suppressing related deprecation warnings in the test suite.
After raising the Python dependency to >=3.7, now may be the right time to make the move.


---

Sent from sourceforge.net because doc...@li... is subscribed to https://sourceforge.net/p/docutils/bugs/

To unsubscribe from further messages, a project admin can change settings at https://sourceforge.net/p/docutils/admin/bugs/options.  Or, if this is a mailing list, you can unsubscribe from the mailing list.