matplotlib limitations and design flaws

Dear matplotlib developers (and users):

I've expanded my web page "Python Limitations and Design Flaws" to include
a good-size section on matplotlib (item number 3). The URL is as follows:

http://phillipmfeldman.org/Python/Python_Limitations.html

All feedback other than flames is welcome!

Phillip
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160209/ad73d939/attachment.html>

Pull requests are welcome!

···

On Tue, Feb 9, 2016 at 10:22 PM, Phillip Feldman <phillip.m.feldman at gmail.com> wrote:

Dear matplotlib developers (and users):

I've expanded my web page "Python Limitations and Design Flaws" to include a
good-size section on matplotlib (item number 3). The URL is as follows:

http://phillipmfeldman.org/Python/Python_Limitations.html

All feedback other than flames is welcome!

Phillip

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Brian E. Granger
Associate Professor of Physics and Data Science
Cal Poly State University, San Luis Obispo
@ellisonbg on Twitter and GitHub
bgranger at calpoly.edu and ellisonbg at gmail.com

Dear matplotlib developers (and users):

I've expanded my web page "Python Limitations and Design Flaws" to
include a good-size section on matplotlib (item number 3). The URL is
as follows:

http://phillipmfeldman.org/Python/Python_Limitations.html

All feedback other than flames is welcome!

Regarding the polar plot, you are correct that there is an odd situation
where angles are input in radians and labeled in degrees, but I think
your description is incorrect. The inconsistency is entirely with the
azimuth. The radial labels are labeling the radial coordinate, which
has whatever dimensions are appropriate for the data at hand, unlike the
azimuth, which is dimensionless. The radial coordinate is correctly
labeled with the numbers you supplied.

Regarding the figure margin default: first, this presently applies only
to the figure on screen, not to figures written to a file; and second,
as soon as we get 2.0 out, the default will be for the margin to be
white in both cases.

Regarding the "Plot titles are by default jammed against...", I don't
think this is true for the full set of defaults, so I don't know what is
leading you to this conclusion; but a genuine weakness is that we lack a
layout engine, so tweaking of the sort you suggest is indeed needed all
too often.

Regarding the positional arguments to contour and contourf: yes, this is
an unfortunate result of the initial design of the pylab interface to be
close to Matlab, so as to make it easy for Matlab users to switch.

Regarding your first point, "lack of uniformity among the interfaces": I
think all of the developers would agree that this is a problem. It
arose from matplotlib's organic growth, and we are gradually trying to
address it.

Regarding your very first point, "Block Comments", I agree that it would
be nice to be able to use C-style /* and */, for example, but I find the
lack to be a very minor point. My workaround is to indent the block and
insert the line "if False:" above it.

Eric

···

On 2016/02/09 8:22 PM, Phillip Feldman wrote:

Phillip

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

If I feel the need to have a block comment, I have learned that that
usually means:
1) My logic is too complicated and needs to be cleaned up or broken up into
smaller chuncks
2) That the comment might be better as a docstring

And if I need to temporarily "comment out" a chunk of code, triple quoting
works great.

···

On Wed, Feb 10, 2016 at 2:29 AM, Eric Firing <efiring at hawaii.edu> wrote:

On 2016/02/09 8:22 PM, Phillip Feldman wrote:

Dear matplotlib developers (and users):

I've expanded my web page "Python Limitations and Design Flaws" to
include a good-size section on matplotlib (item number 3). The URL is
as follows:

http://phillipmfeldman.org/Python/Python_Limitations.html

All feedback other than flames is welcome!

Regarding the polar plot, you are correct that there is an odd situation
where angles are input in radians and labeled in degrees, but I think your
description is incorrect. The inconsistency is entirely with the azimuth.
The radial labels are labeling the radial coordinate, which has whatever
dimensions are appropriate for the data at hand, unlike the azimuth, which
is dimensionless. The radial coordinate is correctly labeled with the
numbers you supplied.

Regarding the figure margin default: first, this presently applies only to
the figure on screen, not to figures written to a file; and second, as soon
as we get 2.0 out, the default will be for the margin to be white in both
cases.

