[SciPy-User] Pylab - standard packages

Ralf Gommers ralf.gommers@gmail....
Sat Sep 22 16:43:38 CDT 2012


On Sat, Sep 22, 2012 at 8:10 PM, Fernando Perez <fperez.net@gmail.com>wrote:

> On Sat, Sep 22, 2012 at 6:46 AM, Ralf Gommers <ralf.gommers@gmail.com>
> wrote:
> > I think you have forwards and backwards compatible the wrong way around.
> > Forwards compatible would be that you can open version 4 files, if that's
> > introduced in IPython 0.14 or later, in 0.13. In my opinion you need
> either
> > forward compatibility or by default keep saving in version 3 even after
> you
> > have version 4, if you want to make the format a standard.
>
> The format has now two numbers, major and minor.  Right now we're at
> 3.0. The idea is that small, forward-compatible changes will only
> increment the minor number.  It may be that a feature is added that is
> only understood for certain functionality in version 3.1, but a 3.0
> IPython would be able to read, use and save 3.1 notebooks without any
> *data loss*.
>
> Only if there is a change that makes it impossible to really
> understand the notebooks themselves by an older version of the code
> (say because something in the JSON layout changes) would the major
> number be bumped.  That's what happened when we went from v2 to v3.
>
> Now, I don't know if I'm misunderstanding your comment above that we
> have to keep saving in v3 forever if we want the notebook in the spec.
> If you really mean that, then we absolutely *don't* want ipython in
> the spec, ever.  Because we can't commit to never in the future
> evolving the format.


Forever is obviously too long:) Thomas' suggestion of a transition period
makes sense. And I'm glad to hear you are confident that you won't have to
make any changes for the foreseeable future.


> But by that token, then we'd say that the api for
> numpy, or matplotlib, or scipy, can never ever change in a
> backwards-incompatible manner if they are to go into the spec.  So
> will we not put numpy in the spec because in-place operations in the
> current 1.7 betas break code that was valid up until now?
>

That's absolutely the wrong comparison. The impact would be more like
breaking the numpy ABI, or not being able to load .py files made in fancy
editor X in my plain old vim. Or for a proprietary example, moving from
.doc to .docx in MS Word.


> So if putting anything in the spec means it can never change, then by
> all means let's leave it out.  Because we can't commit to freezing
> IPython development forever.
>
> But we have put a lot of thought into trying to ensure that we won't
> need format changes for a long time, because we are keenly aware of
> how disruptive a file format change is.  And now that there are a ton
> of notebooks 'in the wild', we know it would be a real major annoyance
> to make such changes nilly-willy.
>
> So we will do everything we can to keep developing, for as long as
> possible, on the v3 format.  We will try to encapsulate all new use
> cases and functionality into the extensible metadata fields that are
> already defined in there.  The course I foresee is that the *user
> interface* will evolve to expose and make better use of these
> notebooks, so certain fancier features (say a metadata-based slideshow
> mode, for example) might not exist in older versions simply because
> the code hasn't been written yet.
>
> To be more specific with the slideshow idea (which is in the works):
> let's say that we add tags to the metadata that will be interpreted as
> slide transitions in a yet-to-be completed slideshow implementation
> for IPython 0.14.  IPython current (0.13) wouldn't show the slideshow
> because it simply doesn't have the feature.  But it would open a
> notebook saved with slideshow metadata without losing any of it, and
> it could be worked on, edited, etc, without any danger.
>

Thanks for the detailed reply. The 3 versions in the last 1.5 year worried
me, but it seems the dust has settled now. I'll go and vote +1 on including
this in the spec.

Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-user/attachments/20120922/08c67c4f/attachment-0001.html 


More information about the SciPy-User mailing list