Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Pylab function show() accepts any arguments #1712

Closed
misolietavec opened this issue Jan 28, 2013 · 5 comments
Closed

Pylab function show() accepts any arguments #1712

misolietavec opened this issue Jan 28, 2013 · 5 comments

Comments

@misolietavec
Copy link

For example (at ordinary Python shell):

from pylab import plot, show
from numpy import linspace
x=linspace(0,10,100)
y=x*x
plot(x,y)
show(linspace)

and for such nonsense no error message appears...
(according to documentation, show should accept only one experimental keyword, block)

This behaviour is observed in Matplotlib 1.1.0 (Debian testing package) and also in version 1.2 (compiled in virtualenv).

@efiring
Copy link
Member

efiring commented Jan 28, 2013

True, but mpl has never had a policy of strict argument validation. The advantage of strict validation is that it can catch programming errors early; the disadvantage is that it adds a lot of code that must be tested and maintained, and that provides no core functionality. I think there are places where adding or improving argument validation would be worth the extra code, but show() is not one of them.

I'm inclined to close this as "won't fix", but I will leave it open for discussion for a short while.

@misolietavec
Copy link
Author

On 28.1.2013 19:49, Eric Firing wrote:

True, but mpl has never had a policy of strict argument validation. The
advantage of strict validation is that it can catch programming errors
early; the disadvantage is that it adds a lot of code that must be
tested
and maintained, and that provides no core functionality. I think there
are places where adding or improving argument validation would be worth
the extra code, but show() is not one of them.

It was real case of my colleague (non-programmer), to write show(G)
after he created some graph G in Networkx and made some drawing...
He was wondering, why he cannot continue in pylab interactive work,
after running the file with abovementioned commands.

The current behaviour of show() is such:

show() is OK, works as described in documentation
show(par) with anything, evaluated to True causes interactive mode to be
blocked

(in case of my colleague, after closing the figure, there was another
blank figure to close...)

I'm inclined to close this as "won't fix", but I will leave it open for
discussion for a short while.

I think, the show() function is used mainly by "ordinary" users, which are
accustomed
to Matlab-like graphics. So there should be no surprises, calling it. My
proposal is,
either to disable that single argument, or make it the keyword argument
named "block",
not accepting anything else.

@WeatherGod
Copy link
Member

On Tue, Jan 29, 2013 at 8:37 AM, misolietavec notifications@github.comwrote:

On 28.1.2013 19:49, Eric Firing wrote:

True, but mpl has never had a policy of strict argument validation. The
advantage of strict validation is that it can catch programming errors
early; the disadvantage is that it adds a lot of code that must be
tested
and maintained, and that provides no core functionality. I think there
are places where adding or improving argument validation would be worth
the extra code, but show() is not one of them.

It was real case of my colleague (non-programmer), to write show(G)
after he created some graph G in Networkx and made some drawing...
He was wondering, why he cannot continue in pylab interactive work,
after running the file with abovementioned commands.

The current behaviour of show() is such:

show() is OK, works as described in documentation
show(par) with anything, evaluated to True causes interactive mode to be
blocked

(in case of my colleague, after closing the figure, there was another
blank figure to close...)

I'm inclined to close this as "won't fix", but I will leave it open for
discussion for a short while.

I think, the show() function is used mainly by "ordinary" users, which are
accustomed
to Matlab-like graphics. So there should be no surprises, calling it. My
proposal is,
either to disable that single argument, or make it the keyword argument
named "block",
not accepting anything else.

Most likely, the code goes:

if block:
    foobar()

There really isn't much that could be done here (except possibly deprecate
that argument and move towards having show() accept no arguments).

@efiring
Copy link
Member

efiring commented Jan 30, 2013

On 2013/01/29 8:50 AM, Benjamin Root wrote:

On Tue, Jan 29, 2013 at 8:37 AM, misolietavec
notifications@github.comwrote:

On 28.1.2013 19:49, Eric Firing wrote:

True, but mpl has never had a policy of strict argument validation. The
advantage of strict validation is that it can catch programming errors
early; the disadvantage is that it adds a lot of code that must be
tested
and maintained, and that provides no core functionality. I think there
are places where adding or improving argument validation would be worth
the extra code, but show() is not one of them.

It was real case of my colleague (non-programmer), to write show(G)
after he created some graph G in Networkx and made some drawing...
He was wondering, why he cannot continue in pylab interactive work,
after running the file with abovementioned commands.

The current behaviour of show() is such:

show() is OK, works as described in documentation
show(par) with anything, evaluated to True causes interactive mode to be
blocked

(in case of my colleague, after closing the figure, there was another
blank figure to close...)

I'm inclined to close this as "won't fix", but I will leave it open for
discussion for a short while.

I think, the show() function is used mainly by "ordinary" users,
which are
accustomed
to Matlab-like graphics. So there should be no surprises, calling it. My
proposal is,
either to disable that single argument, or make it the keyword argument
named "block",
not accepting anything else.

Most likely, the code goes:

if block:
foobar()

There really isn't much that could be done here (except possibly deprecate
that argument and move towards having show() accept no arguments).

But it turns out that the argument can be quite useful, so I am more
inclined to take off the "experimental" tag than to remove the argument.

Eric


Reply to this email directly or view it on GitHub
#1712 (comment).

@tacaswell
Copy link
Member

Closing as 'wontfix'

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants