Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > > Ben Finney writes: > > > * Address all the language around Python 2 versus Python 3 versus > > > Python general, and re-order or re-word to focus *primarily* on > > > Python 3, with Python 2 treated as the still-supported legacy > > > system. > > I've merged these changes. I have a little bit of adjustment I want to > do on top of it, but this helps a lot. Thanks, You're welcome, and thank you for working to get this in. -- \“All opinions are not equal. Some are a very great deal more | `\ robust, sophisticated, and well supported in logic and argument | _o__) than others.” —Douglas Adams | Ben Finney
Re: Python Policy: Things to consider for Stretch
On Feb 16, 2016, at 11:54 AM, Paul Wise wrote: >I always thought it strange to put site- in /usr/local since >/usr/local already implies site/system-wide packages. Same for dist- >since /usr already implies distribution packages. For as long as I can remember, a from-source 'configure && make && make install' always put Python in /usr/local by default. I think it was pretty much the defacto standard for non-vendor supplied software[*] back in the days of IRIX, SunOS, and other early *nix OSes that Python was developed on. So it was therefore completely natural that you'd end up with a site-packages in /usr/local. It was only later that the /usr/local site-packages directory ended up on a /usr pathed distro-provided Python, which of course led to the previously discussed dist-packages, the location of which completely mirrors site-packages. >I find it weird that site- gets used in ~/ since they are clearly user >packages not site/system-wide packages. It's all just a big ball of cruft-on-cruft with backward compatibility preventing most cullings. Somewhere out there, the entire world financial system probably still critically depends on a tiny bit of Python 1.3 that nobody has anything but the .pyc files for any more. ;) Cheers, -Barry [*] I can't even call it Free Software or Open Source because it predates those terms. I mean, I started out sharing split shar files on Usenet with my UUCP address. ObGOML.
Re: Python Policy: Things to consider for Stretch
On Tue, Feb 16, 2016 at 11:42 AM, Barry Warsaw wrote: > I don't remember exactly why we called it 'site-packages' ... Thanks for the history :) I always thought it strange to put site- in /usr/local since /usr/local already implies site/system-wide packages. Same for dist- since /usr already implies distribution packages. I find it weird that site- gets used in ~/ since they are clearly user packages not site/system-wide packages. Any thoughts on that? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Python Policy: Things to consider for Stretch
On Feb 15, 2016, at 07:42 PM, Barry Warsaw wrote: >I don't remember exactly why we called it 'site-packages', but I believe it >was an evolution from the earlier ni.py module, which was where dotted module >paths first showed up in Python. And which had a 'site-python' directory, which was kept at least for Python 1.5 also. Cheers, -Barry
Re: Python Policy: Things to consider for Stretch
On Feb 16, 2016, at 11:05 AM, Paul Wise wrote: >Side-note: does anyone know why Python puts packages in "dist-packages", >"site-packages" etc directories instead of just "packages" directories? I don't remember exactly why we called it 'site-packages', but I believe it was an evolution from the earlier ni.py module, which was where dotted module paths first showed up in Python. According to the HISTORY file, site-packages showed up sometime between 1.5a3 and 1.5a4, which IIRC would have been around 2001, so after Pythonlabs split from CNRI. If you want to read a blast from the past, here's Guido's original essay on built-in package support added in Python 1.5, again derived from the optional ni.py in earlier versions. https://www.python.org/doc/essays/packages/ dist-packages was a later Debian compromise so as not to break from-source builds installed in /usr/local with the default `make install` target. I think that was probably around the time I joined Canonical but wasn't working on the Foundations team yet. I do remember Doko and I talking about it, and it seemed like 'dist-' was a good parallel to 'site-' (i.e. a place for the distribution to put things). Cheers, -Barry
Re: Python Policy: Things to consider for Stretch
On Sat, Jan 23, 2016 at 9:55 AM, Barry Warsaw wrote: > 2.5 Module Path > > "Public Python modules must be installed in the system Python modules > directory, /usr/lib/python./dist-packages. Public Python 3 modules must > be installed in /usr/lib/python3/dist-packages." Side-note: does anyone know why Python puts packages in "dist-packages", "site-packages" etc directories instead of just "packages" directories? -- bye, pabs https://wiki.debian.org/PaulWise
Re: Python Policy: Things to consider for Stretch
On Tuesday, February 02, 2016 06:44:57 AM Ben Finney wrote: > Ben Finney writes: > > * Address all the language around Python 2 versus Python 3 versus > > > > Python general, and re-order or re-word to focus *primarily* on Python > > 3, with Python 2 treated as the still-supported legacy system. > > > > I'm maintaining a Bazaar branch for this, feel free to get it:: > > $ mkdir python.benfinney/ && cd python.benfinney/ > > $ bzr branch --bind > > http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-deb > > ian/devel/ > Ben Finney writes: > > Thank you, Scott! I'll proceed with the semantic changes that promote > > Python 3 to the primary position. > > Those changes are now in the above branch. The summary of changes from > the commit messages: > > $ bzr log --log-format line --revision ancestor:.. > 430: Ben Finney 2016-02-02 Re-phrase version distinctions to make Python > 3 primary. 429: Ben Finney 2016-02-01 When only Python 2 is specified, just > use literal “2” major version. 428: Ben Finney 2016-02-01 Use Python 3 > examples where appropriate. 427: Ben Finney 2016-01-31 Refine some grammar > and punctuation. 426: Ben Finney 2016-01-31 Distinguish “Python” the > unversioned system versus “Python 2”. 425: Ben Finney 2016-01-30 [merge] > Merge from ‘python-defaults-debian’ mainline. > > Also attached to this message as a Bazaar patch bundle. I've merged these changes. I have a little bit of adjustment I want to do on top of it, but this helps a lot. Thanks, Scott K
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > * Address all the language around Python 2 versus Python 3 versus > Python general, and re-order or re-word to focus *primarily* on Python > 3, with Python 2 treated as the still-supported legacy system. > > I'm maintaining a Bazaar branch for this, feel free to get it:: > > $ mkdir python.benfinney/ && cd python.benfinney/ > $ bzr branch --bind > http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Ben Finney writes: > Thank you, Scott! I'll proceed with the semantic changes that promote > Python 3 to the primary position. Those changes are now in the above branch. The summary of changes from the commit messages: $ bzr log --log-format line --revision ancestor:.. 430: Ben Finney 2016-02-02 Re-phrase version distinctions to make Python 3 primary. 429: Ben Finney 2016-02-01 When only Python 2 is specified, just use literal “2” major version. 428: Ben Finney 2016-02-01 Use Python 3 examples where appropriate. 427: Ben Finney 2016-01-31 Refine some grammar and punctuation. 426: Ben Finney 2016-01-31 Distinguish “Python” the unversioned system versus “Python 2”. 425: Ben Finney 2016-01-30 [merge] Merge from ‘python-defaults-debian’ mainline. Also attached to this message as a Bazaar patch bundle. # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: ben+deb...@benfinney.id.au-20160201192807-\ # 7ux9dchggw9s8znh # target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\ # defaults-debian/ # testament_sha1: 6a28ebdd010851ced1dfe1087d61b9a1dbded494 # timestamp: 2016-02-02 06:36:06 +1100 # base_revision_id: sc...@kitterman.com-20160129221800-\ # kkxuexf3v28q9ro0 # # Begin patch === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml revid:sc...@kitterman.com-20160129221800-kkxuexf3v28q9ro0 +++ debian/python-policy.sgml revid:ben+deb...@benfinney.id.au-20160201192807-7ux9dchggw9s8znh @@ -84,10 +84,12 @@ On the move to Python 3 - Debian currently supports two Python stacks, one for Python 2 - and one for Python 3. The long term goal for Debian is to + Debian currently supports two Python stacks, one for Python 3 + and one for Python 2. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some time. + + https://www.python.org/dev/peps/pep-0404/"; name="PEP 404"> states that no more major Python 2 releases are planned, although the latest released minor version 2.7 @@ -112,10 +114,10 @@ - Python libraries should be always packaged for Python 3 - if supported. Python 2 libraries should be packaged, if - applications found in the reverse dependencies are not - yet supported by Python 3. + Python libraries, if they support Python 3, should be always + packaged for Python 3. If an application supports only Python + 2, the Python libraries for that application should also be + packaged for Python 2. @@ -133,12 +135,12 @@ Versions - At any given time, the binary package python - will represent the current default Debian Python version. The - binary package python3 will represent the - current Debian Python 3 version. As far as is reasonable, Python - and Python 3 should be treated as separate runtime systems with - minimal interdependencies. + At any given time, the binary package python3 + will represent the current default Debian Python 3 version; the + binary package python will represent the + current default Debian Python 2 version. As far as is reasonable, + Python 3 and Python 2 should be treated as separate runtime + systems with minimal interdependencies. In some cases, Python policy explicitly references Python helper @@ -150,15 +152,17 @@ It is a design goal to fully specify required interfaces and functions in policy for Python 3 and to avoid enshrining specific implementation details in policy. Except as noted, policy for - Python 3 is the same as Python with the addition of the version - number as needed to distinguish them. - - - The default Debian Python version should always be the latest - stable upstream version that can be fully integrated in Debian. + Python 2 is the same as Python 3 with the exception of the + different major version number as needed to distinguish them. + + + The default Debian Python version, for each of Python 3 and Python + 2, should always be the latest stable upstream version that can be + fully integrated in Debian. + + There may be newer supported or unsupported versions included in - the Debian if they are not fully integrated for a particular - release. + Debian if they are not fully integrated for a particular release. Apart from the default version, legacy versions of Python or beta @@ -178,17 +182,17 @@ - The set of currently supported Python versions c
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote: > ... > > Once these non-semantic changes are accepted I will begin work on > > the second stage of semantic changes. > ... > > OK. Those are all accepted. Thank you, Scott! I'll proceed with the semantic changes that promote Python 3 to the primary position. > Barry Warsaw had done some changes in the -whl section so I made an > attempt at merging what the two of you had done. That attempt clobbered my earlier changes in that area. I'll restore them and preserve Barry's intention. I should have some more changes to present in a day or two. -- \ “The best mind-altering drug is truth.” —Jane Wagner, via Lily | `\Tomlin | _o__) | Ben Finney
Re: Python Policy: Things to consider for Stretch
On Tuesday, January 26, 2016 04:46:19 PM Ben Finney wrote: ... > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. ... OK. Those are all accepted. Barry Warsaw had done some changes in the -whl section so I made an attempt at merging what the two of you had done. Thanks, Scott K
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I should be able to get it reviewed and merged no later than Saturday > (probably Friday). Much appreciated, thanks for the response. -- \“When I was a baby I kept a diary. Recently I was re-reading | `\ it, it said ‘Day 1: Still tired from the move. Day 2: Everybody | _o__) talks to me like I'm an idiot.’” —Steven Wright | Ben Finney
Re: Python Policy: Things to consider for Stretch
On January 26, 2016 10:32:57 PM EST, Ben Finney wrote: >Dmitry Shachnev writes: > >> On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote: >> > I'm planning to provide changes in two bundles: >> > >> > * Go through the whole document and tidy it up for consistency, >> > source style, markup, and language style. This should not change >> > the meaning of anything, but will change the wording of numerous >> > passages. >> > >> > My proposal for that is attached here as a Bazaar change bundle. >> >> Thanks for your work here, your changes look nice to me! > >Thank you. Are you in a position to do me the favour of merging the >bundle into the repository ‘pkg-python/python-defaults-debian/’ at >Alioth? Only one of the package maintainers can do that. I'm very busy with $work at the moment, but I should be able to get it reviewed and merged no later than Saturday (probably Friday). Scott K
Re: Python Policy: Things to consider for Stretch
Dmitry Shachnev writes: > On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote: > > I'm planning to provide changes in two bundles: > > > > * Go through the whole document and tidy it up for consistency, > > source style, markup, and language style. This should not change > > the meaning of anything, but will change the wording of numerous > > passages. > > > > My proposal for that is attached here as a Bazaar change bundle. > > Thanks for your work here, your changes look nice to me! Thank you. Are you in a position to do me the favour of merging the bundle into the repository ‘pkg-python/python-defaults-debian/’ at Alioth? -- \ “Money is always to be found when men are to be sent to the | `\ frontiers to be destroyed: when the object is to preserve them, | _o__) it is no longer so.” —Voltaire, _Dictionnaire Philosophique_ | Ben Finney
Re: Python Policy: Things to consider for Stretch
Hi Ben, On Tue, Jan 26, 2016 at 04:46:19PM +1100, Ben Finney wrote: > I'm planning to provide changes in two bundles: > > * Go through the whole document and tidy it up for consistency, source > style, markup, and language style. This should not change the meaning > of anything, but will change the wording of numerous passages. > > My proposal for that is attached here as a Bazaar change bundle. > > * Address all the language around Python 2 versus Python 3 versus Python > general, and re-order or re-word to focus *primarily* on Python 3, > with Python 2 treated as the still-supported legacy system. > > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. > > I'm maintaining a Bazaar branch for this, feel free to get it:: > > $ mkdir python.benfinney/ && cd python.benfinney/ > $ bzr branch --bind > http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Thanks for your work here, your changes look nice to me! -- Dmitry Shachnev signature.asc Description: PGP signature
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > I'm planning to provide changes in two bundles: > > * Go through the whole document and tidy it up for consistency, source > style, markup, and language style. This should not change the meaning > of anything, but will change the wording of numerous passages. > > My proposal for that is attached here as a Bazaar change bundle. > > * Address all the language around Python 2 versus Python 3 versus Python > general, and re-order or re-word to focus *primarily* on Python 3, > with Python 2 treated as the still-supported legacy system. > > Once these non-semantic changes are accepted I will begin work on the > second stage of semantic changes. That last sentence isn't very clear. What I intended to imply is: The first stage is done and all its changes are in the branch, the second stage I haven't yet started. The set of revision in the “r411–r424” patch bundle is all intended to be non-semantic changes, and once they're accepted I'll begin on the second, semantic-changing, stage of work. -- \“I don't accept the currently fashionable assertion that any | `\ view is automatically as worthy of respect as any equal and | _o__) opposite view.” —Douglas Adams | Ben Finney
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > Scott Kitterman writes: > > > At this point I think internal consistency is probably more > > important, so if someone wants to go through and make all the > > python's that should be python2, etc then please send in a patch. > > I'll take that on. I'm planning to provide changes in two bundles: * Go through the whole document and tidy it up for consistency, source style, markup, and language style. This should not change the meaning of anything, but will change the wording of numerous passages. My proposal for that is attached here as a Bazaar change bundle. * Address all the language around Python 2 versus Python 3 versus Python general, and re-order or re-word to focus *primarily* on Python 3, with Python 2 treated as the still-supported legacy system. Once these non-semantic changes are accepted I will begin work on the second stage of semantic changes. I'm maintaining a Bazaar branch for this, feel free to get it:: $ mkdir python.benfinney/ && cd python.benfinney/ $ bzr branch --bind http://vcs.whitetree.org/bzr/public/debian/python/python-defaults-debian/devel/ Currently the log of changes since the ‘pkg-python’ repository (as included in the attached change bundle) looks like:: $ cd devel/ $ bzr log --log-format line --revision ancestor:.. 424: Ben Finney 2016-01-26 Clarify what text is literal names. 423: Ben Finney 2016-01-26 Update copyright notice. 422: Ben Finney 2016-01-26 Refine markup for a compact list. 421: Ben Finney 2016-01-26 Clarify what names are filesystem paths. 420: Ben Finney 2016-01-26 Clarify what names are Debian packages. 419: Ben Finney 2016-01-26 Specify GPLv2 documents explicitly. 418: Ben Finney 2016-01-26 Update external URLs to be current, and use HTTPS. 417: Ben Finney 2016-01-25 Use consistent terminology for “distribution”, “version”, “release”. 416: Ben Finney 2016-01-25 Avoid literal ‘<’ and ‘>’, use SGML character entities. 415: Ben Finney 2016-01-25 Distinguish “Python” the system versus “python” the command. 414: Ben Finney 2016-01-25 Add myself to the document's authors. 413: Ben Finney 2016-01-25 Correct whitespace to conform to Policy style. 412: Ben Finney 2016-01-25 Add editor hints to match Debian Policy text style. 411: Scott Kitterman 2016-01-24 Python policy updates (draft) for Stretch DO NOT UPLOAD YET:wq # Bazaar merge directive format 2 (Bazaar 0.90) # revision_id: ben+deb...@benfinney.id.au-20160126051103-\ # 3zbuoy0u0vp14w5d # target_branch: bzr+ssh://bzr.debian.org/bzr/pkg-python/python-\ # defaults-debian/ # testament_sha1: 765dacf10bafece44db129db818e74a4d0814c0e # timestamp: 2016-01-26 16:43:48 +1100 # source_branch: http://vcs.whitetree.org/bzr/public/debian/python\ # /python-defaults-debian/devel/ # base_revision_id: sc...@kitterman.com-20160124060119-\ # e07prikr3oa8bkbn # # Begin patch === modified file 'debian/python-policy.sgml' --- debian/python-policy.sgml revid:sc...@kitterman.com-20160124060119-e07prikr3oa8bkbn +++ debian/python-policy.sgml revid:ben+deb...@benfinney.id.au-20160126051103-3zbuoy0u0vp14w5d @@ -17,24 +17,28 @@ fli...@debian.org -Josselin Mouette + Josselin Mouette j...@debian.org -Joe Wreschnig + Joe Wreschnig pi...@debian.org -Loïc Minier + Loïc Minier l...@debian.org -Scott Kitterman + Scott Kitterman sc...@kitterman.com -Barry Warsaw -ba...@debian.org + Barry Warsaw + ba...@debian.org + + + Ben Finney + ben+deb...@benfinney.id.au version 0.10.1.0 @@ -46,7 +50,7 @@ - Copyright © 1999—2014 Software in the Public Interest + Copyright © 1999–2016 Software in the Public Interest This manual is free software; you can redistribute it and/or @@ -61,11 +65,11 @@ the GNU General Public License for more details. - A copy of the GNU General Public License is available as - /usr/share/common-licences/GPL in the Debian GNU/Linux - distribution or on the World Wide Web at - http://www.gnu.org/copyleft/gpl.html"; - name="The GNU General Public License">. + A copy of the GNU General Public License version 2 is available as + /usr/share/common-licences/GPL-2 in the Debian + GNU/Linux system, or on the World Wide Web at + https://www.gnu.org/licenses/old-licenses/gpl-2.0.html"; + name="GNU General Public License, version 2">. You can also obtain it by writing to the @@ -83,12 +87,12 @@ Debian currently supports two Python stacks, one for Python 2 and one for Python 3. The long term goal for Debian is to reduce this to one stack, dropping the Python 2 stack at some - time. - http://legacy.python.org/dev/peps/pep-0404/"; + time. + https://www.python.org/dev/peps/pep-0404/"; name="PEP 404"> states that no more major Python 2 releases - are planned,
Re: Python Policy: Things to consider for Stretch
On January 24, 2016 11:59:14 PM EST, Ben Finney
wrote:
>Scott Kitterman writes:
>
>> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
>> > Found it; the source document is ‘python-policy.sgml’ in the source
>> > VCS for ‘python3’. Currently that's a Bazaar repository at
>> >
>.
>>
>> That's correct.
>
>Hmm, apparently I've got the wrong thing. I've got changes from you,
>most recently 2016-01-11; followed by later changes as recent as
>2016-01-18:
>
>=
>$ bzr info
>Repository checkout (format: 2a)
>Location:
>repository checkout root:
>/home/bignose/Projects/debian/python3/python3-defaults-debian/trunk
>checkout of branch:
>bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/
>[…]
>
>$ bzr log --log-format=line --limit 3
>340: Matthias Klose 2016-01-18 - drop python3.4 from the defaults
>339: Matthias Klose 2016-01-17 * Drop Python 3.4 as a supported python3
>version.
>338: Scott Kitterman 2016-01-11 {3.5.1-1} Upload to unstable
>=
>
>But the ‘debian/python-policy.sgml’ document has a version:
>
>=
>$ grep '' debian/python-policy.sgml
> version 0.4.1.0
>=
>
>which doesn't match what you showed (containing “version 0.10.1.0”) at
>http://kitterman.com/debian/python-policy.new-from-old.diff.html>.
>
>What am I missing? Is there a different repository or branch I need to
>use?
Python-defaults, not python3-defaults.
Scott K
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes:
> On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote:
> > Found it; the source document is ‘python-policy.sgml’ in the source
> > VCS for ‘python3’. Currently that's a Bazaar repository at
> > .
>
> That's correct.
Hmm, apparently I've got the wrong thing. I've got changes from you,
most recently 2016-01-11; followed by later changes as recent as
2016-01-18:
=
$ bzr info
Repository checkout (format: 2a)
Location:
repository checkout root:
/home/bignose/Projects/debian/python3/python3-defaults-debian/trunk
checkout of branch:
bzr+ssh://bzr.debian.org/bzr/pkg-python/python3-defaults-debian/
[…]
$ bzr log --log-format=line --limit 3
340: Matthias Klose 2016-01-18 - drop python3.4 from the defaults
339: Matthias Klose 2016-01-17 * Drop Python 3.4 as a supported python3 version.
338: Scott Kitterman 2016-01-11 {3.5.1-1} Upload to unstable
=
But the ‘debian/python-policy.sgml’ document has a version:
=
$ grep '' debian/python-policy.sgml
version 0.4.1.0
=
which doesn't match what you showed (containing “version 0.10.1.0”) at
http://kitterman.com/debian/python-policy.new-from-old.diff.html>.
What am I missing? Is there a different repository or branch I need to
use?
--
\ “Capitalism has destroyed our belief in any effective power but |
`\ that of self interest backed by force.” —George Bernard Shaw |
_o__) |
Ben Finney
Re: Python Policy: Things to consider for Stretch
Thanks for taking this on Ben, On Jan 24, 2016, at 04:33 PM, Ben Finney wrote: >I think you're right that this needs a general clean-up through the >policy document, to consistently use: > >* “python2” to refer to that command only; > >* “python3” to refer to that command only; > >* “python” to refer to that command (and I'd suggest deprecating it > where feasible); > >* “Python 2” referring exclusively to that language version 2.x and no > other versions of that language; > >* “Python 3” referring exclusively to that language version 3.x and no > other versions of that language; > >* “Python” referring to the language implemented either as Python 2 or > Python 3. I agree with all the above, though re: Scott's feedback on deprecation of /usr/bin/python, here's my take (note, we've had these discussions many times before ;). Ultimately, we should be both guided by, and drive with our opinions, PEP 394 which should help keep the situation consistent across *nix distros. https://www.python.org/dev/peps/pep-0394/ /usr/bin/python (on Debian) should never point to anything but the latest Python 2 version *until* Python 2.7 is EOL'd upstream, meaning binary, source, and security-only releases. Bug fix releases (source only) are promised until 2020, and I'd wager we'll see supported security-only releases until 2025. I would like to see scripts that are only compatible with Python 2 to be shebanged `/usr/bin/python2` or `/usr/bin/python2.7`. You can think of this mostly as documentation at this point, but it does remove any possibility of future ambiguity. It also begins to open the door to the often discussed launcher idea someday landing on /usr/bin/python, enabling bilingual scripts. I think there's zero harm in this since shebang lines are generally not user-evident. Then there's no change to /usr/bin/python any time soon, or the fact that invoking `python` at the shell starts the Python 2 interpreter. Cheers, -Barry
Re: Python Policy: Things to consider for Stretch
On Sunday, January 24, 2016 04:58:26 PM Ben Finney wrote: > Ben Finney writes: > > Where is the Git (I assume?) repository you're using for VCS of this > > policy document? > > Found it; the source document is ‘python-policy.sgml’ in the source VCS > for ‘python3’. Currently that's a Bazaar repository at > . That's correct. Scott K
Re: Python Policy: Things to consider for Stretch
On Sunday, January 24, 2016 04:33:55 PM Ben Finney wrote: > Scott Kitterman writes: > > I don't particularly agree, but if that's correct, then there's a > > large amount of change needed throughout the policy. These certainly > > aren't the only places this comes up. > > Yes, that's likely because when the Debian Python policy was initially > drafted, there was no Python 3 anywhere close to entering Debian. So > “Python” and “Python 2” were less ambiguously conflated at that time. > > Now that Python 2 and Python 3 are both commonly (and correctly) > referred to as “Python”, we need to take more care using the terms for > what we mean. > > > Ambiguous or not, I think the policy is mostly consistent in using > > python and python3 vice python2 and python3. > > Well that's another dimension of confusion :-) The term “python2” and > “python3” are named of commands, more than the names of languages. > > I think you're right that this needs a general clean-up through the > policy document, to consistently use: > > * “python2” to refer to that command only; > > * “python3” to refer to that command only; > > * “python” to refer to that command (and I'd suggest deprecating it > where feasible); > > * “Python 2” referring exclusively to that language version 2.x and no > other versions of that language; > > * “Python 3” referring exclusively to that language version 3.x and no > other versions of that language; > > * “Python” referring to the language implemented either as Python 2 or > Python 3. > > > At this point I think internal consistency is probably more important, > > so if someone wants to go through and make all the python's that > > should be python2, etc then please send in a patch. > > I'll take that on. Send it to anywhere in particular? Or I can just send > it to this forum. Here or a bzr branch (per my other reply) somewhere is fine. I agree with all of that except the idea of deprecating /usr/bin/python. It'll never point to anything other than a Python (2) version in Debian, so there's no need to deprecate it faster than Python (2) in general. Scott K
Re: Python Policy: Things to consider for Stretch
On Sunday, January 24, 2016 04:46:09 PM Ben Finney wrote: > Scott Kitterman writes: > > I've taken a run through the current Python Policy to see where I > > think it needs to be updated for Stretch. The updates largely fall > > into four categories: […] > > This is great to see, thank you Scott. > > Where is the Git (I assume?) repository you're using for VCS of this > policy document? It's in bzr, actually. You can find the repository at https://alioth.debian.org/scm/loggerhead/pkg-python/python-defaults-debian/files (that page has a link to make a branch using bzr. The Python Policy is in debian/python-policy.sgml You can make a text version using: debiandoc2text debian/python-policy.sgml > > This is just my opinion on stuff I found. I'm interested in feedback > > on how these changes look and what else ought to be considered > > I like what I see (modulo other discussions in this thread). > > > One small nit: the examples of what is included versus excluded of the > “scope” of a Python version reference. It used to say: > > as it seems reasonable to provide them. (Note: For the scope of this > document, Python versions are synonymous to feature releases, i.e. > Python 2.7 and 2.7.1 are sub-minor versions of the same Python version > 2.7, but Python 2.6 and 2.7 are indeed different versions.) > > The contrast “2.7 and 2.7.1 are […] the same Python version 2.7”, with > “2.6 and 2.7 are […] different versions”, uses version “2.7” in both > parts. > > I think it's important to the example that an *identical* version is in > *both* arms of that contrast, to be clear what is being distinguished. > > So in the re-write I'd advise again using an identical version in both > parts: > > as it seems reasonable to provide them. (Note: For the scope of this > document, Python versions are synonymous to feature releases, i.e. > Python 3.5 and 3.5.1 are sub-minor versions of the same Python version > 3.5, but Python 3.4 and 3.5 are indeed different versions.) > > If I can know where to access the VCS repository I can make a patch for > that, if you like. Great. See above. I just pushed the edits I've proposed so what's in there now should be clean for you to work on top of. Pushing them to the repository doesn't make them any less draft in my opinion (in case anyone was wondering). Scott K
Re: Python Policy: Things to consider for Stretch
Ben Finney writes: > Where is the Git (I assume?) repository you're using for VCS of this > policy document? Found it; the source document is ‘python-policy.sgml’ in the source VCS for ‘python3’. Currently that's a Bazaar repository at . -- \ “The entertainment industry calls DRM "security" software, | `\ because it makes them secure from their customers.” —Cory | _o__) Doctorow, 2014-02-05 | Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I've taken a run through the current Python Policy to see where I > think it needs to be updated for Stretch. The updates largely fall > into four categories: […] This is great to see, thank you Scott. Where is the Git (I assume?) repository you're using for VCS of this policy document? > This is just my opinion on stuff I found. I'm interested in feedback > on how these changes look and what else ought to be considered I like what I see (modulo other discussions in this thread). One small nit: the examples of what is included versus excluded of the “scope” of a Python version reference. It used to say: as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 2.7 and 2.7.1 are sub-minor versions of the same Python version 2.7, but Python 2.6 and 2.7 are indeed different versions.) The contrast “2.7 and 2.7.1 are […] the same Python version 2.7”, with “2.6 and 2.7 are […] different versions”, uses version “2.7” in both parts. I think it's important to the example that an *identical* version is in *both* arms of that contrast, to be clear what is being distinguished. So in the re-write I'd advise again using an identical version in both parts: as it seems reasonable to provide them. (Note: For the scope of this document, Python versions are synonymous to feature releases, i.e. Python 3.5 and 3.5.1 are sub-minor versions of the same Python version 3.5, but Python 3.4 and 3.5 are indeed different versions.) If I can know where to access the VCS repository I can make a patch for that, if you like. -- \ “Come on, if your religion is so vulnerable that a little bit | `\ of disrespect is going to bring it down, it's not worth | _o__) believing in, frankly.” —Terry Gilliam, 2005-01-18 | Ben Finney
Re: Python Policy: Things to consider for Stretch
Scott Kitterman writes: > I don't particularly agree, but if that's correct, then there's a > large amount of change needed throughout the policy. These certainly > aren't the only places this comes up. Yes, that's likely because when the Debian Python policy was initially drafted, there was no Python 3 anywhere close to entering Debian. So “Python” and “Python 2” were less ambiguously conflated at that time. Now that Python 2 and Python 3 are both commonly (and correctly) referred to as “Python”, we need to take more care using the terms for what we mean. > Ambiguous or not, I think the policy is mostly consistent in using > python and python3 vice python2 and python3. Well that's another dimension of confusion :-) The term “python2” and “python3” are named of commands, more than the names of languages. I think you're right that this needs a general clean-up through the policy document, to consistently use: * “python2” to refer to that command only; * “python3” to refer to that command only; * “python” to refer to that command (and I'd suggest deprecating it where feasible); * “Python 2” referring exclusively to that language version 2.x and no other versions of that language; * “Python 3” referring exclusively to that language version 3.x and no other versions of that language; * “Python” referring to the language implemented either as Python 2 or Python 3. > At this point I think internal consistency is probably more important, > so if someone wants to go through and make all the python's that > should be python2, etc then please send in a patch. I'll take that on. Send it to anywhere in particular? Or I can just send it to this forum. -- \ “Pinky, are you pondering what I'm pondering?” “Well, I think | `\ so, but *where* do you stick the feather and call it macaroni?” | _o__) —_Pinky and The Brain_ | Ben Finney
Re: Python Policy: Things to consider for Stretch
On Saturday, January 23, 2016 08:50:49 PM Barry Warsaw wrote: > On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote: > >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. > > I'll leave it to you, but my take on it is that "Python" is the generic term > for the language and its specification. "Python 2" v "Python 3" provides > disambiguation when you're talking about specific major versions of the > language. "Python 3.5" and such usually describe specific releases of the > CPython interpreter implementation (note how "CPython" is used to > disambiguate between alternative implementations of the language > specification). Finally, python2.7, python3.4 and such are used to > describe the executables that provide the versions (e.g. mentally prepend > them with /usr/bin). > > All of this, except the last point perhaps, is orthogonal to the > /usr/bin/python2 issue you mention. > > Back to the original point, to me saying "Python" and "Python 3" is > confusing or misleading, given the above definitions. It's confusing > because "Python 3" *is* Python, so what's the difference? It's misleading > because it implies that somehow "Python 3" isn't "Python". > > >> 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". > > See above, but to rephrase, "Python" is ambiguous in this context because > you could be talking about Python-the-language, not > Python-some-release-version. I don't particularly agree, but if that's correct, then there's a large amount of change needed throughout the policy. These certainly aren't the only places this comes up. Ambiguous or not, I think the policy is mostly consistent in using python and python3 vice python2 and python3. At this point I think internal consistency is probably more important, so if someone wants to go through and make all the python's that should be python2, etc then please send in a patch. Scott K signature.asc Description: This is a digitally signed message part.
Re: Python Policy: Things to consider for Stretch
On Jan 23, 2016, at 03:38 AM, Scott Kitterman wrote: >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. I'll leave it to you, but my take on it is that "Python" is the generic term for the language and its specification. "Python 2" v "Python 3" provides disambiguation when you're talking about specific major versions of the language. "Python 3.5" and such usually describe specific releases of the CPython interpreter implementation (note how "CPython" is used to disambiguate between alternative implementations of the language specification). Finally, python2.7, python3.4 and such are used to describe the executables that provide the versions (e.g. mentally prepend them with /usr/bin). All of this, except the last point perhaps, is orthogonal to the /usr/bin/python2 issue you mention. Back to the original point, to me saying "Python" and "Python 3" is confusing or misleading, given the above definitions. It's confusing because "Python 3" *is* Python, so what's the difference? It's misleading because it implies that somehow "Python 3" isn't "Python". >> 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". See above, but to rephrase, "Python" is ambiguous in this context because you could be talking about Python-the-language, not Python-some-release-version. Cheers, -Barry pgpy0qrLvOIdq.pgp Description: OpenPGP digital signature
Re: Python Policy: Things to consider for Stretch
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./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./dist-packages. So maybe say > /usr/local/lib/python2.7/dist-packages here too? There really won't be any > other value for 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. 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 signature.asc Description: This is a digitally signed message part.
Re: Python Policy: Things to consider for Stretch
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./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? 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./dist-packages. So maybe say /usr/local/lib/python2.7/dist-packages here too? There really won't be any other value for than 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? 3.6 Provides s/substituation/substitution/ B.2. dh_python2 and dh_python3 Again, I think here you want to say "Python2 and Python3" to disambiguate between generic Python. Other than that, +1 Cheers, -Barry pgplZMuJy6II7.pgp Description: OpenPGP digital signature
Python Policy: Things to consider for Stretch
I've taken a run through the current Python Policy to see where I think it needs to be updated for Stretch. The updates largely fall into four categories: 1. Update old examples 2. Clean up old policy test that no longer applies 3. Simplify things due to there only being one python version 4. Make the text better match current practice I've sent this twice now and the list didn't like it for different reasons, so I've posted [1] the diff I've come up with so far in rfcdiff format (because I think it's easier to read that unified diffs for this kind of thing). This is just my opinion on stuff I found. I'm interested in feedback on how these changes look and what else ought to be considered (no: rewrite the whole thing is not useful feedback unless you provide the text). While I don't have any specific near-term deadlines for this, at least one of the proposals (killing off python:Provides) will take a little while to accomplish, so I would like to get consensus on what's reasonable sooner rather than later. Scott K [1] http://kitterman.com/debian/python-policy.new-from-old.diff.html signature.asc Description: This is a digitally signed message part.
