Re: Python 4 and ‘python3’ (was: /usr/bin/python2 shebangs)
On Nov 02, 2016, at 01:57 PM, Ben Finney wrote: >Donald Stufft writes: > >> /usr/bin/python3 being Python 4.x is a bit weird though > >Seriously? Who is proposing that? > >> and it’s likely that Python 4.x is not going to be another break the >> world release. > >Certainly the command ‘python3’ should only ever point to the Python 3 >interpreter. > >If upstream ever releases a “Python 4” but expects the interpreter for >that to also be named ‘python3’, I think we can declare upstream to be >directly courting user pain, and secede on behalf of our users. I wouldn't at all be surprised if /usr/bin/python is reclaimed for some future post-Python2-demise Python 4 interpreter. It might even be a good thing since I'm not sure I'd want a /usr/bin/python4. Not that I'm expecting Python 4 any time soon, but if Larry Hasting's gilectomy work actually pans out, that'd be a solid contender for it. Cheers, -Barry
Re: Python 4 and ‘python3’
Barry Warsaw writes: > On Nov 02, 2016, at 01:57 PM, Ben Finney wrote: > > >Certainly the command ‘python3’ should only ever point to the Python > >3 interpreter. > > > >If upstream ever releases a “Python 4” but expects the interpreter > >for that to also be named ‘python3’, I think we can declare upstream > >to be directly courting user pain, and secede on behalf of our users. > > I wouldn't at all be surprised if /usr/bin/python is reclaimed for > some future post-Python2-demise Python 4 interpreter. It might even be > a good thing since I'm not sure I'd want a /usr/bin/python4. What about a Python 4.0 that is just “the release that comes after 3.9”? http://www.curiousefficiency.org/posts/2014/08/python-4000.html> Such a “Python 4.0” release would inevitably be referred to as Python 4, and inevitably will be considered *not the same* as ‘/usr/bin/python3’. That's what I'm saying is pointless user confusion: do we use ‘/usr/bin/python3’ for the interpreter? Do we use ‘/usr/bin/python4’? Why, if they're deliberately compatible interpreters — indeed, they may be the *same* interpreter? Such a thoroughly, and persistently, confusing state of affairs is entirely avoidable (just use Semantic Versioning, don't name it “4.0” until it's backward-incompatible with all “3.xx”). I had thought that was the sane and prevailing attitude of the Python release managers. But the above post implies that pointless confusion will be directly courted, merely because of some aesthetic objection to a two-digit component in the version string. > Not that I'm expecting Python 4 any time soon […] At the current rate of Python releases, it's not very far in the future before the Python release managers must decide what the version string for “the release that comes after 3.9” will be. Is there anyone seriously courting the idea that “Python 4.0 is part of the Python 3 line”? I would hope not, yet the above post implies it. Can that be quashed decisively? -- \“If you go parachuting, and your parachute doesn't open, and | `\you friends are all watching you fall, I think a funny gag | _o__) would be to pretend you were swimming.” —Jack Handey | Ben Finney
Re: Python 4 and ‘python3’
Don't panic. :) On Nov 03, 2016, at 09:28 AM, Ben Finney wrote: >But the above post implies that pointless confusion will be directly >courted, merely because of some aesthetic objection to a two-digit >component in the version string. Those are Nick's opinions. Everyone's got one! AFAIK, there is *no* official declaration (e.g. from Guido or the mythical Python 4 release manager) about this either way. >At the current rate of Python releases, it's not very far in the future >before the Python release managers must decide what the version string >for “the release that comes after 3.9” will be. We're up to Python 2.7.12 so the double digit version component ship has sailed and it wasn't all that Y2K-y, so I doubt there will be a hard and fast prohibition against 3.10. Even if there is, we won't see a possible 3.10 until 2022 if I'm doing my math correctly and we stick to the roughly 18 month release cycle. I predict that when the time comes, it'll generate a gigathread's worth of discussion, 3 or 4 competing PEPs, and then Guido will just pronounce. Cheers, -Barry
Re: Packaging new version of ZODB (Zope Object Database)
On Nov 02, 2016, at 10:46 AM, Arnaud Fontaine wrote:
>> I write to debian-python, because some of the involved packages are
>> not specific to Zope. Actually, I even think that ZODB itself is not
>> specific to Zope, but well, changing section of existing packages can
>> be another topic.
>
>This has already been discussed but all the packages in pkg-zope SVN
>repository will have to be moved to python-{modules, apps} repositories
>(because there is almost no activity on pkg-zope and most modules are
>used independently of Zope anyway) and we should use debian-python ML
>for the same reason, so yes, please use debian-python ML and commit
>everything to python-{modules, apps} repositories.
+1. I do still touch some of the ztk packages and would dearly love to ditch
svn, but just haven't had the time to think about a proper migration. Should
we just admit defeat and do on-demand conversions, preserving history if
possible but not worrying about it too much?
And then what about just using gbp and ignoring git-dpm? The latter still
kind of works but we know it's a dead-end. Anybody looked at dgit? Is that
a useful option?
can-of-worms-ly y'rs,
-Barry
pgpgflcDONUfX.pgp
Description: OpenPGP digital signature
Re: Python 4 and ‘python3’
Barry Warsaw writes: > AFAIK, there is *no* official declaration (e.g. from Guido or the > mythical Python 4 release manager) about this either way. In support of your position, Guido van Rossum has informally implied version “3.10” is feasible for a future Python 3 https://twitter.com/gvanrossum/status/583346987925278720>. I had thought GvR expressed a distaste for Semantic Versioning but can't find it now. So, yes, my panic is lessened :-) > I predict that when the time comes, it'll generate a gigathread's > worth of discussion, 3 or 4 competing PEPs, and then Guido will just > pronounce. Hopefully, informed by reasoned argument about consequences, more than aesthetic preferences of a small group (I'm still sore about the process evidenced in the Python VCS decisions, so don't wholly trust this will be better). -- \“With Lisp or Forth, a master programmer has unlimited power | `\ and expressiveness. With Python, even a regular guy can reach | _o__) for the stars.” —Raymond Hettinger | Ben Finney
Re: Packaging new version of ZODB (Zope Object Database)
On November 2, 2016 6:51:56 PM EDT, Barry Warsaw wrote:
>On Nov 02, 2016, at 10:46 AM, Arnaud Fontaine wrote:
>
>>> I write to debian-python, because some of the involved packages
>are
>>> not specific to Zope. Actually, I even think that ZODB itself is
>not
>>> specific to Zope, but well, changing section of existing packages
>can
>>> be another topic.
>>
>>This has already been discussed but all the packages in pkg-zope
>SVN
>>repository will have to be moved to python-{modules, apps}
>repositories
>>(because there is almost no activity on pkg-zope and most modules
>are
>>used independently of Zope anyway) and we should use debian-python
>ML
>>for the same reason, so yes, please use debian-python ML and
>commit
>>everything to python-{modules, apps} repositories.
>
>+1. I do still touch some of the ztk packages and would dearly love to
>ditch
>svn, but just haven't had the time to think about a proper migration.
>Should
>we just admit defeat and do on-demand conversions, preserving history
>if
>possible but not worrying about it too much?
>
>And then what about just using gbp and ignoring git-dpm? The latter
>still
>kind of works but we know it's a dead-end. Anybody looked at dgit? Is
>that
>a useful option?
Dgit and git-dpm are orthogonal. I'd suggest converting the same way we did
DPMT for now and then they'll be included in whatever we migrate to next.
Scott K
Re: Packaging new version of ZODB (Zope Object Database)
Hi, Barry Warsaw writes: > +1. I do still touch some of the ztk packages and would dearly love > to ditch svn, but just haven't had the time to think about a proper > migration. Should we just admit defeat and do on-demand conversions, > preserving history if possible but not worrying about it too much? I haven't had time to work on the migration. On-demand conversion is fine with me. Is there any problem in preserving history while migrating From SVN to Git? Cheers, -- Arnaud Fontaine signature.asc Description: PGP signature
