> This is all irrelevant if you haven't signed the CLA*.
IMO, this shouldn't be an argument against the proposed changes, as the CLA
is fairly straightforward and only takes 24-48 hours to process. Unless the
OP specifically is unable to or doesn't want to sign the CLA, it won't be a
significant c
On Mon, Nov 4, 2019 at 5:42 AM Edward K. Ream wrote:
> ...there are two reasons why adding the gem to tokenize.py might be a
good idea.
Heh. I myself am not convinced that the gem needs "advertising" in
tokenize.py.
Those interested in how Leo's token-based commands work would be more
likely t
On 11/04/2019 03:42 AM, Edward K. Ream wrote:
On Sun, Nov 3, 2019 at 7:23 PM Edward K. Ream wrote:
Let's be clear, there is no reason for python libraries to include every little
code gem. However, I have two motivations adding the gem to the tokenize module:
This is all irrelevant if you h
On Sun, Nov 3, 2019 at 7:23 PM Edward K. Ream wrote:
Clearly, the new code would have to be repackaged if it were to be made
> part of tokenize.py. That's all I would like to say now regarding your
> comments. Perhaps other devs will pick up the ball.
>
After sleeping on your comments, I would l
On Sun, Nov 3, 2019 at 4:14 PM Terry Reedy wrote:
> > **tl;dr:** Various posts, linked below, discuss a much better
replacement for untokenize.
> If that were true, I would be interested. But as explained below, I
don't believe it.
I do not believe that the tone of my post was in any way objec
On 11/3/2019 11:12 AM, Edward K. Ream wrote:
I am creating this post as a courtesy to anyone interested in python's tokenize
module.
As one of the 46 contributors to this module, and as one who fixed
several untokenize bugs a few years ago, I am interested.
> **tl;dr:** Various posts, linke
