indef draw_artist(self, a) there is an otherassert: isa going to be available only afterdraw has been draw, or the user could call the method beforedraw? If the case is the latter, then I'll move it to exception.

I like this post about assertions:

https://mail.python.org/pipermail/python-list/2013-November/660401.html

I wouldn't go hog-wild in converting the asserts into exceptions, but
perhaps we could see what sort of asserts can be converted (and
vice-versa). I don't have a particular opinion about this one yet.

Thanks for the link, I'll read it more carefully tomorrow. I agree about not going wild. Anyway these two points at the end

• Never use them for testing user-supplied data, or for anything
  where the check must take place under all circumstances.Don't use them for checking input arguments to public library
• functions (private ones are okay) since you don't control the
  caller and can't guarantee that it will never break the
  function's contract.

convinced me even more that my PR make sense

Indeed. To highlight two particular paragraphs that I find illuminating:

Opinions on assertions vary, because they can be a statement ofconfidence about the correctness of the code. If you're certain that thecode is correct, then assertions are pointless, since they will neverfail and you can safely remove them. If you're certain the checks canfail (e.g. when testing input data provided by the user), then you darenot use assert since it may be compiled away and then your checks will beskipped.It's the situations in between those two that are interesting, times whenyou're certain the code is correct but not *quite* absolutely certain.Perhaps you've missed some odd corner case (we're all only human). Inthis case an extra runtime check helps reassure you that any errors willbe caught as early as possible rather than in distant parts of the code.

On Tue, May 13, 2014 at 5:07 PM, Francesco Montesano <
notifications@github.com> wrote:

Thanks for the link, I'll read it more carefully tomorrow. I agree about
not going wild. Anyway these two points at the end

• Never use them for testing user-supplied data, or for anything where
  the check must take place under all circumstances.Don't use them for
  checking input arguments to public library

• functions (private ones are okay) since you don't control the caller
  and can't guarantee that it will never break the function's contract.

  convinced me even more that my PR make sense

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/3060#issuecomment-43013027
.

I don't really want to do this for 1.4.0, labeled for 1.4.x

I'll try to get back with further commits later this week or next one.

Before I embark myself intolib/matplotlib/backends (in the various modules in the directory there are 33assert).
Are the modules in there supposed to be used by users (in which case most or all theassert should be changed) or should be considered as internals (in which case theassert are fine)?

ps: before anyone asks or complain. I'm going to run the test suite and adjust it if needed once I'm done with removing the asserts

I would avoid touching the backends just yet, they are on my list of things to re-factor as soon as 1.4 gets out (see#2624 ).

I've left alone a few asserts on private functions after checking that no user input is directly passed to them.
I've also left alone at least one indocstring.py assuming that are not used interactively or dynamically.

this line looks like a but to me. Shouldn't it bedt2 = r2.dtype[name]?

If it's a bug, I'll fix it here

Besides: I didn't dare to touchlib/matplotlib/mathtext.py

Please make a separate PR for that bug.

Also, I think that entire block of functions are candidates to be removed from the library. I have never looked at them before, but scanning them they look like they are replicating much of the functionality thatpandas provides.

@tacaswell: I'll do a separate PR.

I'm waiting Travis answer in case I need to fix any problem.

And I have a question about testing.
Here it's written

run the script tests.py in the root directory of the distribution
On my system if I do this, it imports the installed version (as probably should be?)

If Icd build/lib.linux-x86_64-2.7 and try to runtest.py, it loads the rightmatplotlib, but it fails at a certain point when it tries to use amock (ormocks) module.
I guess that what's written above works if matplotlib is built with

python setup.py develop

It is correct?

I've installed matplotlib asdevelop and runpython tests.py. After fixing some bug I've introduced (my bad), I get a large number of warnings and :

FAILED (KNOWNFAIL=365, errors=1, failures=3)

The failing tests are:

• ERROR: matplotlib.tests.test_backend_pgf.test_rcupdate
  with

  [...]File "/.../matplotlib/lib/matplotlib/backends/backend_pgf.py", line 318, in __init__raise LatexError("LaTeX returned an error, probably missing font or error in preamble:\n%s" % stdout)LatexError: LaTeX returned an error, probably missing font or error in preamble:This is pdfTeX, Version 3.1415926-2.5-1.40.14 (TeX Live 2013/TeX Live for SUSE Linux)restricted \write18 enabled.

• FAIL: matplotlib.tests.test_coding_standards.test_pep8_conformance
  I can fix it, but in a different PR

• FAIL: matplotlib.tests.test_text.test_font_styles.test with

  ImageComparisonFailure: images not close:    /.../matplotlib/result_images/test_text/font_styles.png vs. /.../matplotlib/result_images/test_text/font_styles-expected.png (RMS 13.672)

• FAIL: matplotlib.tests.test_text.test_font_styles.test with

  ImageComparisonFailure: images not close: /.../matplotlib/result_images/test_text/font_styles_pdf.png vs. /.../matplotlib/result_images/test_text/font_styles-expected_pdf.png (RMS 14.065)

Now I runpython3 tests and update here. Then I'll push the corrected version.

With python3 I get three extra errors:

• ERROR: Failure: AttributeError ('module' object has no attribute 'test_dates')
• ERROR: Failure: AttributeError ('module' object has no attribute 'test_legend')
• ERROR: Failure: AttributeError ('module' object has no attribute 'test_patheffects')

The traceback is always the same (except for the actual attribute name)

Traceback (most recent call last):  File "/home/susefra/.local/lib/python3.3/site-packages/nose/failure.py", line 39, in runTest    raise self.exc_val.with_traceback(self.tb)  File "/home/susefra/.local/lib/python3.3/site-packages/nose/loader.py", line 403, in loadTestsFromName    module = resolve_name(addr.module)  File "/home/susefra/.local/lib/python3.3/site-packages/nose/util.py", line 321, in resolve_name    obj = getattr(obj, part)AttributeError: 'module' object has no attribute 'test_patheffects'

At a minimum this needs a re-base.

@pelson@mdboom@efiring Thoughts? I think I am in favor of switching asserts in public facing function into exceptions so we can provide more meaningful error messages/make sane error handling possible. I think private functions should keep using assert as they can in principle be suppressed for efficiency reasons.

@tacaswell: I agree with that assert vs. exception policy.@montefra: Sorry this has sat here so long. It would be nice to rebase this so we can merge.

@tacaswell: Yes, I agree also.

At the moment I'm travelling, so I don't know when I'll do it. For sure I can rebase, test and commit within a week and a half. Is there any hurry?

@montefra I left you a bunch of style-related comment and a few places where I was confused by the logic.

Thank you for doing this!

@tacaswell it seems that we now agree 👍

Should I rebase?

This is getting really close! Just a few minor issues (one class of 2.6 compatibility one class of style consistency).

Thank you so much for working on this!

Please @ ping me when this is updated.

@tacaswell: on top of your comments, I went through all my modifications to make the whole thing more consistent.

ps: I've found a few more"{}".format(..) around mpl, so they should fail on python 2.6. I'll do a new PR to fix them.

Awesome.

A PR to clean up the format calls else where would be appreciated.