Fedora Python features

[David Malcolm]

On Thu, 2010-05-27 at 20:39 -0400, Toshio Kuratomi wrote:
> On Thu, May 27, 2010 at 07:32:23PM -0400, David Malcolm wrote:
> > I've added a list of Python-related features to our wiki page here:
> > https://fedoraproject.org/wiki/SIGs/Python#Python_Features
> > 
> > Is anyone else working on Python-related Fedora features?
> > 
> You are!
> 
> pypy and pynie are good stories for Fedora 14.  Although what would make
> this even better is figuring out how to package modules for both of these.

(following up on this and on an IRC chat on #fedora-python):

I've speculatively created this feature for PyPy in Fedora:
https://fedoraproject.org/wiki/Features/PyPyStack

It's not clear to me yet how far to push this:
1) just the core interpreter, or
2) sharing pure-Python add-on modules with the system Python (but with
split bytecode files), or
3) a full, independent Python stack, but with just pure-Python add-on
modules, or
4) a full, independent Python stack, with both pure-Python and
machine-code extension modules

Doing e.g. (4) would probably involve a lot of work, though I think we'd
be first to have done it, which would be good in of itself.

Speaking for myself, I don't yet know if I myself want to sign up for
that.  There are particular Python workloads I want to optimize (yum is
one of them), and I don't yet know if PyPy is the best solution for what
I need.  (I need to write some systemtap scripts to instrument things).



As for Pynie, I've packaged a prerelease state of upstream SVN, and Tim
Lauridsen reviewed it (bug 593069), but it's at an early stage of
development, and upstream have requested that we not ship it until they
ship tarballs (so I've closed that review out as DEFERRED for now).


> I've been working on coding kitchen (will package once I get the licensing
> worked out) which may or may not make a good story.... It's a library of
> little code that everyone decided they need to write.  So it's little and
> eclectic by nature (not earthshattering) but at the same time we're writing
> it and it would be useful...  I'll propose it as a feature if someone prods
> me otherwise I'll consider it just another package.
> 
>   https://fedorahosted.org/releases/k/i/kitchen/docs

Is $FOO a feature?  There's a checklist at the bottom of this page:
https://fedoraproject.org/wiki/Features/Policy/Definitions

"kitchen" looks useful, but I'm not convinced that it matches any of the
criteria there.  (Don't let me stop you though!)


> > * upgrading python3 from 3.1 to 3.2  [3].  This is more uncertain, as
> > the upstream schedule doesn't line up so well with ours.  We could
> > potentially package an alpha release I guess.  python3 isn't on the
> > critical path, and the number of packages needing a rebuild is _much_
> > smaller than for Python 2, but I'd want to talk to upstream about it.
> > By comparison, Ubuntu's next release has a slightly later feature freeze
> > than ours, and is planning to ship a beta of 3.2 ([4] and [5]).
> > 
> To decide this, we really want to have an idea of features vs risks and how
> long between our release and the upstream 3.2-final release.
> 
> * I have a vague remembrance that a lot of good things were added to 3.2 but
>   the upstream whatsnew page doesn't yet list things that jog my memory.
> * We probably don't want to ship 3.2alpha1 if final doesn't come out for six
>   more months but shipping a late alpha when final is scheduled for two
>   months later could be a good tradeoff.

Lining up the schedules:
DATE        PYTHON 3 UPSTREAM     FEDORA      
2010-05-25	                  Fedora 13 Release
2010-05-28 >Present day
2010-06-26  Python 3.2 alpha 1
2010-07-13	                  F14 Feature Submission Deadline
2010-07-24  Python 3.2 alpha 2
2010-07-27	                  F14 Feature Freeze
2010-07-27	                  Branch Fedora 14 from Rawhide
2010-08-03	                  F14 Software String Freeze
2010-08-03                        F14 Alpha Change Deadline
2010-08-17                        F14 Alpha Release
2010-08-21  Python 3.2 alpha 3
2010-08-31                        F14 Software Translation Deadline
2010-09-07                        F14 Beta Change Deadline
2010-09-18  Python 3.2 beta 1; 
2010-09-18  Upstream feature freeze
2010-09-21                        F14 Beta Release
2010-10-12                        F14 Final Freeze
2010-10-14                        F14 Compose Release Candidate
2010-10-16  Python 3.2 beta 2
2010-10-26                        F14 Fedora 14 Final Release
2010-11-13  Python 3.2 candidate 1
2010-11-27  Python 3.2 candidate 2
2010-12-11  Python 3.2 final

Assuming that they turn out to be be true to the day (often a dangerous
assumption!), then at F14 feature freeze on 2010-07-27, upstream would
be at 3.2 alpha 2 (or maybe still alpha 1).   Upstream feature freeze is
only 3 days before F14 beta release.

This also assumes that python3 is not on the critical path, and that
none of the dual-build python2/python3 src.rpms that might in worst-case
need a python3 rebuild have python2 subpackages that _are_ on the
critical path (if that makes sense).

I think my chief concerns are
(i) the possibility of ABI breaks during the 3.2 development cycle,
affecting either the .pyc/.pyo format, or the ABI of .so extension
modules.
(ii) the possibility of irritating upstream by shipping an alpha

With rawhide branched for F15 on 2010-07-27, we could simply do this in
rawhide for F15.



As for Python 2, I think the case for 2.7 for F14 is fairly clear, and
it's just a case of getting ready, then doing it.  I plan to help fix
anything that breaks - but I'm going to be on vacation from June 9th
through 20th, and hopefully _not_ on a computer, so we either want to do
it ASAP, or after the 20th.  It may be sanest to wait until after I'm
back; upstream plan to release RC2 on the 19th.

Thoughts?
Dave