Progressbar object is no more an iterator #1125
Comments
|
Bisect shows 8780a76, from #706, as the origin of the issue. Prior to that, @ThiefMaster and @dsully, were involved in that PR. |
|
Since click is a py2/py3 compatible project, we should consider using This also seems pretty easy to add a test for, based on the example given. |
|
Due to various issues, we don't use six in the Pallets projects. I think there was actually an issue with streams due to six that was worked around in Click 7. We try to implement only as much as we need in I don't mind just adding |
I'm super-curious, but I'll save looking into this until after my workday.
Adding |
- add a test for iterating on a progressbar with next() - implement `next()` in terms of `iter(ProgressBar)`, which is already well-defined - add a note about slow operations with progressbar to narrative docs One of the keys to this working is that `ProgressBar.generator` is consuming an iterable and doesn't store any important state in local variables, making it re-entry safe. I wasn't sure how we can best hint in the public docs that simply walking the bar and stopping one step short of finishing will result in the progress bar "hanging" unfinished. Noting that we work well with things like `time.sleep()` seems like a decent way of advertising positively something which we support *and* guiding anyone going off-book into proper usage. closes pallets#1125
- add a test for iterating on a progressbar with next() - implement `next()` in terms of `iter(ProgressBar)`, which is already well-defined - add a note about slow operations with progressbar to narrative docs One of the keys to this working is that `ProgressBar.generator` is consuming an iterable and doesn't store any important state in local variables, making it re-entry safe. I wasn't sure how we can best hint in the public docs that simply walking the bar and stopping one step short of finishing will result in the progress bar "hanging" unfinished. Noting that we work well with things like `time.sleep()` seems like a decent way of advertising positively something which we support *and* guiding anyone going off-book into proper usage. closes pallets#1125
- add a test for iterating on a progressbar with next() - implement `next()` in terms of `iter(ProgressBar)`, which is already well-defined - add a note about slow operations with progressbar to narrative docs One of the keys to this working is that `ProgressBar.generator` is consuming an iterable and doesn't store any important state in local variables, making it re-entry safe. I wasn't sure how we can best hint in the public docs that simply walking the bar and stopping one step short of finishing will result in the progress bar "hanging" unfinished. Noting that we work well with things like `time.sleep()` seems like a decent way of advertising positively something which we support *and* guiding anyone going off-book into proper usage. closes pallets#1125
- add a test for iterating on a progressbar with next() - implement `next()` in terms of `iter(ProgressBar)`, which is already well-defined - add a note about slow operations with progressbar to narrative docs One of the keys to this working is that `ProgressBar.generator` is consuming an iterable and doesn't store any important state in local variables, making it re-entry safe. I wasn't sure how we can best hint in the public docs that simply walking the bar and stopping one step short of finishing will result in the progress bar "hanging" unfinished. Noting that we work well with things like `time.sleep()` seems like a decent way of advertising positively something which we support *and* guiding anyone going off-book into proper usage. closes pallets#1125
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hi,
With Click < 7.0, iterating on the bar object was possible:
With Click 7.0, this is broken:
Is it on purpose ? Seems related to 82f9c62 (#487)
The text was updated successfully, but these errors were encountered: