Peter Law

> > it would be great if it didn't need to do assert asttokens.tree is not None just to placate the type checker. > > While I'm hesitant to remove/deprecate...

> So if something were to lazily initialise tokens just by calling `.tokens` or something it would be hard to notice. Well, yes. This is exactly my point. Calls to...

I think we may need to agree to disagree here. Fundamentally the change in #93 breaks static analysis of `asttokens` consumers (as well as internally) and has the potential to...

Just a thought here -- would using something like https://pypi.org/project/cached-property/ make this easier given the goal of lazy evaluation? That would sidestep the need for various places to check whether...

Ah, ok. I think I'd misunderstood from the discussion on that issue. Given that goal I would repeat the encouragement I made on that issue -- of exploring having variations...

> Can you show a sketch of what the consumer code would look like and what the difference/advantage would be? Right now I think the default case is `atok =...

> > Can you show a sketch of what the consumer code would look like and what the difference/advantage would be? Right now I think the default case is `atok...

While rebasing #98 I hit a test failure which I think is present in this PR too -- the f-string handling in `atok.get_text` implicitly relies on `mark_tokens` having run before...

> @PeterJCLaw please can you write an example of what using the API in #98 would look like, compared with the API here, I think the tests in #98 cover...

Ah, I'd not spotted that this was intentional. I agree the "standard" API has the potential for confusion. I do suspect it may be the lesser of two evils to...