GithubHelp home page GithubHelp logo

wolph / python-progressbar Goto Github PK

View Code? Open in Web Editor NEW
842.0 21.0 141.0 1.37 MB

Progressbar 2 - A progress bar for Python 2 and Python 3 - "pip install progressbar2"

Home Page: http://progressbar-2.readthedocs.org/en/latest/

License: BSD 3-Clause "New" or "Revised" License

Python 100.00%
python progressbar progress-bar rate eta percentage console terminal time progress

python-progressbar's Introduction

Text progress bar library for Python.

Build status:

python-progressbar test status

Coverage:

image

Install

The package can be installed through pip (this is the recommended method):

pip install progressbar2

Or if pip is not available, easy_install should work as well:

easy_install progressbar2

Or download the latest release from Pypi (https://pypi.python.org/pypi/progressbar2) or Github.

Note that the releases on Pypi are signed with my GPG key (https://pgp.mit.edu/pks/lookup?op=vindex&search=0xE81444E9CE1F695D) and can be checked using GPG:

gpg --verify progressbar2-<version>.tar.gz.asc progressbar2-<version>.tar.gz

Introduction

A text progress bar is typically used to display the progress of a long running operation, providing a visual cue that processing is underway.

The progressbar is based on the old Python progressbar package that was published on the now defunct Google Code. Since that project was completely abandoned by its developer and the developer did not respond to email, I decided to fork the package. This package is still backwards compatible with the original progressbar package so you can safely use it as a drop-in replacement for existing project.

The ProgressBar class manages the current progress, and the format of the line is given by a number of widgets. A widget is an object that may display differently depending on the state of the progress bar. There are many types of widgets:

The progressbar module is very easy to use, yet very powerful. It will also automatically enable features like auto-resizing when the system supports it.

Security contact information

To report a security vulnerability, please use the Tidelift security contact. Tidelift will coordinate the fix and disclosure.

Known issues

  • The Jetbrains (PyCharm, etc) editors work out of the box, but for more advanced features such as the MultiBar support you will need to enable the "Enable terminal in output console" checkbox in the Run dialog.
  • The IDLE editor doesn't support these types of progress bars at all: https://bugs.python.org/issue23220
  • Jupyter notebooks buffer sys.stdout which can cause mixed output. This issue can be resolved easily using: import sys; sys.stdout.flush(). Linked issue: #173

Usage

There are many ways to use Python Progressbar, you can see a few basic examples here but there are many more in the examples file.

Wrapping an iterable

import time
import progressbar

for i in progressbar.progressbar(range(100)):
    time.sleep(0.02)

Progressbars with logging

Progressbars with logging require stderr redirection _before the StreamHandler is initialized. To make sure the stderr stream has been redirected on time make sure to call progressbar.streams.wrap_stderr() before you initialize the logger.

One option to force early initialization is by using the WRAP_STDERR environment variable, on Linux/Unix systems this can be done through:

# WRAP_STDERR=true python your_script.py

If you need to flush manually while wrapping, you can do so using:

import progressbar

progressbar.streams.flush()

In most cases the following will work as well, as long as you initialize the StreamHandler after the wrapping has taken place.

import time
import logging
import progressbar

progressbar.streams.wrap_stderr()
logging.basicConfig()

for i in progressbar.progressbar(range(10)):
    logging.error('Got %d', i)
    time.sleep(0.2)

Multiple (threaded) progressbars

import random
import threading
import time

import progressbar

BARS = 5
N = 50


def do_something(bar):
    for i in bar(range(N)):
        # Sleep up to 0.1 seconds
        time.sleep(random.random() * 0.1)

        # print messages at random intervals to show how extra output works
        if random.random() > 0.9:
            bar.print('random message for bar', bar, i)


with progressbar.MultiBar() as multibar:
    for i in range(BARS):
        # Get a progressbar
        bar = multibar[f'Thread label here {i}']
        # Create a thread and pass the progressbar
        threading.Thread(target=do_something, args=(bar,)).start()

Context wrapper

import time
import progressbar

with progressbar.ProgressBar(max_value=10) as bar:
    for i in range(10):
        time.sleep(0.1)
        bar.update(i)

Combining progressbars with print output

import time
import progressbar

for i in progressbar.progressbar(range(100), redirect_stdout=True):
    print('Some text', i)
    time.sleep(0.1)

Progressbar with unknown length

import time
import progressbar

bar = progressbar.ProgressBar(max_value=progressbar.UnknownLength)
for i in range(20):
    time.sleep(0.1)
    bar.update(i)

Bar with custom widgets

import time
import progressbar

widgets=[
    ' [', progressbar.Timer(), '] ',
    progressbar.Bar(),
    ' (', progressbar.ETA(), ') ',
]
for i in progressbar.progressbar(range(20), widgets=widgets):
    time.sleep(0.1)

Bar with wide Chinese (or other multibyte) characters

# vim: fileencoding=utf-8
import time
import progressbar


def custom_len(value):
    # These characters take up more space
    characters = {
        '进': 2,
        '度': 2,
    }

    total = 0
    for c in value:
        total += characters.get(c, 1)

    return total


bar = progressbar.ProgressBar(
    widgets=[
        '进度: ',
        progressbar.Bar(),
        ' ',
        progressbar.Counter(format='%(value)02d/%(max_value)d'),
    ],
    len_func=custom_len,
)
for i in bar(range(10)):
    time.sleep(0.1)

Showing multiple independent progress bars in parallel

import random
import sys
import time

import progressbar

BARS = 5
N = 100

# Construct the list of progress bars with the `line_offset` so they draw
# below each other
bars = []
for i in range(BARS):
    bars.append(
        progressbar.ProgressBar(
            max_value=N,
            # We add 1 to the line offset to account for the `print_fd`
            line_offset=i + 1,
            max_error=False,
        )
    )

# Create a file descriptor for regular printing as well
print_fd = progressbar.LineOffsetStreamWrapper(lines=0, stream=sys.stdout)

# The progress bar updates, normally you would do something useful here
for i in range(N * BARS):
    time.sleep(0.005)

    # Increment one of the progress bars at random
    bars[random.randrange(0, BARS)].increment()

    # Print a status message to the `print_fd` below the progress bars
    print(f'Hi, we are at update {i+1} of {N * BARS}', file=print_fd)

# Cleanup the bars
for bar in bars:
    bar.finish()

# Add a newline to make sure the next print starts on a new line
print()

Naturally we can do this from separate threads as well:

import random
import threading
import time

import progressbar

BARS = 5
N = 100

# Create the bars with the given line offset
bars = []
for line_offset in range(BARS):
    bars.append(progressbar.ProgressBar(line_offset=line_offset, max_value=N))


class Worker(threading.Thread):
    def __init__(self, bar):
        super().__init__()
        self.bar = bar

    def run(self):
        for i in range(N):
            time.sleep(random.random() / 25)
            self.bar.update(i)


for bar in bars:
    Worker(bar).start()

print()

python-progressbar's People

Contributors

alapidas avatar cbrnr avatar drwilco avatar hroff-1902 avatar joe-antognini avatar keszybz avatar marcelotrevisani avatar matthewwardrop avatar max-arnold avatar mgorny avatar mueslo avatar niltonvolpato avatar nxsofsys avatar opoplawski avatar paulo-raca avatar pganssle avatar pr0ps avatar preston-landers avatar raingo avatar rgeoghegan avatar ritze avatar stuertz avatar takluyver avatar terencehonles avatar tnestmeyer avatar william-andre avatar wohthan avatar wolph avatar zannick avatar zzzsochi avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

python-progressbar's Issues

Version 3.0.1: ImportError: No module named fcntl

Hi I got trouble with installing new version (3.0.1) on Windows:

In my case progressbar2 installed as a dependency of django-stdimage.

Console output:

Collecting progressbar2>=2.7 (from django-stdimage==1.2.2->-r requirements\base.txt (line 22))
  Using cached progressbar2-3.0.1.tar.gz
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):
      File "<string>", line 20, in <module>
      File "c:\users\jenssd~1\appdata\local\temp\pip-build-rnf6vf\progressbar2\setup.py", line 6, in <module>
        from progressbar import metadata
      File "progressbar\__init__.py", line 64, in <module>
        from .bar import ProgressBar
      File "progressbar\bar.py", line 5, in <module>
        import fcntl
    ImportError: No module named fcntl

    ----------------------------------------
Command "python setup.py egg_info" failed with error code 1 in c:\users\jenssd~1\appdata\local\temp\pip-build-rnf6vf\progressbar2

Progress always on newline, not overwriting same line?

First of all: thanks for all the development on this! I'm getting a small problem with the output being on newlines. Not sure if this is intended behavior, I assumed the text would be updated inline, but instead I get progress updates on new lines:

1
  0%|                                                                          |2
  0%|                                                                          |3
  0%|                                                                          |4
  1%|                                                                          |5
  1%|                                                                          |6
  1%|#                                                                         |7
  1%|#                                                                         |8
  2%|#                                                                         |9
  2%|#                                                                         |10
  2%|#                                                                         |11

Here's my code:

    progress_bar = ProgressBar(max_value=image_count).start()
    for root, _, files in os.walk(directory):
        for file_name in files:
            loop_counter += 1
            progress_bar.update(loop_counter)
            ...
    print("Done processing images!")
    progress_bar.finish()

regressions in appearance in Jupyter notebooks

Hello, the appearance of the progress bars in Jupyter notebooks has degraded in recent versions. I'm using jupyter notebook 4.0 on osx with chrome. For now I'm sticking with 3.4.0, but I can try to debug the later versions as well.

The last version that looked good was 3.4.0

image

In 3.4.1, the progress bars span multiple lines.

image

Same behavior in 3.5.2,

image

In 3.6.0, the progress bar doesn't show up until it's actually finished. Below is while it's still looping.

image

Here it has finished.

image

tput: No value for $TERM and no -T specified?

Hi,

When I run this:

from progressbar import ProgressBar, Percentage, AbsoluteETA, ETA, Bar
import time

widgets = ['Test: ', Percentage(), ' | ', ETA(), ' | ', AbsoluteETA()]
pbar = ProgressBar(widgets=widgets, maxval=500).start()
for i in range(500):
    time.sleep(0.01)
    pbar.update(i+1)
pbar.finish()

I get this output:

/usr/bin/python3.4 /home/anjum/Python/pbar_test.py
tput: No value for $TERM and no -T specified
Test: 100% | Time: 0:00:05 | Finished at: 2015/12/08 23:57:28    

Does anyone know what the cause of the tput: No value for $TERM and no -T specified is?

progress bar updates too fast

I'm using the progress bar to show progress for a file transfer. The progress bar works just fine, but it's updating too fast. In the image, the estimated time and estimated transfer speed are being updated really quickly, which causes a flickering effect.

screen shot 2015-01-22 at 11 58 02 pm

Is there a way to get it to update at a fixed interval, or at least less frequently?

Shows nothing while processing

I just get the finished bar after the process, but there is nothing to see while processing.

Tried some of the examples, but always the same: displays nothing until finish.

Do you or someone have an idea for this issue?

Python 3.4.3 on Win 8.1 and PyCharm IDE

Silencing stdout for use in frozen apps

I'm using progress bar for the speed and eta widgets, however I'm displaying the output using qt instead of stdout. This works well but when using it in a frozen app I'm finding that py2exe tries to write the stdout from progress bar to a logfile which is causing me some issues.

Is there a simple way to 'silence' the output from progressbar?

examples.py fails...maybe?

Python 3.5, Windows 10

Traceback (most recent call last):

  File "examples.py", line 373, in <module>
    test()
  File "examples.py", line 368, in test
    example()
  File "examples.py", line 21, in wrapped
    fn()
  File "examples.py", line 236, in with_example18
    assert progress._env_size() is not None

you know, I just realized what might be the issue.

AFAICT, examples.py doesn't come down when you install via pip so I just copied examples.py off of the repo...but maybe the repo is ahead of whats on pip?

If that's the case, maybe include examples.py on the pip version...

Width of progressbar is wrong

 10% (1 of 10) |##                          | Elapsed Time: 0:00:00 ETA: 0:00:0
 20% (2 of 10) |#####                       | Elapsed Time: 0:00:00 ETA: 0:00:0
 30% (3 of 10) |########                    | Elapsed Time: 0:00:00 ETA: 0:00:0
 40% (4 of 10) |###########                 | Elapsed Time: 0:00:00 ETA: 0:00:0
 50% (5 of 10) |##############              | Elapsed Time: 0:00:00 ETA: 0:00:0  
 60% (6 of 10) |################            | Elapsed Time: 0:00:00 ETA: 0:00:0 
 70% (7 of 10) |###################         | Elapsed Time: 0:00:00 ETA: 0:00:0
 80% (8 of 10) |######################      | Elapsed Time: 0:00:00 ETA: 0:00:0
 90% (9 of 10) |#########################   | Elapsed Time: 0:00:00 ETA: 0:00:0
100% (10 of 10) |#############################| Elapsed Time: 0:00:01 Time: 1.00

arch linux, i3wm, rxvt-unicode-256 color
Also on windows in mysy2

signal.SIGWINCH does not exist on Windows

Version 3.4.1 of progressbar2 seems to be completely broken on Windows, because it is calling signal.SIGWINCH, which is apparently not available on Windows.

>>> import progressbar
>>> pb = progressbar.ProgressBar()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "C:\Python34\lib\site-packages\progressbar\bar.py", line 167, in __init__
    StdRedirectMixin.__init__(self, **kwargs)
  File "C:\Python34\lib\site-packages\progressbar\bar.py", line 75, in __init__
    super(StdRedirectMixin, self).__init__(**kwargs)
  File "C:\Python34\lib\site-packages\progressbar\bar.py", line 57, in __init__
    signal.signal(signal.SIGWINCH, self._handle_resize)
AttributeError: 'module' object has no attribute 'SIGWINCH'

Tested on Python 2.7.10 and Python 3.4.3 on Windows 7. Also tested in Anaconda and Anaconda3 (python 2.7.10 and 3.4.3 respectively).

unexpected behavior under travis/miniconda

I'm trying to get travis-ci set up for my project. While I can install and use progressbar2 just fine on my development environment (and in a totally bare virtualenv), I'm getting import errors with progressbar2 on travis' docker containers. Obviously I'm doing something stupid -- but it's not clear to me what it is.

My travis.yml:

language: python
notifications:
  email: false
python:
  # We don't actually use the Travis Python, but this keeps it organized.
  - "3.4"
  - "3.5"
install:
  # - sudo apt-get update
  # We do this conditionally because it saves us some downloading if the
  # version is the same.
  - wget https://repo.continuum.io/miniconda/Miniconda3-latest-Linux-x86_64.sh -O miniconda.sh;
  - bash miniconda.sh -b -p $HOME/miniconda
  - export PATH="$HOME/miniconda/bin:$PATH"
  - hash -r
  - conda config --set always_yes yes --set changeps1 no
  - conda update -q conda
  # Useful for debugging any issues with conda
  - conda info -a
  - conda install conda-env

  # Replace dep1 dep2 ... with your dependencies
  #- conda create -q -n test-environment python=$TRAVIS_PYTHON_VERSION dep1 dep2 ...
  - conda env create -f environment.yml
  - source activate thesis-code
  - pip install progressbar2 blessed
  - python setup.py install

script:
  # Your test script goes here
  py.test

my environment.yml:

name: thesis-code
dependencies:
  - python>=3.4
  - pip
  - docopt >= 0.6.2
  - matplotlib >= 1.5.1
  - numpy >= 1.10
  - scipy >= 0.17.0
  - PyYAML >= 3.11

Travis does all this successfully, and in particular:

$ pip install progressbar2 blessed

Collecting progressbar2

  Downloading progressbar2-3.6.2-py2.py3-none-any.whl

Collecting blessed

  Downloading blessed-1.14.1-py2.py3-none-any.whl (64kB)

    100% |████████████████████████████████| 71kB 5.9MB/s 

Collecting argparse (from progressbar2)

  Downloading argparse-1.4.0-py2.py3-none-any.whl

Collecting wcwidth>=0.1.4 (from blessed)

  Downloading wcwidth-0.1.6-py2.py3-none-any.whl

Requirement already satisfied (use --upgrade to upgrade): six>=1.9.0 in /home/travis/miniconda/envs/thesis-code/lib/python3.5/site-packages (from blessed)

Installing collected packages: argparse, progressbar2, wcwidth, blessed

Successfully installed argparse-1.4.0 blessed-1.14.1 progressbar2-3.6.2 wcwidth-0.1.6

but then when running py.test:

============================= test session starts ==============================

platform linux -- Python 3.4.2 -- py-1.4.26 -- pytest-2.6.4

collected 1 items / 2 errors 

tests/test_periphery.py .

==================================== ERRORS ====================================

 ERROR collecting build/lib/verhulst_runner/analysis/get_assr_level_growth_test.py 

../../../virtualenv/python3.4.2/lib/python3.4/site-packages/py/_path/local.py:629: in pyimport

    __import__(pkgpath.basename)

build/lib/verhulst_runner/__init__.py:3: in <module>

    from .brainstem import *

build/lib/verhulst_runner/brainstem.py:7: in <module>

    import progressbar

E   ImportError: No module named 'progressbar'

___ ERROR collecting verhulst_runner/analysis/get_assr_level_growth_test.py ____

../../../virtualenv/python3.4.2/lib/python3.4/site-packages/py/_path/local.py:629: in pyimport

    __import__(pkgpath.basename)

verhulst_runner/__init__.py:3: in <module>

    from .brainstem import *

verhulst_runner/brainstem.py:7: in <module>

    import progressbar

E   ImportError: No module named 'progressbar'

====================== 1 passed, 2 error in 0.28 seconds =======================

The command "py.test" exited with 1.

Keeps printing new lines

  3% ( 17 of 480) |                        | Elapsed Time: 0:01:25 ETA:  0:41:17
  3% ( 17 of 480) |                        | Elapsed Time: 0:01:25 ETA:  0:41:16
  3% ( 18 of 480) |                        | Elapsed Time: 0:01:30 ETA:  0:41:11
  3% ( 18 of 480) |                        | Elapsed Time: 0:01:30 ETA:  0:41:11
  3% ( 19 of 480) |                        | Elapsed Time: 0:01:36 ETA:  0:41:05
  3% ( 19 of 480) |                        | Elapsed Time: 0:01:36 ETA:  0:41:05
  4% ( 20 of 480) |#                       | Elapsed Time: 0:01:41 ETA:  0:41:02
  4% ( 20 of 480) |#                       | Elapsed Time: 0:01:41 ETA:  0:41:02

Python - 3.5.1 - 2015-12-07

I am using your examples same issue

progressbar deos not finish correctly

sometimes even if updating the progressbar with the max_value, the progressbar does not finish with 100%.

This is due to the following logic in _needs_update method:

    if self.poll_interval:
        delta = datetime.now() - self.last_update_time
        poll_status = delta > self.poll_interval

    # Do not update if value increment is not large enough to
    # add more bars to progressbar (according to current
    # terminal width)
    try:
        divisor = self.max_value / self.term_width  # float division
        if self.value // divisor == self.previous_value // divisor:
            if self.poll_interval:
                return poll_status
            return False
    except:
        # ignore any division errors
        pass

    if self.value > self.next_update or self.end_time:
        return True
    elif self.poll_interval:
        return poll_status

even if updating with max_value, the method still returns False if the increment is not large enough.
suggest add the logic that returns True when max_value is reached.

In v3.8.0, ETA()/AdaptiveETA() does not work as expected

When I use ETA()/AdaptiveETA(), what I get is "Elapsed Time" rather than "ETA".
For example, when I run example with command python2 example.py eta, what I get is

Skipping with_example
Skipping with_example_stdout_redirection
Skipping basic_widget_example
Skipping file_transfer_example
Skipping custom_file_transfer_example
Skipping double_bar_example
Skipping basic_file_transfer
Skipping simple_progress
Skipping basic_progress
Skipping progress_with_automatic_max
Skipping progress_with_unavailable_max
Skipping animated_marker
Skipping counter_and_timer
Skipping format_label
Skipping animated_balloons
Skipping animated_arrows
Skipping animated_filled_arrows
Skipping animated_wheels
Skipping format_label_bouncer
Skipping format_label_rotating_bouncer
Skipping with_right_justify
Skipping exceeding_maximum
Skipping reaching_maximum
Skipping stdout_redirection
Skipping stderr_redirection
Skipping negative_maximum
Skipping rotating_bouncing_marker
Skipping incrementing_bar
Skipping increment_bar_with_output_redirection
Skipping eta_types_demonstration
Skipping adaptive_eta_without_value_change
Skipping iterator_with_max_value
Running: eta
Test:   0% | ETA: ETA:  --:--:-- | AbsoluteETA: Estimated finish time:  ----/--/-- --:--:-- | AdaptiveETA:Test:   4% | ETA: Elapsed Time: 0:00:00 | AbsoluteETA: Elapsed Time: 0:00:00 | AdaptiveETA: Elapsed Time: Test:   6% | ETA: Elapsed Time: 0:00:00 | AbsoluteETA: Elapsed Time: 0:00:00 | AdaptiveETA: Elapsed Time: 

maxval and max_value

I'm trying to use ProgressBar with a data file that I'm iterating through. My code is:
with open(filepath(RATINGS_FILE)) as data, ProgressBar(max_value=600) as bar:
This throws
TypeError: __init__() got an unexpected keyword argument 'max_value'

Also,
with open(filepath(RATINGS_FILE)) as data, ProgressBar(maxval=600) as bar:
simply throws
AttributeError: __exit__

ETA and AdaptiveETA widgets

Hi, just wondering whether you are interested in changing the ETA and AdapativeETA widgets. At the moment their estimation is based on the mean processing time per item:

pbar.seconds_elapsed / pbar.currval

and

per_item = duration / items

respectively. However, the mean is very susceptible to outliers, i.e., a few tasks that took exceptionally long will lead to over estimation of the time needed, whereas a few very short tasks (due to handled exceptions, for example) will lead to gross underestimation of the ETA. I propose to use the median instead, which is statistically much more robust. If you're interested, I can look into making a pull request.

No newline after progressbar

from progressbar import ProgressBar
from time import sleep

prog = ProgressBar()

for i in prog(range(10)):
    sleep(0.1)

print('Hello World')

Output:

100% (10 of 10) |#############################| Elapsed Time: 0:00:01 Time: 1.00Hello World

Inverse FileTransferSpeed

For many slow-moving loops, the transfer speed would be something like .01 B/s or .00 B/s, which is highly uninformative. Is there a way you could show s/B for these cases? 175 s/B is much more descriptive and helpful. Also, do you have a workaround I could use for now? Because seeing .00 B/s doesn't tell me much about how fast I'm looping.

argparse not a valid dependency

When installing via pip install progressbar2, the argparse package is also installed. The only reference to argparse is in setup.py where it is used for install_requires.

I believe argparse can be safely removed from setup.py.

ProgressBar should work in 'with' block.

It would be useful to use the construct:

with progressbar.ProgressBar(maxval=10).start() as progress:
progress.update(1)

At the end of the 'with' block would finish automatically.

Progressbar dislikes empty iterables

Hey there,

I've had to pass in some empty iterables lately which causes progressbar to raise for having no start time. You can test this with list(progressbar.ProgressBar()([])).

I had a look into it and found the same issue raised on Google Code with a fix added later.

Do you think this could be added? =)