Regarding the "Plot titles are by default jammed against...", I don't
think this is true for the full set of defaults, so I don't know what is
leading you to this conclusion; but a genuine weakness is that we lack a
layout engine, so tweaking of the sort you suggest is indeed needed all too
often.

Regarding the positional arguments to contour and contourf: yes, this is
an unfortunate result of the initial design of the pylab interface to be
close to Matlab, so as to make it easy for Matlab users to switch.

Regarding your first point, "lack of uniformity among the interfaces": I
think all of the developers would agree that this is a problem. It arose
from matplotlib's organic growth, and we are gradually trying to address it.

Regarding your very first point, "Block Comments", I agree that it would
be nice to be able to use C-style /* and */, for example, but I find the
lack to be a very minor point. My workaround is to indent the block and
insert the line "if False:" above it.

Eric

Phillip

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160210/6e597e26/attachment-0001.html>

To add to that, thanks to modern text editors, languages don't need block
comments any more. Ctrl + / should comment out a chunk of text on most
editors that I've used (Save for e.g., vim).

-p
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160210/f02da0e0/attachment.html>

···

On Wed, Feb 10, 2016 at 7:09 AM, Benjamin Root <ben.v.root at gmail.com> wrote:

If I feel the need to have a block comment, I have learned that that
usually means:
1) My logic is too complicated and needs to be cleaned up or broken up
into smaller chuncks
2) That the comment might be better as a docstring

And if I need to temporarily "comment out" a chunk of code, triple quoting
works great.

Ctrl + / should comment out a chunk of text on most editors that I've
used (Save for e.g., vim).

And it's pretty trivial to set up in vim (note that you'd tupically
customize comment marker on a per-language basis through an autocmd
function). This maps commenting out a block to "-" and uncommenting to "_":

" Clear all comment markers (one rule for all languages)
map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//<CR>:nohlsearch<CR>
"Insert comment markers (assumes # unless overridden)
map - :s/^/#/<CR>:nohlsearch<CR>

There are also smarter options through various plugins, as well.

At any rate, block commenting isn't something I've ever missed or felt was
a limitation in any way, though that's just my $0.02.

Cheers,
-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160210/9f324905/attachment.html>

A point in favor of not using block comments is that it is *much* harder to
exclude block commented code from greps/regex. If you comment every line,
that makes excluding those lines trivial.

Ryan

···

On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington <joferkington at gmail.com> wrote:

Ctrl + / should comment out a chunk of text on most editors that I've

used (Save for e.g., vim).

And it's pretty trivial to set up in vim (note that you'd tupically
customize comment marker on a per-language basis through an autocmd
function). This maps commenting out a block to "-" and uncommenting to "_":

" Clear all comment markers (one rule for all languages)
map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//<CR>:nohlsearch<CR>
"Insert comment markers (assumes # unless overridden)
map - :s/^/#/<CR>:nohlsearch<CR>

There are also smarter options through various plugins, as well.

At any rate, block commenting isn't something I've ever missed or felt was
a limitation in any way, though that's just my $0.02.

Cheers,
-Joe

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160210/d8dc9c38/attachment.html>

I will correct my discussion of the polar plot example.

I'll add something to the discussion of block comments. Re. Ryan's point
that it is hard to exclude block commented code from greps/regex: This is
equally true of doc strings, and no one is suggesting that we stop using
these.

Is there any plan to incorporate a layout engine into matplotlib?

Phillip

P.S. I want to thank everyone for the thoughtful responses.

···

On Wed, Feb 10, 2016 at 9:12 AM, Ryan May <rmay31 at gmail.com> wrote:

A point in favor of not using block comments is that it is *much* harder
to exclude block commented code from greps/regex. If you comment every
line, that makes excluding those lines trivial.

Ryan

On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington <joferkington at gmail.com> > wrote:

Ctrl + / should comment out a chunk of text on most editors that I've

used (Save for e.g., vim).

And it's pretty trivial to set up in vim (note that you'd tupically
customize comment marker on a per-language basis through an autocmd
function). This maps commenting out a block to "-" and uncommenting to "_":

