Inconsistent behaviour of float vs. str valued linewidth kwarg when saving plots as ps or eps.

[kirnis]

There is a minor discrepancy in the behaviour of the linewidth kwarg between producing plots in the pyplot window and saving these plots into a file. According to the matplotlib documentation this kwarg accepts a float value. But I noticed that you can also give the value as a string and the plot works just fine. In other words, both of

plot(x,y,linewidth=1.5) and
plot(x,y,linewidth='1.5')

work and produce identical line plots of y vs. x. However, if the latter option of string valued linewidth is used, it is not possible to save the plot into ps or eps files. Instead the pyplot window gives the error message

"float argument required, not str"

without indicating where exactly the error occurred. This is inconsistent behaviour. You should either be able to use string valued linewidth kwargs when saving plots into ps or eps files or using the string values should be entirely forbidden here.

[tacaswell]

It is more surprising that it works with the other backends.

Why are you passing in linewidth as a string? I don't the documentation claims anywhere that passing strings should work....

[kirnis]

I was also surprised about the behaviour. The discovery came from having passed plot symbols and colours as strings and being too lazy to check the documentation for the correct way to pass linewidth. Since the string values for linewidth kind of worked at first I didn't notice my error till trying to save the plots. In some other case there might have been a delay of months before having the need to produce the plots into files and noticing that something had gone wrong.

I was left hoping that the unsupported string values of linewidth would be made to result in an error earlier on so that this kind of lazy programming wouldn't bite others.

[OceanWolf]

Why don't we do it the other way around, just do foo = float(foo) or something if needed, it feels more pythonic that way, quack-quack.

[efiring]

@OceanWolf are you suggesting that a string should be accepted? I don't agree. Things that fundamentally are numbers should be supplied as numbers. A string doesn't quack like a number. Accepting a string here seems, to me, more perlish than pythonic.

[OceanWolf]

@efiring I did mean to suggest that, yes, float('3.3') == float(3.3), so in that sense they quack the same, on the otherhand float('foo') raises a ValueError: could not convert string to float: foo, which seems like a good enough error message to me.

I don't really mind either way, whatever you decide.

[tacaswell]

@kirnis We have patched this to work, but please change your code to pass in floats!