rST description not rendered on PyPI

I noticed that the PyPI package page has the rst readme in plain text. Using the readme package to check it, I found that the changelog markup in CHANGES.rst is causing the problems.

We could:

  1. Take the change log out of the package's long description. I prefer this, because the change log makes the PyPI page very long as more releases happen.
  2. Manually change the changelog and change directives back to plain rst. The Sphinx docs would presumably lose something from this.
  3. Have some code that tries to convert the rich rst into plain rst when setup.py runs. This would be fragile, and could easily get out of date.

Wrapper for stderr and stdout ?

Hopefully this is almost the last of my braindump-of-progressbar things :)

Functions that provided wrapped versions of stderr, stdout could be useful.

At the moment if you 'print' something while a progress bar is running, then you can get some parts of the PB left on screen.

A wrapper could detect output, + remove the progressbar from the screen, output anything normally, then draw the progress bar on the next line.

AdaptiveETA gives negative ETA

Thanks for a great package!

I've noticed that when using the AdaptiveETA widget and my download speed is not uniform you will get a negative ETA. It would be better if it just said 00:00.

Script for reproducing:

from progressbar import ProgressBar, AdaptiveETA
import time

pb = ProgressBar(widgets=[AdaptiveETA()], max_value=20)

for i in range(20):
    pb.update(i)
    time.sleep(0.1)
    if i < 10:
        time.sleep(0.5)