" Clear all comment markers (one rule for all languages)
map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//<CR>:nohlsearch<CR>
"Insert comment markers (assumes # unless overridden)
map - :s/^/#/<CR>:nohlsearch<CR>

There are also smarter options through various plugins, as well.

At any rate, block commenting isn't something I've ever missed or felt
was a limitation in any way, though that's just my $0.02.

Cheers,
-Joe

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160214/5e02e7d2/attachment.html>

See https://github.com/matplotlib/matplotlib/issues/1109

The consensus seems to be that we should use
https://github.com/nucleic/kiwi for
solving the linear constraint problem, someone just needs to sort out how
to automatically generate the constraint equations from a `Figure` object.
The sticking points are going to be dealing with text (which will require a
(partial?) 2-pass approach) and how what the user-facing API for tuning the
constraints will be.

This might be a good GSoC project?

Tom

···

On Mon, Feb 15, 2016 at 2:20 AM Phillip Feldman <phillip.m.feldman at gmail.com> wrote:

I will correct my discussion of the polar plot example.

I'll add something to the discussion of block comments. Re. Ryan's point
that it is hard to exclude block commented code from greps/regex: This is
equally true of doc strings, and no one is suggesting that we stop using
these.

Is there any plan to incorporate a layout engine into matplotlib?

Phillip

P.S. I want to thank everyone for the thoughtful responses.

On Wed, Feb 10, 2016 at 9:12 AM, Ryan May <rmay31 at gmail.com> wrote:

A point in favor of not using block comments is that it is *much* harder
to exclude block commented code from greps/regex. If you comment every
line, that makes excluding those lines trivial.

Ryan

On Wed, Feb 10, 2016 at 9:41 AM, Joe Kington <joferkington at gmail.com> >> wrote:

Ctrl + / should comment out a chunk of text on most editors that I've

used (Save for e.g., vim).

And it's pretty trivial to set up in vim (note that you'd tupically
customize comment marker on a per-language basis through an autocmd
function). This maps commenting out a block to "-" and uncommenting to "_":

