Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/21 Terry Reedy : > I strongly recommend that where it makes a difference, the pypy python3 > project target 3.3. In particular, don't reproduce the buggy narrow-build > behavior of 3.2 and before (perhaps pypy avoids this already). Do include > the new unicode capi in cpyext. I anticipate that 3.3 will see more > production use than 3.2 Is there a reason in particular? --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyUnicode_EncodeDecimal
Victor Stinner wrote: > > Should we document and test it, leave it unchanged and > > deprecate it, or simply remove it? > > If we change PyUnicode_EncodeDecimal() to reject error handlers different > than > strict, we can keep this function for some release and deprecate it. The > function is already deprecated beacuse it uses the deprecated Py_UNICODE type. I'd be fine with removing the function in 3.4. For consistency, it might be better to remove it in 4.0 together with all the other deprecated functions (at least I understood that this was the plan). Stefan Krah ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyUnicode_EncodeDecimal
Le mardi 22 novembre 2011 02:02:05, Victor Stinner a écrit : > This function is broken by design if an error handler is specified: the > caller cannot know the size of the output buffer, whereas the caller has > to allocate this buffer. > > I propose to raise an error if an error handler (different than "strict") > is specified) and do this change in Python 2.7, 3.2 and 3.3. > > In Python 2.7 code base, PyUnicode_EncodeDecimal() is always called with > errors=NULL. In Python 3.x, the function is no more called. I opened the following issue for this point: http://bugs.python.org/issue13452 Victor ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
Giampaolo Rodolà, 22.11.2011 10:21: 2011/11/21 Terry Reedy: I strongly recommend that where it makes a difference, the pypy python3 project target 3.3. In particular, don't reproduce the buggy narrow-build behavior of 3.2 and before (perhaps pypy avoids this already). Do include the new unicode capi in cpyext. I anticipate that 3.3 will see more production use than 3.2 Is there a reason in particular? Well, Py3 still has a lot to catch up in terms of wide spread distribution compared to Py2.x, and new users will usually start using the most up to date release, which will soon be 3.3. Besides, 3.3 has received various optimisations that make it more suitable for production use than 3.2, including the above mentioned Unicode optimisations. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyUnicode_Resize
2011/11/22 Victor Stinner > Hi, > > In Python 3.2, PyUnicode_Resize() expects a number of Py_UNICODE units, > whereas Python 3.3 expects a number of characters. > > It is tricky to convert a number of Py_UNICODE units to a number of > characters, so it is diffcult to provide a backward compatibility > PyUnicode_Resize() function taking a number of Py_UNICODE units in Python > 3.3. > > Should we rename PyUnicode_Resize() in Python 3.3 to avoid surprising bugs? > > The issue only concerns Windows with non-BMP characters, so a very rare use > case. > > The easiest solution is to do nothing in Python 3.3: the API changed, but > it > doesn't really matter. Developers just have to be careful on this > particular > issue (which is not well documented today). > +1. A note in the "Porting C code" section of whatsnew/3.3 should be enough. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel wrote: > Giampaolo Rodolà, 22.11.2011 10:21: >> >> 2011/11/21 Terry Reedy: >>> >>> I strongly recommend that where it makes a difference, the pypy python3 >>> project target 3.3. In particular, don't reproduce the buggy narrow-build >>> behavior of 3.2 and before (perhaps pypy avoids this already). Do include >>> the new unicode capi in cpyext. I anticipate that 3.3 will see more >>> production use than 3.2 >> >> Is there a reason in particular? > > Well, Py3 still has a lot to catch up in terms of wide spread distribution > compared to Py2.x, and new users will usually start using the most up to > date release, which will soon be 3.3. > > Besides, 3.3 has received various optimisations that make it more suitable > for production use than 3.2, including the above mentioned Unicode > optimisations. > > Stefan > PyPy's py3k branch targets Python 3.2 until 3.3 is released and very likely 3.3 afterwards. Optimizations are irrelevant really in the case of PyPy. Cheers, fijal ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 02:15 PM, Stefan Behnel wrote: >Well, Py3 still has a lot to catch up in terms of wide spread distribution >compared to Py2.x, and new users will usually start using the most up to date >release, which will soon be 3.3. > >Besides, 3.3 has received various optimisations that make it more suitable >for production use than 3.2, including the above mentioned Unicode >optimisations. 3.3 won't be released (according to PEP 398's current schedule) until August of next year. I think that's too long to wait before pushing for widespread adoption of Python 3. Hopefully, we're going to be making a dent in that in the next version of Ubuntu. We're actively starting to port a handful of desktop applications (including their dependency stacks) to Python 3.2, which I think is a fine release for doing so. I owe a blog post about this, but please do contact me if you want to get involved. Cheers, -Barry ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
Maciej Fijalkowski, 22.11.2011 15:46: On Tue, Nov 22, 2011 at 3:15 PM, Stefan Behnel wrote: Giampaolo Rodolà, 22.11.2011 10:21: 2011/11/21 Terry Reedy: I strongly recommend that where it makes a difference, the pypy python3 project target 3.3. In particular, don't reproduce the buggy narrow-build behavior of 3.2 and before (perhaps pypy avoids this already). Do include the new unicode capi in cpyext. I anticipate that 3.3 will see more production use than 3.2 Is there a reason in particular? Well, Py3 still has a lot to catch up in terms of wide spread distribution compared to Py2.x, and new users will usually start using the most up to date release, which will soon be 3.3. Besides, 3.3 has received various optimisations that make it more suitable for production use than 3.2, including the above mentioned Unicode optimisations. Note that I was referring to Terry's "more production use" comment here, not to the "PyPy should target 3.3 instead of 3.2" part. PyPy's py3k branch targets Python 3.2 until 3.3 is released and very likely 3.3 afterwards. Optimizations are irrelevant really in the case of PyPy. I admit that I wasn't very clear in my wording. As Terry pointed out, the Unicode changes in Py3.3 are not only for speed and/or memory performance improvements, they also improve the compliance of the Unicode implementation, which implies a behavioural change. Since PyPy appears to have implemented the current wide/narrow behaviour of Py2 and Py3.[012] already, I see no reason not to target 3.2 for the time being as it does not require substantial changes in this part. Compliance with Py3.3 will then require implementing the new behaviour. Stefan ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix wrong credit and issue id given in previous commit
On Tue, 22 Nov 2011 13:38:03 +0100 giampaolo.rodola wrote: > diff --git a/Misc/ACKS b/Misc/ACKS > --- a/Misc/ACKS > +++ b/Misc/ACKS > @@ -11,7 +11,7 @@ > PS: In the standard Python distribution, this file is encoded in UTF-8 > and the list is in rough alphabetical order by last names. > > -Matt Mulsow > +Chris Clark > Rajiv Abraham "The list is in rough alphabetical order by last names". Regarfs Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
Barry Warsaw writes: > Hopefully, we're going to be making a dent in that in the next version of > Ubuntu. This is still a big mess in Gentoo and MacPorts, though. MacPorts hasn't done anything about ceating a transition infrastructure AFAICT. Gentoo has its "eselect python set VERSION" stuff, but it's very dangerous to set to a Python 3 version, as many things go permanently wonky once you do. (So far I've been able to work around problems this creates, but it's not much fun.) I have no experience with this in Debian, Red Hat (and derivatives) or *BSD, but I have to suspect they're no better. (Well, maybe Red Hat has learned from its 1.5.2 experience! :-) I don't have any connections to the distros, so can't really offer to help directly. I think it might be a good idea for users to lobby (politely!) their distros to work on the transition. > I owe a blog post about this, but please do contact me if you want > to get involved. Yes, please, to the blog post! ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: > Barry Warsaw writes: >> Hopefully, we're going to be making a dent in that in the next version of >> Ubuntu. > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > hasn't done anything about ceating a transition infrastructure AFAICT. What kind of "transition infrastructure" would it need? It's definitely not going to replace the Apple-provided Python out of the box, so setting `python` to a python3 is not going to happen. It doesn't define a `python3`, so maybe that? Is there a document somewhere on what kind of things distros need for a transition plan? > Gentoo has its "eselect python set VERSION" stuff, but it's very > dangerous to set to a Python 3 version, as many things go permanently > wonky once you do. (So far I've been able to work around problems > this creates, but it's not much fun.) Macports provide `port select` which I believe has the same function (you need to install the `python_select` for it to be configured for the Python group), the syntax is port `select --set python $VERSION`: > python --version Python 2.6.1 > sudo port select --set python python32 Selecting 'python32' for 'python' succeeded. 'python32' is now active. > python --version Python 3.2.2 ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Wed, Nov 23, 2011 at 01:41:46AM +0900, Stephen J. Turnbull wrote: > Barry Warsaw writes: > > > Hopefully, we're going to be making a dent in that in the next version of > > Ubuntu. > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > hasn't done anything about ceating a transition infrastructure AFAICT. > Gentoo has its "eselect python set VERSION" stuff, but it's very > dangerous to set to a Python 3 version, as many things go permanently > wonky once you do. (So far I've been able to work around problems > this creates, but it's not much fun.) I have no experience with this > in Debian, Red Hat (and derivatives) or *BSD, but I have to suspect > they're no better. (Well, maybe Red Hat has learned from its 1.5.2 > experience! :-) > For Fedora (and currently, Red Hat is based on Fedora -- a little more about that later, though), we have parallel python2 and python3 stacks. As time goes on we've slowly brought more python-3 compatible modules onto the python3 stack (I believe someone had the goal a year and a half ago to get a complete pylons web development stack running on python3 on Fedora which brought a lot of packages forward). Unlike Barry's work with Ubuntu, though, we're mostly chiselling around the edges; we're working at the level where there's a module that someone needs to run something (or run some optional features of something) that runs on python3. > I don't have any connections to the distros, so can't really offer to > help directly. I think it might be a good idea for users to lobby > (politely!) their distros to work on the transition. > Where distros aren't working on parallel stacks, there definitely needs to be some transition plan. With my experience with parallel stacks, the best help there is to 1) help upstreams port to py3k (If someone can get PIL's py3k support finished and into a released package, that would free up a few things). 2) open bugs or help with creating python3 packages of modules when the upstream support is there. Depending on what software Barry's talking about porting to python3, that could be a big incentive as well. Just like with the push in Fedora to have pylons run on python3, I think that having certain applications that run on python3 and therefore need to have stacks of modules that support it is one of the prime ways that distros become motivated to provide python3 packages and support. This is basically the "killer app" idea in a new venue :-) -Toshio pgp4H9ogaSy0g.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Tue, 2011-11-22 at 09:13 -0800, Toshio Kuratomi wrote: > On Wed, Nov 23, 2011 at 01:41:46AM +0900, Stephen J. Turnbull wrote: > > Barry Warsaw writes: > > > > > Hopefully, we're going to be making a dent in that in the next version of > > > Ubuntu. > > > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > > hasn't done anything about ceating a transition infrastructure AFAICT. > > Gentoo has its "eselect python set VERSION" stuff, but it's very > > dangerous to set to a Python 3 version, as many things go permanently > > wonky once you do. (So far I've been able to work around problems > > this creates, but it's not much fun.) I have no experience with this > > in Debian, Red Hat (and derivatives) or *BSD, but I have to suspect > > they're no better. (Well, maybe Red Hat has learned from its 1.5.2 > > experience! :-) > > > For Fedora (and currently, Red Hat is based on Fedora -- a little more about > that later, though), we have parallel python2 and python3 stacks. As time > goes on we've slowly brought more python-3 compatible modules onto the > python3 stack (I believe someone had the goal a year and a half ago to get > a complete pylons web development stack running on python3 on Fedora which > brought a lot of packages forward). FWIW, current status of Fedora's Python 3 stack can be seen here: http://fedoraproject.org/wiki/Python3 and that page may be of interest to other distributions - I know of at least one other distribution that's screen-scraping it ;) ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix wrong credit and issue id given in previous commit
Sorry, thanks (fixed). --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/11/22 Antoine Pitrou : > On Tue, 22 Nov 2011 13:38:03 +0100 > giampaolo.rodola wrote: >> diff --git a/Misc/ACKS b/Misc/ACKS >> --- a/Misc/ACKS >> +++ b/Misc/ACKS >> @@ -11,7 +11,7 @@ >> PS: In the standard Python distribution, this file is encoded in UTF-8 >> and the list is in rough alphabetical order by last names. >> >> -Matt Mulsow >> +Chris Clark >> Rajiv Abraham > > "The list is in rough alphabetical order by last names". > > Regarfs > > Antoine. > > > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: sort last committed name in alphabetical order
Did you mean to also modify sched.py in this changeset? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On Nov 22, 2011, at 7:35 AM, Stefan Behnel wrote: > Maciej Fijalkowski, 22.11.2011 15:46: >> PyPy's py3k branch targets Python 3.2 until 3.3 is released and very >> likely 3.3 afterwards. Optimizations are irrelevant really in the case >> of PyPy. > > I admit that I wasn't very clear in my wording. As Terry pointed out, the > Unicode changes in Py3.3 are not only for speed and/or memory performance > improvements, they also improve the compliance of the Unicode implementation, > which implies a behavioural change. Since PyPy appears to have implemented > the current wide/narrow behaviour of Py2 and Py3.[012] already, I see no > reason not to target 3.2 for the time being as it does not require > substantial changes in this part. Compliance with Py3.3 will then require > implementing the new behaviour. One reason to target 3.2 for now is it's not a moving target. There's overhead involved in managing modifications to the pure python standard lib needed for PyPy, tracking 3.3 changes as they happen as well exacerbates this. The plans to split the standard lib into its own repo separate from core CPython will of course help alternative implementations here. -- Philip Jenvey ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix wrong credit and issue id given in previous commit
Hi, 2011/11/22 Giampaolo Rodolà > Sorry, thanks (fixed). > You also modified Lib/sched.py in the same commit. Was it intended? If not, please revert it. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/22 Philip Jenvey > One reason to target 3.2 for now is it's not a moving target. There's > overhead involved in managing modifications to the pure python standard lib > needed for PyPy, tracking 3.3 changes as they happen as well exacerbates > this. > > The plans to split the standard lib into its own repo separate from core > CPython will of course help alternative implementations here. > I don't see how it would help here. Copying the CPython Lib/ directory is not difficult, even though PyPy made slight modifications to the files, and even without any merge tool. OTOH when PyPy changed minor versions (from 2.7.0 to 2.7.2 IIRC) most of the work was to follow the various tiny fixes made to the built-in modules: _io, _ssl and _multiprocessing. -- Amaury Forgeot d'Arc ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
On Tue, 22 Nov 2011 21:29:43 +0100
benjamin.peterson wrote:
> http://hg.python.org/cpython/rev/77ab830930ae
> changeset: 73697:77ab830930ae
> user:Benjamin Peterson
> date:Tue Nov 22 15:29:32 2011 -0500
> summary:
> fix compiler warning by implementing this more cleverly
You mean "more obscurely"?
Obfuscating the original intent in order to disable a compiler warning
doesn't seem very wise to me.
Regards
Antoine.
> files:
> Objects/unicodeobject.c | 7 +--
> 1 files changed, 1 insertions(+), 6 deletions(-)
>
>
> diff --git a/Objects/unicodeobject.c b/Objects/unicodeobject.c
> --- a/Objects/unicodeobject.c
> +++ b/Objects/unicodeobject.c
> @@ -6164,12 +6164,7 @@
> kind = PyUnicode_KIND(unicode);
> data = PyUnicode_DATA(unicode);
> len = PyUnicode_GET_LENGTH(unicode);
> -
> -switch(kind) {
> -case PyUnicode_1BYTE_KIND: expandsize = 4; break;
> -case PyUnicode_2BYTE_KIND: expandsize = 6; break;
> -case PyUnicode_4BYTE_KIND: expandsize = 10; break;
> -}
> +expandsize = kind * 2 + 2;
>
> if (len > PY_SSIZE_T_MAX / expandsize)
> return PyErr_NoMemory();
>
> --
> Repository URL: http://hg.python.org/cpython
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
2011/11/22 Antoine Pitrou : > On Tue, 22 Nov 2011 21:29:43 +0100 > benjamin.peterson wrote: >> http://hg.python.org/cpython/rev/77ab830930ae >> changeset: 73697:77ab830930ae >> user: Benjamin Peterson >> date: Tue Nov 22 15:29:32 2011 -0500 >> summary: >> fix compiler warning by implementing this more cleverly > > You mean "more obscurely"? > Obfuscating the original intent in order to disable a compiler warning > doesn't seem very wise to me. Well, I think it makes sense that the kind tells you how many bytes are in it. -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Nov 22, 2011, at 09:13 AM, Toshio Kuratomi wrote: >For Fedora (and currently, Red Hat is based on Fedora -- a little more about >that later, though), we have parallel python2 and python3 stacks. Debian (and thus Ubuntu) also has separate Python 2 and 3 stacks. In general, if you have a Python package (e.g. on PyPI) called 'foo', you'll have a Debian binary package called python-foo for the Python 2 version, and python3-foo for the Python 3 version. /usr/bin/python will always (modulo perhaps PEP 394) point to Python 2.x with Python 3 accessible via /usr/bin/python3. The minor version numbered Python binaries are also available. Debian's infrastructure makes it fairly easy to support multiple versions of Python at the same time, and of course to support both a Python 2 and 3 stack simultaneously. It's also fairly easy to switch the default Python version. Binary packages containing pure-Python are space efficient, sharing one copy of the Python source code for all supported versions. A symlink farm is used to manage the incompatibilities in .pyc files, but only for Python 2, since PEPs 3147 and 3149 solve this problem in a better way for Python 3 (no symlink farms necessary). The one additional complication though is that extension modules must be built for each supported version, and all .so's are included in a single binary package. E.g. if python-foo has an extension module, it will contain the 2.6 .so and the 2.7 .so. For the next version of Ubuntu, we will be dropping Python 2.6 support, so our binary packages are rebuilt to contain only the 2.7 version of the extension module. Details on how Debian packages Python, including its deviations from upstream, are available here: http://wiki.debian.org/Python Ubuntu's deviations from Debian and other details are available here: https://wiki.ubuntu.com/Python >Unlike Barry's work with Ubuntu, though, we're mostly chiselling around the >edges; we're working at the level where there's a module that someone needs >to run something (or run some optional features of something) that runs on >python3. This is great, because it means Fedora's taking kind of a bottom-up approach, while Ubuntu is taking a more top-down approach. Working together, we'll change the world. :) The key here is that we push as many of the changes as possible as far upstream as possible. I know Toshio and David agree, we want to get upstream package authors and application developers to support Python 3 as much as possible. I hope there will be no cases where a distro has to fork a package or application to support Python 3, although we will do it if there's no other way. Most likely for Ubuntu though, that would be pushing the changes into Debian. >Where distros aren't working on parallel stacks, there definitely needs to >be some transition plan. With my experience with parallel stacks, the best >help there is to 1) help upstreams port to py3k (If someone can get PIL's >py3k support finished and into a released package, that would free up a few >things). 2) open bugs or help with creating python3 packages of modules >when the upstream support is there. +1 >Depending on what software Barry's talking about porting to python3, that >could be a big incentive as well. Just like with the push in Fedora to have >pylons run on python3, I think that having certain applications that run on >python3 and therefore need to have stacks of modules that support it is one >of the prime ways that distros become motivated to provide python3 packages >and support. This is basically the "killer app" idea in a new venue :-) Again, wholehearted +1. For now, we are not spending much time on server applications, though I've seen promising talk about Twisted ports to Python 3. We're looking specifically at desktop applications, such as Update Manager, Software Center, Computer Janitor, etc. Those may be fairly Ubuntu and/or Debian specific, but the actual applications themselves aren't too difficult to port. E.g. switching to Gnome object introspection, which already supports Python 3. We can easily identify the dependency stack for the desktop applications we're targeting, which leads us to looking at ports of the dependent libraries, and that benefits all Python users. Our goal is for the Ubuntu 14.04 LTS release (in April 2014) to have no Python 2 on the release images, or in our "main" archive, so everything you'd get on your desktop in a default install would be Python 3. For the upcoming 12.04 LTS release, I'd be happy if we had just a couple of Python 3 applications on the desktop by default. I see the work going on in Fedora/RedHat, Debian/Ubuntu, and other distributions as applying some positive momentum on pushing the Python community over the tipping point for Python 3 support. Cheers, -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailma
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On Nov 22, 2011, at 06:10 PM, Xavier Morel wrote: >It's definitely not going to replace the Apple-provided Python out of the >box, so setting `python` to a python3 is not going to happen. Nor should it! PEP 394 attempts to codify the Python project's recommendations for what version 'python' (e.g. /usr/bin/python) points to, but I think there is widespread agreement that it would be a mistake to point it at Python 3. >It doesn't define a `python3`, so maybe that? Is there a document >somewhere on what kind of things distros need for a transition plan? This is probably fairly distro specific, so I doubt any such document exists, or would be helpful. E.g. Debian's approach is fairly intimately tied to its build tools, rules files, and policies. There is, in fact, a separate Python policy document for Debian. What this means for Debian is that well-behaved distutils-based packages can be built for all available Python 2 versions with about 3 lines of code in your debian/rules file. You don't even really need to think about it, which is especially nice during Python version transitions. Of course, in Ubuntu, we'll never have to do one of those again . The tools are not quite there for Python 3, though they are being actively worked on. This means it takes more effort from the distro packager to get Python 2 and Python 3 binary packages built (assuming upstream supports both), and to built it for multiple versions of Python 3 (not an issue right now though, since 3.2 is the minimum version we're all targeting). It's definitely possible, but it's not as trivially easy as it usually is for Python 2. I fully expect that to improve over time. I do occasionally fiddle with MacPorts, and have used Gentoo's system in a previous life, but I don't really know enough about them to make anything other than general recommendations. OTOH, I think Fedora's and Debian's experience is that separate Python 2 and Python 3 stacks is the best way to avoid insanity for operating systems and their users. -Barry signature.asc Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On 11/22/2011 10:35 AM, Stefan Behnel wrote: Maciej Fijalkowski, 22.11.2011 15:46: 2011/11/21 Terry Reedy: I strongly recommend that where it makes a difference, the pypy python3 project target 3.3. In particular, don't reproduce the buggy narrow-build behavior of 3.2 and before (perhaps pypy avoids this already). Do include the new unicode capi in cpyext. I anticipate that 3.3 will see more production use than 3.2 [snip} PyPy's py3k branch targets Python 3.2 until 3.3 is released and very likely 3.3 afterwards. Optimizations are irrelevant really in the case of PyPy. I admit that I wasn't very clear in my wording. As Terry pointed out, the Unicode changes in Py3.3 are not only for speed and/or memory performance improvements, they also improve the compliance of the Unicode implementation, which implies a behavioral change. One of the major features of Python 3 is the expansion of the directly supported character set from ascii to unicode. Python's original narrow and wide build unicode implementation has problems that were somewhat tolerable in an optional, alternate text class but which are much less so for *the* text class. The general problem is that the two builds give different answers for operations and functions on strings containing non-BMP characters. This differences potentially affects anything that uses strings, such as the re module, without guarding against the differences. One can view the narrow build results as wrong and buggy. Extended chars were practically non-existent when the implementation was written, but are becoming more common now and in the future. In any case, Python string code no longer works the same across all x.y builds. On *nix platforms that can have both narrow and wide builds, there can also be binary conflicts for extension modules. On Windows, there is no conflict because one is stuck with a buggy narrow build. This is all besides the space issue. In my view, Python 3.3 will be the first fully satisfactory Python 3 version. It should be the version of choice for any app doing full unicode text or document processing on platforms that include, in particular, Windows. > Since PyPy appears to have implemented the current wide/narrow behavior of Py2 and Py3.[012] already, I see no reason not to target 3.2 for the time being as it does not require substantial changes in this part. Compliance with Py3.3 will then require implementing the new behavior. Thinking about how PyPy will do that should start well before 3.3 is released. My impression from reading the PyPy and Python 3 page, linked in the original post, is that releasing PyPy fully ready for Python 3, with all listed phases completed, will take close to a year anyway. Hence my comment. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
On 11/22/2011 3:28 PM, Philip Jenvey wrote:
One reason to target 3.2 for now is it's not a moving target.
Neither is the basic design and behavior of the new unicode
implementation. On 3.2 narrow builds, including Windows
>>> len('\U00010101')
2
With 3.3, the answer will be, properly, 1. I suspect that becoming
compatible with that, and all that it implies for many other examples,
will be the biggest hurdle for PyPy becoming compatible with 3.3.
--
Terry Jan Reedy
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: sort last committed name in alphabetical order
Nope, the commit involving sched was the previous one. This one was just an unrelated fix. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/11/22 Nadeem Vawda : > Did you mean to also modify sched.py in this changeset? > ___ > Python-Dev mailing list > [email protected] > http://mail.python.org/mailman/listinfo/python-dev > Unsubscribe: > http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] [Python-checkins] cpython: sort last committed name in alphabetical order
You're right. I committed sched.py by accident. I'm going to revert it. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ 2011/11/22 Giampaolo Rodolà : > Nope, the commit involving sched was the previous one. > This one was just an unrelated fix. > > --- Giampaolo > http://code.google.com/p/pyftpdlib/ > http://code.google.com/p/psutil/ > > > 2011/11/22 Nadeem Vawda : >> Did you mean to also modify sched.py in this changeset? >> ___ >> Python-Dev mailing list >> [email protected] >> http://mail.python.org/mailman/listinfo/python-dev >> Unsubscribe: >> http://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com >> > ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix wrong credit and issue id given in previous commit
2011/11/22 Amaury Forgeot d'Arc : > Hi, > 2011/11/22 Giampaolo Rodolà >> >> Sorry, thanks (fixed). > > You also modified Lib/sched.py in the same commit. > Was it intended? If not, please revert it. > -- > Amaury Forgeot d'Arc You're right. I committed sched.py by accident. I'm going to revert it. --- Giampaolo http://code.google.com/p/pyftpdlib/ http://code.google.com/p/psutil/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] PyPy 1.7 - widening the sweet spot
2011/11/22 Terry Reedy
> On 11/22/2011 3:28 PM, Philip Jenvey wrote:
>
> One reason to target 3.2 for now is it's not a moving target.
>>
>
> Neither is the basic design and behavior of the new unicode
> implementation. On 3.2 narrow builds, including Windows
>
> >>> len('\U00010101')
> 2
>
> With 3.3, the answer will be, properly, 1. I suspect that becoming
> compatible with that, and all that it implies for many other examples, will
> be the biggest hurdle for PyPy becoming compatible with 3.3.
PyPy currently defines unicode as arrays of wchar_t, so only Windows uses a
narrow unicode build.
It will probably change though, and for performance reasons it makes indeed
sense to have different internal representations for the same external type.
PyPy already does this for several types (there is a special version of
dict specialized for string keys, and the 2.7 range() returns a list that
does not need to allocate its items, and can turn into a "real" list as
soon as you modify it), so I would not qualify this task as a big hurdle,
compared to other optimizations done in similar areas.
--
Amaury Forgeot d'Arc
___
Python-Dev mailing list
[email protected]
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
On Tue, 22 Nov 2011 16:42:35 -0500 Benjamin Peterson wrote: > 2011/11/22 Antoine Pitrou : > > On Tue, 22 Nov 2011 21:29:43 +0100 > > benjamin.peterson wrote: > >> http://hg.python.org/cpython/rev/77ab830930ae > >> changeset: 73697:77ab830930ae > >> user: Benjamin Peterson > >> date: Tue Nov 22 15:29:32 2011 -0500 > >> summary: > >> fix compiler warning by implementing this more cleverly > > > > You mean "more obscurely"? > > Obfuscating the original intent in order to disable a compiler warning > > doesn't seem very wise to me. > > Well, I think it makes sense that the kind tells you how many bytes are in it. Yes, but "kind * 2 + 2" looks like a magical formula, while the explicit switch let you check mentally that each estimate was indeed correct. Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
2011/11/22 Antoine Pitrou : > On Tue, 22 Nov 2011 16:42:35 -0500 > Benjamin Peterson wrote: >> 2011/11/22 Antoine Pitrou : >> > On Tue, 22 Nov 2011 21:29:43 +0100 >> > benjamin.peterson wrote: >> >> http://hg.python.org/cpython/rev/77ab830930ae >> >> changeset: 73697:77ab830930ae >> >> user: Benjamin Peterson >> >> date: Tue Nov 22 15:29:32 2011 -0500 >> >> summary: >> >> fix compiler warning by implementing this more cleverly >> > >> > You mean "more obscurely"? >> > Obfuscating the original intent in order to disable a compiler warning >> > doesn't seem very wise to me. >> >> Well, I think it makes sense that the kind tells you how many bytes are in >> it. > > Yes, but "kind * 2 + 2" looks like a magical formula, while the > explicit switch let you check mentally that each estimate was indeed > correct. I don't see how it's more magic than hardcoding 4, 6, and 10. Don't you have to mentally check that those are correct? -- Regards, Benjamin ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
On Tue, 22 Nov 2011 19:42:24 -0500 Benjamin Peterson wrote: > 2011/11/22 Antoine Pitrou : > > On Tue, 22 Nov 2011 16:42:35 -0500 > > Benjamin Peterson wrote: > >> 2011/11/22 Antoine Pitrou : > >> > On Tue, 22 Nov 2011 21:29:43 +0100 > >> > benjamin.peterson wrote: > >> >> http://hg.python.org/cpython/rev/77ab830930ae > >> >> changeset: 73697:77ab830930ae > >> >> user: Benjamin Peterson > >> >> date: Tue Nov 22 15:29:32 2011 -0500 > >> >> summary: > >> >> fix compiler warning by implementing this more cleverly > >> > > >> > You mean "more obscurely"? > >> > Obfuscating the original intent in order to disable a compiler warning > >> > doesn't seem very wise to me. > >> > >> Well, I think it makes sense that the kind tells you how many bytes are in > >> it. > > > > Yes, but "kind * 2 + 2" looks like a magical formula, while the > > explicit switch let you check mentally that each estimate was indeed > > correct. > > I don't see how it's more magic than hardcoding 4, 6, and 10. Don't > you have to mentally check that those are correct? I don't know. Perhaps I'm saying that because I *have* already done the mental check :) Regards Antoine. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
[Python-Dev] Python 3.4 Release Manager
I've volunteered to be the Release Manager for Python 3.4. The FLUFL has already given it his Sloppy Wet Kiss Of Approval, and we talked to Georg and he was for it too. There's no formal process for selecting the RM, so I may already be stuck with the job, but I thought it best to pipe up on python-dev in case someone had a better idea. But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that? Needs work? I look forward to seeing how the sausage is made, /larry/ ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
Xavier Morel writes: > On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: > > Barry Warsaw writes: > >> Hopefully, we're going to be making a dent in that in the next version of > >> Ubuntu. > > This is still a big mess in Gentoo and MacPorts, though. MacPorts > > hasn't done anything about ceating a transition infrastructure AFAICT. > What kind of "transition infrastructure" would it need? It's definitely > not going to replace the Apple-provided Python out of the box, so > setting `python` to a python3 is not going to happen. Sure, but many things do shadow Apple-provided software if you set PATH=/opt/local/bin:$PATH. I'm not sure what infrastructure is required, but I can't really see MacPorts volunteers doing a 100% conversion the way that Ubuntu's paid developers can. So there will be a long transition period, and I wouldn't be surprised if multiple versions of Python 2 and multiple versions of Python 3 will typically need to be simultaneously available to different ports. > It doesn't define a `python3`, so maybe that? A python3 symlink or script would help a little bit, but I don't think that's necessary or sufficient, because ports already can and do depend on Python x.y, not just Python x. > Is there a document somewhere on what kind of things distros need > for a transition plan? I'm hoping Barry's blog will be a good start. > Macports provide `port select` which I believe has the same function > (you need to install the `python_select` for it to be configured for > the Python group), the syntax is port `select --set python $VERSION`: Sure. I haven't had the nerve to do this on MacPorts because "port" is such a flaky thing (not so much port itself, but so many ports assume that the port maintainer's local configuration is what others' systems use, so I stay as vanilla as possible -- I rather doubt that many ports are ready for Python 3, and I'm not willing to be a guinea pig). The problem that I've run into with Gentoo is that *even when the ebuild is prepared for Python 3* assumptions about the Python current when the ebuild is installed/upgraded gets baked into the installation (eg, print statement vs. print function), but some of the support scripts just call "python" or something like that. OTOH, a few ebuilds don't support Python 3 (or in a ebuild that nominally supports Python 3, upstream does something perfectly reasonable for Python 2 like assume that Latin-1 characters are acceptable in a ChangeLog, and the ebuild maintainer doesn't test under Python 3 so it slips through) so I have to do an eselect dance while emerging ... and in the meantime things that expect Python 3 as the system Python break. So far, in Gentoo I've always been able to wiggle out of such problems by doing the eselect dance two or three times with the ebuild that is outdated, and then a couple of principal prerequisites or dependencies at most. Given my experience with MacPorts I *very much* expect similar issues with its ports. ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Nov 22, 2011, at 7:50 PM, Larry Hastings wrote: > > > I've volunteered to be the Release Manager for Python 3.4. Awesome. Thanks for stepping up. > The FLUFL has already given it his Sloppy Wet Kiss Of Approval, E! > and we talked to Georg and he was for it too. There's no formal process for > selecting the RM, so I may already be stuck with the job, but I thought it > best to pipe up on python-dev in case someone had a better idea. > > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that? > Needs work? You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE THE RM FOR PYTHON 3.5 WILL LOVE IT ;-) Raymond ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Tue, Nov 22, 2011 at 08:27:24PM -0800, Raymond Hettinger wrote: > > On Nov 22, 2011, at 7:50 PM, Larry Hastings wrote: > > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that? > > Needs work? > > You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE > THE RM FOR PYTHON 3.5 WILL LOVE IT ;-) > Wow! My release engineering team needs to take classes from you guys! -Toshio pgpuU9lyX1YFu.pgp Description: PGP signature ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Tue, 22 Nov 2011 20:27:24 -0800 Raymond Hettinger wrote: > > > > But look! I'm already practicing: NO YOU CAN'T CHECK THAT IN. How's that? > > Needs work? > > You could try a more positive leadership style: THAT LOOKS GREAT, I'M SURE > THE RM FOR PYTHON 3.5 WILL LOVE IT ;-) How about: PHP 5.5 IS NOW OPEN FOR COMMIT ? ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Wed, Nov 23, 2011 at 11:50 AM, Larry Hastings wrote: > I've volunteered to be the Release Manager for Python 3.4. The FLUFL has That's cool. But just my thought, wouldn't it be better for someone who regularly commits, fixes bugs and feature requests be better for a RM role? Once a developer gets bored with those and wants more, could take up RM role. Is there anything wrong with this kind of thinking? Thanks, Senthil ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Python 3.4 Release Manager
On Wed, Nov 23, 2011 at 2:50 PM, Senthil Kumaran wrote: > On Wed, Nov 23, 2011 at 11:50 AM, Larry Hastings wrote: >> I've volunteered to be the Release Manager for Python 3.4. The FLUFL has > > That's cool. But just my thought, wouldn't it be better for someone > who regularly commits, fixes bugs and feature requests be better for a > RM role? Once a developer gets bored with those and wants more, could > take up RM role. Is there anything wrong with this kind of thinking? The main (thoroughly informal) criteria are having commit privileges, having shown some evidence of "getting it" when it comes to the release process and then actually putting your hand up to volunteer. Most people who pass the second criterion seem to demonstrate this odd reluctance to meet the third criterion ;) There's probably a fourth criterion of the other devs not going "Arrg, no, not *them*!", but, to my knowledge, that's never actually come up... I'm sure Larry will now be paying close attention as Georg shepherds 3.3 towards release next year, so it sounds like a perfectly reasonable idea to me. +1 Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
On 11/22/2011 7:42 PM, Benjamin Peterson wrote: 2011/11/22 Antoine Pitrou: On Tue, 22 Nov 2011 16:42:35 -0500 Benjamin Peterson wrote: 2011/11/22 Antoine Pitrou: On Tue, 22 Nov 2011 21:29:43 +0100 benjamin.peterson wrote: http://hg.python.org/cpython/rev/77ab830930ae changeset: 73697:77ab830930ae user:Benjamin Peterson date:Tue Nov 22 15:29:32 2011 -0500 summary: fix compiler warning by implementing this more cleverly You mean "more obscurely"? Obfuscating the original intent in order to disable a compiler warning doesn't seem very wise to me. Well, I think it makes sense that the kind tells you how many bytes are in it. Yes, but "kind * 2 + 2" looks like a magical formula, while the explicit switch let you check mentally that each estimate was indeed correct. I don't see how it's more magic than hardcoding 4, 6, and 10. Don't you have to mentally check that those are correct? I personally strongly prefer the one-line formula to the hardcoded magic numbers calculated from the formula. I find it much more readable. To me, the only justification for the switch would be if there is a serious worry about the kind being changed to something other than 1, 2, or 4. But the fact that this is checked with an assert that can be optimized away negates that. The one-liner could be followed by assert(kind==1 || kind==2 || kind==4) which would also serve to remind the reader of the possibilities. You could even follow the formula with /* 4, 6, or 10 */ I think you reverted too soon. -- Terry Jan Reedy ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] cpython: fix compiler warning by implementing this more cleverly
On Wed, Nov 23, 2011 at 4:49 PM, Terry Reedy wrote: > I personally strongly prefer the one-line formula to the hardcoded magic > numbers calculated from the formula. I find it much more readable. To me, > the only justification for the switch would be if there is a serious worry > about the kind being changed to something other than 1, 2, or 4. But the > fact that this is checked with an assert that can be optimized away negates > that. The one-liner could be followed by > assert(kind==1 || kind==2 || kind==4) > which would also serve to remind the reader of the possibilities. You could > even follow the formula with /* 4, 6, or 10 */ I think you reverted too > soon. +1 to what Terry said here, although I would add a genuinely explanatory comment that gives the calculation meaning: /* For each character, allow for "\U" prefix and 2 hex digits per byte */ expandsize = 2 + 2 * kind; Cheers, Nick. -- Nick Coghlan | [email protected] | Brisbane, Australia ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
In article <[email protected]>, "Stephen J. Turnbull" wrote: > I haven't had the nerve to do this on MacPorts because "port" is such > a flaky thing (not so much port itself, but so many ports assume that > the port maintainer's local configuration is what others' systems use, > so I stay as vanilla as possible -- I rather doubt that many ports are > ready for Python 3, and I'm not willing to be a guinea pig). I think your fears are unfounded. MacPort's individual port files are supposed to be totally independent of the setting of 'port select'. In other words, there are separate ports for each Python version, i.e. py24-distribute, py25-distribute, py26-distribute, py27-distribute, py31-distribute, and py32-distribute. Or, for ports that are not principally Python packages, there may be port variants, i.e. +python27, +python32, etc. If you do find a port that somewhere uses an unversioned 'python', you should report it as a bug; they will fix that. Also, fairly recently, the MacPorts introduced a python ports group infrastructure behind the scenes that makes it possible for them to maintain one meta portfile that will generate ports for each of the supported Python versions also supported by the package. The project has been busily converting Python package port files over to this new system and, thus, increasing the number of ports available for Python 3.2. Currently, I count 30 'py32' ports and '38 'py31' ports compared to 468 'py26' and 293 'py27' ports so, yes, there is still a lot to be done. But my observation of the MacPorts project is that they respond well to requests. If people request existing packages be made available for py32, or - even better - provide patches to do so, it will happen. Also right now besides the Python port group transition, the project has been swamped with issues arising from the Xcode 4 introduction for Lion, mandating the transition from gcc to clang or llvm-gcc. -- Ned Deily, [email protected] ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
Re: [Python-Dev] Promoting Python 3 [was: PyPy 1.7 - widening the sweet spot]
On 2011-11-23, at 04:51 , Stephen J. Turnbull wrote: > Xavier Morel writes: >> On 2011-11-22, at 17:41 , Stephen J. Turnbull wrote: >>> Barry Warsaw writes: > Hopefully, we're going to be making a dent in that in the next version of Ubuntu. > >>> This is still a big mess in Gentoo and MacPorts, though. MacPorts >>> hasn't done anything about ceating a transition infrastructure AFAICT. > >> What kind of "transition infrastructure" would it need? It's definitely >> not going to replace the Apple-provided Python out of the box, so >> setting `python` to a python3 is not going to happen. > > Sure, but many things do shadow Apple-provided software if you set > PATH=/opt/local/bin:$PATH. > Some I'm sure do, but "many" is more doubtful, and I have not seen any do that in the Python ecosystem: macports definitely won't install a bare (unversioned) `python` without the user asking. > I'm not sure what infrastructure is required, but I can't really see > MacPorts volunteers doing a 100% conversion the way that Ubuntu's paid > developers can. So there will be a long transition period, and I > wouldn't be surprised if multiple versions of Python 2 and multiple > versions of Python 3 will typically need to be simultaneously > available to different ports. That's already the case so it's not much of a change. > >> It doesn't define a `python3`, so maybe that? > A python3 symlink or script would help a little bit, but I don't think > that's necessary or sufficient, because ports already can and do > depend on Python x.y, not just Python x. Yes indeed, which is why I was wondering in the first place: other distributions are described as "fine" because they have separate Python2 and Python3 stacks, macports has a Python stack *per Python version* so why would it be more problematic when it should have even less conflicts? >> Macports provide `port select` which I believe has the same function >> (you need to install the `python_select` for it to be configured for >> the Python group), the syntax is port `select --set python $VERSION`: > > Sure. > > I haven't had the nerve to do this on MacPorts because "port" is such > a flaky thing (not so much port itself, but so many ports assume that > the port maintainer's local configuration is what others' systems use, > so I stay as vanilla as possible -- I rather doubt that many ports are > ready for Python 3, and I'm not willing to be a guinea pig). That is what I'd expect as well, I was just giving the corresponding tool to the gentoo version thereof. > The problem that I've run into with Gentoo is that *even when the > ebuild is prepared for Python 3* assumptions about the Python current > when the ebuild is installed/upgraded gets baked into the installation > (eg, print statement vs. print function), but some of the support > scripts just call "python" or something like that. OTOH, a few > ebuilds don't support Python 3 (or in a ebuild that nominally supports > Python 3, upstream does something perfectly reasonable for Python 2 > like assume that Latin-1 characters are acceptable in a ChangeLog, and > the ebuild maintainer doesn't test under Python 3 so it slips through) > so I have to do an eselect dance while emerging ... and in the > meantime things that expect Python 3 as the system Python break. > > So far, in Gentoo I've always been able to wiggle out of such problems > by doing the eselect dance two or three times with the ebuild that is > outdated, and then a couple of principal prerequisites or dependencies > at most. > > Given my experience with MacPorts I *very much* expect similar > issues with its ports. Yes I would as well, although: 1. A bare `python` call would always call into the Apple-provided Python, this has no reason to change so ports doing that should not be affected 2. Few ports should use Python (therefore assume things about Python) in their configuration/installation section (outside upstream's own assumptions): ports are tcl, not bash, so there shouldn't be too much reason to call Python from them ___ Python-Dev mailing list [email protected] http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