print("")

Output is:

ETA:  -1 day, 23:59:56

ETA causes crash in

The following code works with progressbar2==3.6.2,
however, when progressbar2==3.8.0 it breaks.

The download stops working after the first iteration. (the script just hangs)

I played with the code for hours, I thought it might have something to do with the uneven update sizes, but it doesn't. Interestingly AbsoluteETA does not cause a crash, but displays elapsed time instead of ETA.

I am using python 2.7.6 on Ubuntu 14.04

def default_pbar(max_value=None, prefix='     '):
    widgets = [
        prefix,
        progressbar.Bar('=', '[', ']'),
        #' ', Bar(marker=progressbar.RotatingMarker()),
        ' ', progressbar.Counter(), '/', `max_value`,
        ' ', '(', progressbar.Percentage(), ')',
        ' ', progressbar.FileTransferSpeed(),
        ' ', progressbar.ETA(),
        ' ',
    ]
    return progressbar.ProgressBar(widgets=widgets, max_value=max_value, redirect_stdout=True)

def retrieveFile(web_location, local_location):
    #progressbar update function
    def dlProgress(count, blockSize, totalSize):
        if pbar.max_value != totalSize:
            pbar.max_value = totalSize
        pbar.update(min(count*blockSize, totalSize))

    dl_size = int(urllib.urlopen(web_location).info().getheaders("Content-Length")[0])
    pbar =default_pbar(dl_size)
    pbar.start()
    urllib.urlretrieve(web_location, local_location, reporthook=dlProgress)
    pbar.finish()

