Discussion:
[Docutils-develop] Bugfix release 0.13.2
Guenter Milde
2017-02-06 09:39:36 UTC
Permalink
Dear David, dear Docutils developers,

I think it is time to roll out the bugfix release 0.13.2.
...
... There was an internal change to Docutils in revision 7942 that
refactored some code, and a side effect was to remove some
attributes from the Inliner class (they became locals instead).
...
Günter, I think the attached patch should also be rolled into a 0.13.2
bugfix release.
Is the patch still "on the table"?
Yes, but I'm looking at making more extensive changes first.
The patch that implemented the changes to support
1. Inliner.__init__ is currently a no-op (code: just "pass"). That
smells bad. Why even have the method if it does nothing? Prior to the
patch (in, say, r7640), it initialized self.implicit_dispatch. It
can't do that completely now, but it can initialize an empty
self.implicit_dispatch with a docstring.
2. My coding style is to initialize all instance attributes in the
__init__ method of a class, for easy reference, and include an
attribute docstring for documentation. The Inliner class now breaks
this style. I'd like to fix this.
3. The Inliner.init_customizations method grew from 6 physical lines
of code to almost 140 lines. This was because all of the formerly
statically defined class attributes were brought in, to be defined
dynamically depending on settings.character_level_inline_markup. I
plan to refactor this huge method into a small init_customizations and
shunt all the definitions into another method.
4. That ``args.update(vars(Inliner))`` line is fragile, and should be replaced.
I'll work on all these and propose another patch.
How is work going on this?

Thanks,
Günter


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply
David Goodger
2017-02-12 21:34:00 UTC
Permalink
Post by Guenter Milde
Dear David, dear Docutils developers,
I think it is time to roll out the bugfix release 0.13.2.
...
... There was an internal change to Docutils in revision 7942 that
refactored some code, and a side effect was to remove some
attributes from the Inliner class (they became locals instead).
...
Günter, I think the attached patch should also be rolled into a 0.13.2
bugfix release.
Is the patch still "on the table"?
Yes, but I'm looking at making more extensive changes first.
The patch that implemented the changes to support
1. Inliner.__init__ is currently a no-op (code: just "pass"). That
smells bad. Why even have the method if it does nothing? Prior to the
patch (in, say, r7640), it initialized self.implicit_dispatch. It
can't do that completely now, but it can initialize an empty
self.implicit_dispatch with a docstring.
2. My coding style is to initialize all instance attributes in the
__init__ method of a class, for easy reference, and include an
attribute docstring for documentation. The Inliner class now breaks
this style. I'd like to fix this.
3. The Inliner.init_customizations method grew from 6 physical lines
of code to almost 140 lines. This was because all of the formerly
statically defined class attributes were brought in, to be defined
dynamically depending on settings.character_level_inline_markup. I
plan to refactor this huge method into a small init_customizations and
shunt all the definitions into another method.
4. That ``args.update(vars(Inliner))`` line is fragile, and should be replaced.
I'll work on all these and propose another patch.
How is work going on this?
I have an incomplete implementation in my local checkout. I'll try to
get it done ASAP, but it's not highest priority right now.

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply
David Goodger
2017-02-12 21:41:29 UTC
Permalink
Post by Guenter Milde
Dear David, dear Docutils developers,
I think it is time to roll out the bugfix release 0.13.2.
...
... There was an internal change to Docutils in revision 7942 that
refactored some code, and a side effect was to remove some
attributes from the Inliner class (they became locals instead).
...
Günter, I think the attached patch should also be rolled into a 0.13.2
bugfix release.
Is the patch still "on the table"?
Yes, but I'm looking at making more extensive changes first.
The patch that implemented the changes to support
1. Inliner.__init__ is currently a no-op (code: just "pass"). That
smells bad. Why even have the method if it does nothing? Prior to the
patch (in, say, r7640), it initialized self.implicit_dispatch. It
can't do that completely now, but it can initialize an empty
self.implicit_dispatch with a docstring.
2. My coding style is to initialize all instance attributes in the
__init__ method of a class, for easy reference, and include an
attribute docstring for documentation. The Inliner class now breaks
this style. I'd like to fix this.
3. The Inliner.init_customizations method grew from 6 physical lines
of code to almost 140 lines. This was because all of the formerly
statically defined class attributes were brought in, to be defined
dynamically depending on settings.character_level_inline_markup. I
plan to refactor this huge method into a small init_customizations and
shunt all the definitions into another method.
4. That ``args.update(vars(Inliner))`` line is fragile, and should be replaced.
I'll work on all these and propose another patch.
How is work going on this?
I have an incomplete implementation in my local checkout. I'll try to
get it done ASAP, but it's not highest priority right now.

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply
engelbert gruber
2017-02-13 10:38:43 UTC
Permalink
i got a note if i should release , do i ?

