[SciPy-User] Pylab - standard packages
Sat Sep 22 16:43:38 CDT 2012
On Sat, Sep 22, 2012 at 8:10 PM, Fernando Perez <firstname.lastname@example.org>wrote:
> On Sat, Sep 22, 2012 at 6:46 AM, Ralf Gommers <email@example.com>
> > 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
> > forward compatibility or by default keep saving in version 3 even after
> > 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the SciPy-User