retrieveFile('ftp://ftp.ncbi.nlm.nih.gov/pub/pmc/articles.A-B.tar.gz', 'articles.A-B.tar.gz')

redirect_stdout=True hangs IPython

Hey,
I'm on py 2.7 with progressbar 3.6.1. Example from documentation

import time
import progressbar

bar = progressbar.ProgressBar(redirect_stdout=True)
for i in range(100):
    print 'Some text', i
    time.sleep(0.1)
    bar.update(i)

works, but after finishing loop, I don't see IPython prompt (although interpreter itself works). Deleting bar object doesn't help.

edit:
What's better, using ProgressBar as context manager doesn't break IPython. Consider this

import time
import progressbar

with progressbar.ProgressBar(redirect_stdout=True) as bar:
    for i in range(20):
        print 'Some text', i
        time.sleep(0.1)
        bar.update(i)

make use of __iadd__

I sometimes do something like this:

bar = ProgressBar().start()
for _ in container:
    bar.update(bar.currval + 1)
    # ...
bar.finish()

It'd be neat if instead I could simply do:

bar += 1

If there's interest in this, I can submit a pull request.

NullBar ?

It would be useful to have a bar that does nothing at all.

Rational - I have a bunch of functions that can take a bar, and it would be nice to not have to check for None -

