v1.4.1rc1 delayed :(

Hello all,

We are going to miss the deadline on 1.4.1 as there is 2-3 blocker issues:

  - #3470 / PR#3564 which started as issues with the macosx backend
and spiralled into discovering that we were only validating input to
rcparams about half of the time.

- #3505 The changes to disable interactive mode when not at a repl.
It turns out a lot of people use it and we should un-break them.

- #3517 which is related to non-ascii paths in font look up which
causes matplotlib to blow up on import.

I am open to arguments that any of these should not be blockers.

Tom

···

--
Thomas Caswell
tcaswell@...149...

Thanks for working on all of these. I just discovered another issue that really should be a blocker:

Mike

···

On 10/01/2014 11:58 PM, Thomas Caswell wrote:

Hello all,

We are going to miss the deadline on 1.4.1 as there is 2-3 blocker issues:

   - #3470 / PR#3564 which started as issues with the macosx backend
and spiralled into discovering that we were only validating input to
rcparams about half of the time.

  - #3505 The changes to disable interactive mode when not at a repl.
It turns out a lot of people use it and we should un-break them.

  - #3517 which is related to non-ascii paths in font look up which
causes matplotlib to blow up on import.

I am open to arguments that any of these should not be blockers.

Tom

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute

I'm not sure what to do about matplotlib.__version__ is now unicode as of 1.4.0 by mdboom · Pull Request #3621 · matplotlib/matplotlib · GitHub either. In general, I think it is best to have strings like this left in their native mode, not coerced to unicode, but that is contrary to the strategy decided upon when "from __future__ import unicode_literals" was adopted.

Mike, what do you think--are other projects going to run into this problem, triggered by a bug in LooseVersion?

Eric

···

On 2014/10/07, 11:03 AM, Michael Droettboom wrote:

Thanks for working on all of these. I just discovered another issue
that really should be a blocker:

setup.py creates a zombie C extension called "freetype2" by mdboom · Pull Request #3622 · matplotlib/matplotlib · GitHub

Mike

On 10/01/2014 11:58 PM, Thomas Caswell wrote:

Hello all,

We are going to miss the deadline on 1.4.1 as there is 2-3 blocker issues:

    - #3470 / PR#3564 which started as issues with the macosx backend
and spiralled into discovering that we were only validating input to
rcparams about half of the time.

   - #3505 The changes to disable interactive mode when not at a repl.
It turns out a lot of people use it and we should un-break them.

   - #3517 which is related to non-ascii paths in font look up which
causes matplotlib to blow up on import.

I am open to arguments that any of these should not be blockers.

Tom

I'm not sure what to do about
matplotlib.__version__ is now unicode as of 1.4.0 by mdboom · Pull Request #3621 · matplotlib/matplotlib · GitHub either. In
general, I think it is best to have strings like this left in their
native mode, not coerced to unicode, but that is contrary to the
strategy decided upon when "from __future__ import unicode_literals" was
adopted.

I think it has a pretty easy fix -- just put `str()` around the version string. That will go back to bytes on 2.x and unicode on 3.x.

Mike, what do you think--are other projects going to run into this
problem, triggered by a bug in LooseVersion?

It's an unfortunate bug, but fortunately has a reasonable workaround.

I think there are certain areas of matplotlib where the benefit of using `unicode_literals` outweighs the pain -- particularly in the text and math text handling, the PDF and SVG backends, and anything to do with fonts. It's actually fixed a lot of bugs for us. But, yes, there are the occasional dark corners in Python 2 like this.

Mike

···

On 10/07/2014 05:13 PM, Eric Firing wrote:

Eric

On 2014/10/07, 11:03 AM, Michael Droettboom wrote:

Thanks for working on all of these. I just discovered another issue
that really should be a blocker:

setup.py creates a zombie C extension called "freetype2" by mdboom · Pull Request #3622 · matplotlib/matplotlib · GitHub

Mike

On 10/01/2014 11:58 PM, Thomas Caswell wrote:

Hello all,

We are going to miss the deadline on 1.4.1 as there is 2-3 blocker issues:

     - #3470 / PR#3564 which started as issues with the macosx backend
and spiralled into discovering that we were only validating input to
rcparams about half of the time.

    - #3505 The changes to disable interactive mode when not at a repl.
It turns out a lot of people use it and we should un-break them.

    - #3517 which is related to non-ascii paths in font look up which
causes matplotlib to blow up on import.

I am open to arguments that any of these should not be blockers.

Tom

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk
_______________________________________________
Matplotlib-devel mailing list
Matplotlib-devel@lists.sourceforge.net
matplotlib-devel List Signup and Options

--
Michael Droettboom
Science Software Branch
Space Telescope Science Institute