On Friday, January 22, 2016 05:55:19 PM Barry Warsaw wrote: > On Jan 21, 2016, at 10:47 AM, Scott Kitterman wrote: > >I've taken a run through the current Python Policy to see where I think it > >needs to be updated for Stretch. > > Thanks Scott for the badly needed update. > > Some comments, apologies for the lack of good quoting, or if I've read the > diff incorrectly. > > 2.5 Module Path > > "Public Python modules must be installed in the system Python modules > directory, /usr/lib/python<X>.<Y>/dist-packages. Public Python 3 modules > must be installed in /usr/lib/python3/dist-packages." > > I think this could use a bit of disambiguation, sice "system Python modules" > could mean either Python generically, in which case the second sentence is > in conflict. Do you mean "system Python 2 modules"? If so, let's say > that. Also, since Python 2.7 is all there will be from now on, why not say > that explicitly? Personally I seriously dislike the trend to call Python Python 2 (and I still thing approving a pep to invent /usr/bin/python2 because Arch went insane was a horrible idea). There's an earlier spot in the document where it says that everything refers to python and python3 unless it's explicit. I'll make this spot /usr/lib/python2.7/dist-packages and any risk of ambiguity is, I think, resolved. > A good reason not to would be because Policy needs to cover older releases > where there can be multiple versions of Python 2. But then later in your > diff you seem to mention python2.7 as being associated with > /usr/local/lib/python2.<Y>/dist-packages. So maybe say > /usr/local/lib/python2.7/dist-packages here too? There really won't be any > other value for <Y> than 7. We only need (I think) to cover packages being developed for the release the policy is for. Squeeze was the last multi-python version release, so I think we're safe to remove python2.<Y> where way may not always be 7. > 3.4 Specifying Supported Versions > > "The optional `X-Python-Version (preferred) or `XS-Python-Version` field..." > > It's a little confusing because we're now saying we prefer not to have > either field. How about "(previously preferred)" or just drop the > parenthetical? Makes sense. I'll do that. > 3.6 Provides > > s/substituation/substitution/ Thanks. > B.2. dh_python2 and dh_python3 > > Again, I think here you want to say "Python2 and Python3" to disambiguate > between generic Python. If I say Python and Python3, what version can the one that's not Python3 possibly be? I don't think it's any less confusing than starting to call what we've always called "Python" "Python 2". > Other than that, +1 Thanks for reviewing. Scott K
Attachment:
signature.asc
Description: This is a digitally signed message part.