" Clear all comment markers (one rule for all languages)
map _ :s/^\/\/\\|^--\\|^> \\|^[#"%!;]//<CR>:nohlsearch<CR>
"Insert comment markers (assumes # unless overridden)
map - :s/^/#/<CR>:nohlsearch<CR>

There are also smarter options through various plugins, as well.

At any rate, block commenting isn't something I've ever missed or felt
was a limitation in any way, though that's just my $0.02.

Cheers,
-Joe

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Ryan May

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160215/254dd933/attachment-0001.html>

I was only debunking your own specific point about block comments: "A
consequence is that there is no good mechanism for temporarily deactivating
a large block of code?one must either laboriously comment out each line, or
simply delete the block."

So for commenting out blocks of code, block comments suck because using
block comments means there's no way to exclude the "temporarily" disabled
code. It's generally much less often that I'm frustrated by my ability to
exclude lines from docstrings in a grep.

Given that even Gedit has a plugin for mass commenting lines, I see no
problem with the lack of block comments. In fact, when I'm doing C++, I
exclusively use the single line '//' rather than the C style '/* */'. So
for me, lack of block comments is a *feature* of Python (since you don't
end up with two ways to do comments, either). To each their own style...but
comments are really one of your 10 biggest gripes about Python? REALLY?

Ryan

···

On Mon, Feb 15, 2016 at 12:19 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote:

I'll add something to the discussion of block comments. Re. Ryan's point
that it is hard to exclude block commented code from greps/regex: This is
equally true of doc strings, and no one is suggesting that we stop using
these.

--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160215/5b5ed761/attachment.html>

Benjamin Root <ben.v.root at gmail.com> writes:

And if I need to temporarily "comment out" a chunk of code, triple quoting
works great.

You can also insert an "if 0:" indented between your normal indentation
levels, and end the block with "if 1:" unless you wanted to comment out
to the end of the natural block.

···

--
Jouni K. Sepp?nen
http://www.iki.fi/jks

OK. "if 0:" is a reasonable solution. I will remove the block comment
issue.

···

On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:

Benjamin Root <ben.v.root at gmail.com> writes:

> And if I need to temporarily "comment out" a chunk of code, triple
quoting
> works great.

You can also insert an "if 0:" indented between your normal indentation
levels, and end the block with "if 1:" unless you wanted to comment out
to the end of the natural block.

--
Jouni K. Sepp?nen
http://www.iki.fi/jks

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160216/0eec1783/attachment.html>

The downside of "if 0:" is that no editor will syntax color this as a
comment.

···

On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote:

OK. "if 0:" is a reasonable solution. I will remove the block comment
issue.

On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:

Benjamin Root <ben.v.root at gmail.com> writes:

> And if I need to temporarily "comment out" a chunk of code, triple
quoting
> works great.

You can also insert an "if 0:" indented between your normal indentation
levels, and end the block with "if 1:" unless you wanted to comment out
to the end of the natural block.

--
Jouni K. Sepp?nen
http://www.iki.fi/jks

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160216/07ac853c/attachment.html>

All the more reason why I utilize triple quoting for "commenting out
blocks". It may not be syntax-colored for comments, but it is colored
obviously differently than code.

Another reason not to like /* ... */ for commenting out blocks of code.
That is often used for multi-line comments anyway. So, if you have
multi-line comments in the code block that you need to comment out, then
just doing /* ... */ around that isn't trivial. At least with triple
quoting, I can alternate between triple double-quotes and triple
single-quotes.

···

On Tue, Feb 16, 2016 at 11:48 AM, Phillip Feldman < phillip.m.feldman at gmail.com> wrote:

The downside of "if 0:" is that no editor will syntax color this as a
comment.

On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < > phillip.m.feldman at gmail.com> wrote:

OK. "if 0:" is a reasonable solution. I will remove the block comment
issue.

On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:

Benjamin Root <ben.v.root at gmail.com> writes:

> And if I need to temporarily "comment out" a chunk of code, triple
quoting
> works great.

You can also insert an "if 0:" indented between your normal indentation
levels, and end the block with "if 1:" unless you wanted to comment out
to the end of the natural block.

--
Jouni K. Sepp?nen
http://www.iki.fi/jks

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160216/e4573ef0/attachment.html>

The plus side of `if 0:` is that when it ends up committed to your code
base (it shouldn't, but it happens), you can at least be sure that no
syntax errors creep in.

Ryan

···

On Tue, Feb 16, 2016 at 9:53 AM, Benjamin Root <ben.v.root at gmail.com> wrote:

All the more reason why I utilize triple quoting for "commenting out
blocks". It may not be syntax-colored for comments, but it is colored
obviously differently than code.

Another reason not to like /* ... */ for commenting out blocks of code.
That is often used for multi-line comments anyway. So, if you have
multi-line comments in the code block that you need to comment out, then
just doing /* ... */ around that isn't trivial. At least with triple
quoting, I can alternate between triple double-quotes and triple
single-quotes.

On Tue, Feb 16, 2016 at 11:48 AM, Phillip Feldman < > phillip.m.feldman at gmail.com> wrote:

The downside of "if 0:" is that no editor will syntax color this as a
comment.

On Tue, Feb 16, 2016 at 7:57 AM, Phillip Feldman < >> phillip.m.feldman at gmail.com> wrote:

OK. "if 0:" is a reasonable solution. I will remove the block comment
issue.

On Tue, Feb 16, 2016 at 3:20 AM, Jouni K. Sepp?nen <jks at iki.fi> wrote:

Benjamin Root <ben.v.root at gmail.com> writes:

> And if I need to temporarily "comment out" a chunk of code, triple
quoting
> works great.

You can also insert an "if 0:" indented between your normal indentation
levels, and end the block with "if 1:" unless you wanted to comment out
to the end of the natural block.

--
Jouni K. Sepp?nen
http://www.iki.fi/jks

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel at python.org
https://mail.python.org/mailman/listinfo/matplotlib-devel

--
Ryan May
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/matplotlib-devel/attachments/20160216/d3adef15/attachment.html>