This is only used to generate a file prefix if the caller hasn't provided one. We could just insist that the caller provide one and remove the need to use uuid.

Or just use an index; increment by 1 until file doesn't exist... so you get <tag>0.png, <tag>1.png, etc... probably easier on the eye than <tag><30 character hex string>.png or whatever

But have to say, not quite sure what the context in which you are writing is (this is a temp file stored somewhere? or this is a file user wants to read?)

These are files users will want to read e.g. files with histograms.

I'll just add the integer index. The user can override it if they want via a configuration parameter.

If I was being really picky, I would ask you to prepend the index by 0s like 0001, 0002, ..., 0021, ... so that "ls" sorts the files in the right order...

No, I'm not thinking, sorry. OutputPyImage doesn't need to increment/maintain a counter. At present the UUID is created in birth if the user hasn't explicitly provided a file name prefix. This prefix is shared by all files created by this worker. The JSON documents provided as input determine the rest of the file name - and it's up to whatever creates those (e.g. ReducePyMatplotlibHistogram) to ensure any numbering scheme is applied. So,

I'll

• Just adopt a default string instead of the UUID. The user should configure it if they don't want this default (possibly, by creating their own UUID).
• Update ReducePyMatplotlibHistogram to auto-number as suggested.

Updated OutputPyImage.py to not use UUID - 669.

Update ReducePyMatplotlibHistogram to zero-pad auto-numbers - 670

I merged 670 into the trunk... (had someone else with the same problem)

But let me know if you are happy to close the issue or have a few more tweaks to make...

Happy to close, thanks.

FYI: for future reference, run number and spill number should be unique.

FYI: this is fixed in python 2.7.2