def myfunc(bar=Nullbar()):
    with bar:
         bar.update()

or

def myfunc(bar=None):
    bar = bar or Nullbar()
    with bar:
         bar.update()

redirect_stdout via ssh

The redirect_stdout feature does not seem to work when running the python script remotely,

ssh remote python test.py

The output is

Stored new task x<-data<-1_0<-analysis                                          
Stored new task y<-data<-1_0<-analysis
  2% ( 1 of 41) |                         | Elapsed Time: 0:00:00 ETA:  --:--:--Stored new task data<-1_0<-analysis
1_0<-analysis: dependency 'data' not sealed                                     
Stored new task x<-data<-2_0<-analysis
Stored new task y<-data<-2_0<-analysis
Stored new task data<-2_0<-analysis                                             
 14% ( 6 of 41) |###                       | Elapsed Time: 0:00:00 ETA:  0:00:002_0<-analysis: dependency 'data' not sealed
Stored new task y<-data<-2_1<-analysis                                          
 24% (10 of 41) |######                    | Elapsed Time: 0:00:00 ETA:  0:00:00Stored new task data<-2_1<-analysis
 26% (11 of 41) |######                    | Elapsed Time: 0:00:00 ETA:  0:00:002_1<-analysis: dependency 'data' not sealed
 26% (11 of 41) |######                    | Elapsed Time: 0:00:00 ETA:  0:00:00Stored new task x<-data<-3_0<-analysis
 29% (12 of 41) |#######                   | Elapsed Time: 0:00:00 ETA:  0:00:00Stored new task y<-data<-3_0<-analysis
 31% (13 of 41) |########                  | Elapsed Time: 0:00:00 ETA:  0:00:00Stored new task data<-3_0<-analysis
 34% (14 of 41) |########                  | Elapsed Time: 0:00:00 ETA:  0:00:003_0<-analysis: dependency 'data' not sealed