cheers
Post by Guenter Milde
Post by Guenter Milde
Dear David, dear Docutils developers,
I think it is time to roll out the bugfix release 0.13.2.
...
... There was an internal change to Docutils in revision 7942 that
refactored some code, and a side effect was to remove some
attributes from the Inliner class (they became locals instead).
...
GÃŒnter, I think the attached patch should also be rolled into a
0.13.2
Post by Guenter Milde
bugfix release.
Is the patch still "on the table"?
Yes, but I'm looking at making more extensive changes first.
The patch that implemented the changes to support
1. Inliner.__init__ is currently a no-op (code: just "pass"). That
smells bad. Why even have the method if it does nothing? Prior to the
patch (in, say, r7640), it initialized self.implicit_dispatch. It
can't do that completely now, but it can initialize an empty
self.implicit_dispatch with a docstring.
2. My coding style is to initialize all instance attributes in the
__init__ method of a class, for easy reference, and include an
attribute docstring for documentation. The Inliner class now breaks
this style. I'd like to fix this.
3. The Inliner.init_customizations method grew from 6 physical lines
of code to almost 140 lines. This was because all of the formerly
statically defined class attributes were brought in, to be defined
dynamically depending on settings.character_level_inline_markup. I
plan to refactor this huge method into a small init_customizations and
shunt all the definitions into another method.
4. That ``args.update(vars(Inliner))`` line is fragile, and should be
replaced.
Post by Guenter Milde
I'll work on all these and propose another patch.
How is work going on this?
I have an incomplete implementation in my local checkout. I'll try to
get it done ASAP, but it's not highest priority right now.
David Goodger
<http://python.net/~goodger>
------------------------------------------------------------
------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
https://lists.sourceforge.net/lists/listinfo/docutils-develop
Please use "Reply All" to reply to the list.
Guenter Milde
2017-02-13 17:13:22 UTC
Permalink
Dear Engelbert, dear David, dear others,
Post by engelbert gruber
i got a note if i should release , do i ?
Of course. However, I wonder whether we should do a pure bugfix release at
all:

* there are downstream workarounds/fixes in place for all problems we have
handled in Docutils as well.
Post by engelbert gruber
Post by David Goodger
I have an incomplete implementation in my local checkout. I'll try to
get it done ASAP, but it's not highest priority right now.
* There are other bugfixes in the pipeline that are not fully backwards
compatible:

- latex/xetex writer: compilation fails with an epigraph that contains
more than one paragraph.

The fix is backwards-compatible with one exception: a \DUroleepigraph
(for styling one-paragraph epigraphs) would be ignored.

- inline parsing:

fix #307 Non-breaking whitespace and the inline markup recognition rules.

I prefer to adapt the implementation to the spec: no whitespace at the
inner boundaries of inline markup strings.

With this, * text in NBSP * would no longer be emphasized.

So, maybe we could just release 0.14.

Günter


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply
David Goodger
2017-02-13 17:31:04 UTC
Permalink
On Mon, Feb 13, 2017 at 4:38 AM, engelbert gruber
Post by engelbert gruber
i got a note if i should release , do i ?
I don't understand the intent of the question.

Are you asking: should you do a release now?
Or: should you do a release after you "get a note"?

I don't think we're ready for a release right now.
Post by engelbert gruber
i will get one is better english
I don't understand this either.

David Goodger
<http://python.net/~goodger>

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Docutils-develop mailing list
Docutils-***@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/docutils-develop

Please use "Reply All" to reply to the list.

Loading...