Eric Kafe

I also observe slightly better timings with force_list=True. The difference is small but consistent, so this additional parameter does not contribute to solving the speed bottleneck from #3193. Still, it...

Testing with more inputs, the speedup from _force_list= False_ stays small, but it displays some randomness, and it is not always positive or negative. It may be questionable whether it...

> It's an iterable regardless. But it is not an iterator: _next([])_ fails with > TypeError: 'list' object is not an iterator while _next(iter([]))_ returns > StopIteration

Wouldn't you prefer that the output of __related(force_list=False)_ had the same predictable type, no matter whether targets were found or not?

There are two _\_related()_ functions: one for lemmas, which does not support a _sort_ argument, and one for synsets, which has _sort_ set to True by default. But False would...

However, it seems that we need to sort the output, because otherwise it would be returned in random order, so no test would be reproducible. Consider the hyponyms of _legal...

Thanks @bryant1410 for your suggestion to sort the tests' output. However, this would not be necessary if we keep sort=True as default. Considering your use case, if it was possible...

Thanks @bryant1410! Your linked source script contains the following comment: > \# For the following two functions: we use `_related` instead of the actual nice names to avoid sorting unnecessarily....

That sounds great, @bryant1410, and you're very welcome to submit a PR! Please note that these functions are called in many doctests all around, and especially in _nltk/test/wordnet.doctest_. The tests...

> I prefer the solution that _related() does not sort by default. Me too: it breaks backward compatibility, but the current defaults are not optimal. Moreover, returning a generator is...