Stored new task y<-data<-3_1<-analysis                                          

Is it impossible to make it work this way? Some workarounds? Maybe some option that would enable to tell ProgresBar that it is being run remotely and would at least terminate the info with new lines?

math bugs with AdaptiveETA and AdaptiveTransferSpeed

I'm writing a script for file transfers, and I'm seeing some math related exceptions being thrown when using AdaptiveETA and AdaptiveTransferSpeed. After looking into the code, I think these are the problems:

  1. AdaptiveETA calculates items = sample_vals[-1] - sample_vals[0], and then tries to do division with this value per_item = duration / items. In my testing, items turns out to be 0, so the division fails since you can't do division by zero. Locally, I fixed the issue by doing this:

    if (items == 0):
      return ETA._eta(self, pbar)
    
  2. AdaptiveTransferSpeed calculates speed = items / duration, and then tries to do some math power = int(math.log(speed, 1000)). In my testing, printing out the value speed prints -0.0. Locally, I fixed the issue by doing this:

    if (speed <= 0):
      return FileTransferSpeed._speed(self, pbar)
    

Do these seem like reasonable solutions? If so, will these bugs be fixed sometime soon?

Simpler API to customize output?

I wanted to just change the fill character of the default ProgressBar behaviour (using █ instead of #), and found myself needing to override all the default_widgets.
Maybe I'm missing something, but what about some default widget that would behave like progress API, i.e. passing just a string that will be then formatted.
That would look like:

# Only change the the fill character:
bar = ProgressBar(fill="█")
# Change the whole line format:
bar = ProgressBar(fill="█", template='{percent} ({progress}/{total}) {bar} Elapsed Time: {elapsed} Eta: {eta}')

Using string.Formatter it may be straits forward instantiating only the needed widgets (this needs a map between format variables and widgets indeed).
One may eventually override some widget by doing something like:

# Override widget to use for "percent" variable substitution
mybar.register_widget('percent', MyCustomPercentWidget)
# Register a new variable
mybar.register_widget('foo', MyFooWidget)

Thoughts?

update() is slow

My colleague tried to replace old progressbar with progressbar2 in django-cities-light (see this branch https://github.com/greenday2/django-cities-light/commits/feature/progressbar2) and noticed that data import became much slower (~2 hours instead of ~20 minutes). This also results in one CPU core being busy with iTerm only (probably related to frequent terminal redrawing) We worked around this issue by introducing divisor variable and less frequent calls to update().

I think it is worth informing you about the fact that there is serious performance degradation in your fork, so you may want either to fix the cause, or to introduce some laziness in update(), for example update the progressbar only if input variable has changed enough to draw the next character. You can use our divisor trick (and probably replace 100 with utils.get_terminal_size())

dynamic customer message

Currently, only a single value is used as dynamic message, i.e., the iteration index. It would be helpful to include dynamic customer message in the progress bar.

For example,

bar = ProgressBar(widgets=[Percentage(), DynamicMessage('loss'), max_value=100)
for i in range(100):
  bar.update(i, loss=random.random())

Then the bar will output something like

9% ( 78 of 100) | loss = 0.55

Progress2 doesn't install in Python 3.2 (virtualenv)

I'm using ubuntu 12.04 with system wide python 2.7.x. I'm trying to create new virtualenv with python 3:

$ virtualenv --python=/usr/bin/python3 blabla
$ source blabla/bin/activate
(blabla) $ python --version
Python 3.2.3

When I'm try to install progressbar2 from PyPI, I've got error:

Downloading/unpacking progressbar2
  Downloading progressbar2-2.5.0.tar.gz
  Running setup.py egg_info for package progressbar2
    Traceback (most recent call last):
      File "progressbar/__init__.py", line 62, in <module>
        from cStringIO import StringIO
    ImportError: No module named cStringIO

    During handling of the above exception, another exception occurred:

    Traceback (most recent call last):
      File "<string>", line 14, in <module>
      File "/home/nopox/blabla/build/progressbar2/setup.py", line 5, in <module>
        import progressbar
      File "progressbar/__init__.py", line 64, in <module>
        from StringIO import StringIO
    ImportError: No module named StringIO
    Complete output from command python setup.py egg_info:
    Traceback (most recent call last):

  File "progressbar/__init__.py", line 62, in <module>

    from cStringIO import StringIO

ImportError: No module named cStringIO

When I change this (in blabla/build/progressbar2/progressbar/__init__.py) import from

from cStringIO import StringIO

to

from io import StringIO

I've got next error:

ImportError: No module named widgets

So I fix this import from

from widgets import *

to

from progressbar.widgets import *

And install has been successfully finished.

Can you fix it? :-) Your progressbar2 is preferable than progressbar because of stdout\stderr redirect feature.

Thanks

If nonzero min_value used, ProgressBar.start() fails

ProgressBar.start() always calls ProgressBar.update(0). When a ProgressBar is create with a nonzero min_value parameter, this call results in a ValueError exception due to 0 being outside the range of permissible values.

Setting maxval=progressbar.UnknownLength breaks most widgets

As far as I understand I am supposed to use maxval=progressbar.UnknownLength when I don't know the number of iterations.

It works when I initialize Progressbar like

progressbar.ProgressBar(
    widgets=[
        progressbar.BouncingBar(),
    ],
    maxval=progressbar.UnknownLength,
)

Using any other widget or even the default widgets

progressbar.ProgressBar(
    maxval=progressbar.UnknownLength,
)

will raise an exception

File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/__init__.py", line 365, in finish
  self.update(self.maxval)
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/__init__.py", line 321, in update
  self.fd.write('\r' + self._format_line())
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/__init__.py", line 267, in _format_line
  widgets = ''.join(self._format_widgets())
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/__init__.py", line 248, in _format_widgets
  widget = format_updatable(widget, self)
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/widgets.py", line 36, in format_updatable
  return updatable.update(pbar)
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/widgets.py", line 270, in update
  return '%3d%%' % pbar.percentage()
File "/Users/nwerner/Projekte/zget/lib/python2.7/site-packages/progressbar/__init__.py", line 234, in percentage
  return self.currval * 100.0 / (self.maxval or 1)
TypeError: unsupported operand type(s) for /: 'float' and 'classobj'

Progress bar is not plotting when progress is equal to 0

Considering the following code,

from progressbar import ProgressBar
import time

with ProgressBar(max_value=10) as pbar:
    for i in range(10):
        # long, loooong wait
        sleep(10000000)
        pbar.update(i)

Running that, it will take a long time for the process bar get printed. It does not print 0% progress, what is useful for iterations that requires long time to run.

I found the bug both on progressbar2==3.6.2 and git+https://github.com/WoLpH/python-progressbar.git@develop

Resume functionality

Heya,

Not as much an issue as a "do you have any thoughts on this?"

I recently used ProgressBar to indicate download status for a file (with requests streaming) and it works as advertised. However, when I do a resume, speed and (Adaptive)ETA are way off, since my first update takes it to the point where we're picking up again.

I was thinking of putting in support for resume in, and was just wondering if there were any ideas along those lines already.

I was thinking of implementing it with a resumeAt() function, and to put it on the widgets too, so that AdaptiveETA knows to wipe its history, for instance. And maybe someone will extend the Bar with a special character at the resume point, etc.

Thoughts?

Remove compat ?

Python 2.7 supports next() and any() if there is a future release it might be worth removing these..

ETA for unknown exactly size

I have «average» max value and can't use it directly, since progress bar will raise exception. But I like ETA and want something like normal progressbar before max_value and UnknownLength after. If this can be done right now by some checks and changing type of progress bar «on the fly» I will be just happy.

Allow ETA, AbsoluteETA, etc to change the string prefixes

AbsoluteETA currently prepends a long string "Estimated finish time: " before the date. The base Timer object allows the format kwarg to modify the text printed. AbsoluteETA and ETA should allow something similar, rather than hardcode the prefix string(s).

Version is wrong in __init__.py

In __init__.py, the __version__ variable is set to 2.7.3 instead of 3.4.1. See:

>>> import progressbar
>>> progressbar.__version__
'2.7.3'

I suspect this may be where the documentation is pulling its version number from, too, as the docs page is titled "Welcome to ProgressBar Version 2.7.3!"

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.