Hello everyone. The source tarballs and Windows installers for Python 2.6.4rc2 are now available: http://www.python.org/download/releases/2.6.4/ Please download them, install them, and try to use them with your projects and environments. Let's make 2.6.4 a rock solid release! If there are no more regressions found, we'll do the final release in one week, on 25-October. Enjoy, -Barry
Barry Warsaw <barry <at> python.org> writes:
Good news, but just one little nit: the page above appears to link to the NEWS file for 2.6.4rc1. Regards, Vinay Sajip
On Oct 19, 2009, at 3:59 AM, Vinay Sajip wrote:
Barry Warsaw <barry <at> python.org> writes:
Good news, but just one little nit: the page above appears to link to the NEWS file for 2.6.4rc1.
Ooops! Fixed, thanks. -Barry
I'm getting this warning. It seems nothing is actually broken, but the fix is pretty easy. gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FromFormatV': Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'unsigned char *' Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_DecodeUTF8' differ in signedness Include/unicodeobject.h:752: note: expected 'const char *' but argument is of type 'unsigned char *' BTW, should Python build with a C++ compiler? It seems this is not possible with 2.6.4rc2 (and GCC 4.4.1) On Mon, Oct 19, 2009 at 8:55 AM, Barry Warsaw <barry@python.org> wrote:
On Oct 19, 2009, at 3:59 AM, Vinay Sajip wrote:
Barry Warsaw <barry <at> python.org> writes:
Good news, but just one little nit: the page above appears to link to the NEWS file for 2.6.4rc1.
Ooops! Fixed, thanks. -Barry
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/dalcinl%40gmail.com
-- Lisandro Dalcín --------------- Centro Internacional de Métodos Computacionales en Ingeniería (CIMEC) Instituto de Desarrollo Tecnológico para la Industria Química (INTEC) Consejo Nacional de Investigaciones Científicas y Técnicas (CONICET) PTLC - Güemes 3450, (3000) Santa Fe, Argentina Tel/Fax: +54-(0)342-451.1594
On Oct 19, 2009, at 11:10 PM, Lisandro Dalcin wrote:
I'm getting this warning. It seems nothing is actually broken, but the fix is pretty easy.
gcc -pthread -c -fno-strict-aliasing -g -Wall -Wstrict-prototypes -I. -IInclude -I./Include -DPy_BUILD_CORE -o Objects/unicodeobject.o Objects/unicodeobject.c Objects/unicodeobject.c: In function 'PyUnicodeUCS2_FromFormatV': Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'strlen' differ in signedness /usr/include/string.h:397: note: expected 'const char *' but argument is of type 'unsigned char *' Objects/unicodeobject.c:687: warning: pointer targets in passing argument 1 of 'PyUnicodeUCS2_DecodeUTF8' differ in signedness Include/unicodeobject.h:752: note: expected 'const char *' but argument is of type 'unsigned char *'
This isn't a regression in 2.6.3, nor is it critical enough, to be fixed for 2.6.4. -Barry
Barry: Do you know anything about this alleged regression in 2.6.3 with regard to the __doc__ property? https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688 Regards, Zooko
On Oct 21, 2009, at 7:00 PM, Zooko O'Whielacronx wrote:
Do you know anything about this alleged regression in 2.6.3 with regard to the __doc__ property?
https://bugs.edge.launchpad.net/ubuntu/+source/boost1.38/+bug/457688
This is the first I've heard of it, but my guess is that it's caused by the fix for bug 5890. http://bugs.python.org/issue5890 It's a change in Python 2.6.3, but I don't believe it's a regression (as in, currently broken). -Barry
Hi All, I started out some time ago and wrote a Python Package Manager with wxpython. It was an interesting learning experience for me. I was new to python. Some have pointed out that using wx was not a good idea for a tool to go into all the python distributions. Because it required the external dependency of wx. So, given that, I'm ready to have another go. Some have suggested using Tk. But I noticed python Tk isn't standard on ubuntu. A console mode tool is possible. That would be better than the nothing that we have under windows today. Vote [1] - console mode tool for this Alternatively, a web server based tool along the lines of the old python docs system might be possible. Vote [2] - web tool for this I have come to understand that python-dev is full of people that know the packages that they like, know how to install them by hand, and probably only ever go looking for upgrades. However, for new users, it is so much harder. It also seems to me that we have a lot of reasonable and talented people, who are committed and dedicated. To me, a relative outsider, it's not clear if this is a python central issue, or a distutils issue. It could be either. Advise me please. By June next year, some people including myself, want to go to europe for holidays - sorry conferences.. and we want to take some work with us to talk about. We can do the work.. But we need concessions... What can we work on that might make a difference ? If the current roadmap for distutils package management on windows for the next 8 months is nothing, I can live with that. But seriously, lets get this discussion going again. If a command line tool is all that windows users will allowed to have, then it would be better than the current plan which is for them to have nothing. It's not just nothing for now, it's nothing for years. That doesn't seem fair or nice. It's not just one person saying that, it is a handful who don't use windows on a regular basis. Why can't we have an advocate from each major platform? bring their issues, and try to come to a consensus. Even if that tool would simply allow them to choose: - PIP - Distribute - Easy Install - Python Package Manager
From there, users could explore each offer on it's own merits.
I'm interested in getting all types of opinions and feedback. David
On Wed, Oct 21, 2009 at 17:34, David Lyon <david.lyon@preisshare.net> wrote:
Hi All,
I started out some time ago and wrote a Python Package Manager with wxpython. It was an interesting learning experience for me. I was new to python.
Some have pointed out that using wx was not a good idea for a tool to go into all the python distributions. Because it required the external dependency of wx.
So, given that, I'm ready to have another go.
I honestly don't see what this has to do with python-dev or the distutils-sig. If you want to write a package management tool that's great, but I don't see why python-dev should have input on that sort of thing. Asking what kind of GUI to use is a comp.lang.python question and not a python-dev question as I don't see anything like this going into the stdlib. If you want distutils to expose something to make it easier to write your tool then that belong on the distutils-sig. But otherwise this seems off-topic for python-dev. -Brett
On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon <brett@python.org> wrote:
but I don't see why python-dev should have input on that sort of thing.
python-dev is the only place where we could get a change to the installation binary release. We'd need a change and the addition of a program shortcut.
If you want distutils to expose something to make it easier to write your tool then that belong on the distutils-sig. But otherwise this seems off-topic for python-dev.
I didn't ask for that - because I know that getting that assistance on the distutils side is certainly possible. Distutils is simply just one of the many libraries within python. It doesn't have an external interface. The roadmap for distutils for windows doesn't include getting a shortcut or utility for windows so that's why I'm asking about it here. Surely logic says that if it's 'python' and 'development' and it's not in distutils then some discussion of it should be allowed here. What I am really talking about is the menu shortcuts in the cpython distribution for windows. And how they can be improved to help windows users. This is the only place that I can think to discuss that. Best Regards David
On Wed, Oct 21, 2009 at 18:17, David Lyon <david.lyon@preisshare.net> wrote:
On Wed, 21 Oct 2009 17:56:57 -0700, Brett Cannon <brett@python.org> wrote:
but I don't see why python-dev should have input on that sort of thing.
python-dev is the only place where we could get a change to the installation binary release. We'd need a change and the addition of a program shortcut.
But that assumes you can get your tool into the stdlib. It would have been better to phrase the question as "is there interest in having a package manager tool included with Python" rather than ask us out of the blue what GUI you should use.
If you want distutils to expose something to make it easier to write your tool then that belong on the distutils-sig. But otherwise this seems off-topic for python-dev.
I didn't ask for that - because I know that getting that assistance on the distutils side is certainly possible.
Distutils is simply just one of the many libraries within python. It doesn't have an external interface.
And that's on purpose.
The roadmap for distutils for windows doesn't include getting a shortcut or utility for windows so that's why I'm asking about it here.
Surely logic says that if it's 'python' and 'development' and it's not in distutils then some discussion of it should be allowed here.
No it surely does not. We do not need to discuss design decisions of pip, setuptools, virtualenv, buildout, or various other tools that involve the terms "python" and "development" and are not in distutils.
What I am really talking about is the menu shortcuts in the cpython distribution for windows. And how they can be improved to help windows users. This is the only place that I can think to discuss that.
David, you are making a huge leap here thinking that we even want a package manager in the stdlib. You did not ask about menu shortcuts but whether a package manager should be written using Tk or a web front-end. Then you start discussing about wanting to add some UI to package management by default on Windows or add some tool that sounds like what the EU is going to have MS stick in front of users to get new user by browsers. This extends beyond adding some shortcut the Windows installer adds to someone's machine. I realize you are trying to help, David, but you are going in the wrong direction here and pushing rather hard. At the language summit we discussed opening up some APIs in distutils about making it easier for people to write package management tools, but we don't have a burning desire to get into the tool business. We make a language here. Distutils exists as a bootstrap mechanism for the package story and for our own building needs of the stdlib. But I doubt I am the only core developer who has no interest to be in charge of a package management tool when there already exists several good ones out there that people seem to find on their own without issue. -Brett
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon <brett@python.org> wrote:
But that assumes you can get your tool into the stdlib.
No I'm not assuming that I can. I am actually assuming that I cannot.. So lets move forward..
It would have been better to phrase the question as "is there interest in having a package manager tool included with Python" rather than ask us out of the blue what GUI you should use.
David, you are making a huge leap here thinking that we even want a
ok - but I think I know the answer to that.. you answer it next. package
manager in the stdlib.
Well - who is 'we'? If it's python-dev people I can accept and respect that. If it's regular developers out there in developer land, I'm not so sure about your assertion. I'd even politely have to disagree from my experience.
You did not ask about menu shortcuts but whether a package manager should be written using Tk or a web front-end.
I was thinking about the issue on the fly... Menu shortcuts that link off to a a standard community web page would be an excellent compromise - in the case where some tool could not be added. That would be a tremendous improvement for windows users over what they are given at the moment.
Then you start discussing about wanting to add some UI to package management by default on Windows or add some tool that sounds like what the EU is going to have MS stick in front of users to get new user by browsers. This extends beyond adding some shortcut the Windows installer adds to someone's machine.
That's going further than what I'm saying..
I realize you are trying to help, David, but you are going in the wrong direction here and pushing rather hard.
On the counter side, others are pushing rather hard for 0 improvement for the windows platform for the user experience. While everything else on windows rushes ahead.. My direction is improving the developer experience for windows users. I can't do compiler writing. I'm not clever enough.
At the language summit we discussed opening up some APIs in distutils about making it easier for people to write package management tools, but we don't have a burning desire to get into the tool business.
ok - but nothing happened there... I'm not in the tools business either. I'm not doing it for money but that shouldn't be the point.
We make a language here. Distutils exists as a bootstrap mechanism for the package story and for our own building needs of the stdlib.
I accept that it's a tool for building stdlib. No debate.
But I doubt I am the only core developer who has no interest to be in charge of a package management tool when there already exists several good ones out there that people seem to find on their own without issue.
umm.. I disagree with the 'without issue' statement. I'm sure if I tralled the mailing lists I could find more than one.. Enough from me for now. Thanks Brett. David
On approximately 10/21/2009 7:13 PM, came the following characters from the keyboard of David Lyon:
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon <brett@python.org> wrote:
We make a language here. Distutils exists as a bootstrap mechanism for the package story and for our own building needs of the stdlib.
Maybe what David is missing is that since python-dev is uninterested in the package management issue, the only remaining way to include package management in a convenient, single installation, is to 1) Create the package management tool 2) Create a bundled installer that will install both Python, the package management tool, and any dependencies of the package management tool 3) Advertise the availability of the bundle, and its usefulness* 4) See how many users try it out, and as new versions of Python are created, how many users keep coming back, in preference to the package management tool free python.org distribution. *There does seem to be precedent for mentioning/linking to other distributions of Python from http://www.python.org/download/ so that would surely be an avenue that is open to David, although I have no idea what criteria must be met to obtain a listing on that page. -- Glenn -- http://nevcal.com/ =========================== A protocol is complete when there is nothing left to remove. -- Stuart Cheshire, Apple Computer, regarding Zero Configuration Networking
On Wed, Oct 21, 2009 at 10:35:49PM -0700, Glenn Linderman wrote:
Maybe what David is missing is that since python-dev is uninterested in the package management issue, the only remaining way to include package management in a convenient, single installation, is to
1) Create the package management tool 2) Create a bundled installer that will install both Python, the package management tool, and any dependencies of the package management tool 3) Advertise the availability of the bundle, and its usefulness* 4) See how many users try it out, and as new versions of Python are created, how many users keep coming back, in preference to the package management tool free python.org distribution.
David, may be my memory betrays me, but I think you ask you question not for the first but for the second, if not the third time. And every time you got exactly this answer - "Create the package management tool and see how many users try it out". Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
Glenn Linderman <v+python <at> g.nevcal.com> writes:
Maybe what David is missing is that since python-dev is uninterested in the package management issue, [...]
It's a bit strong to say we are uninterested. Most of us are not interested enough to tackle it ourselves (*), but we are certainly interested in good package management being available for Python. (*) Remember, however, that Tarek and work on Distribute, and also on bringing pieces of setuptools/Distribute functionality into distutils. It's true, however, that it is probably not the place to ask for advice with directions to follow for a yet unwritten piece of software. The only piece of advice (besides "forget Tk and use a modern toolkit" :-)) I could give would be to build on Distribute, rather than reinvent a whole bunch of mechanisms. Regards Antoine.
On Thu, 22 Oct 2009 10:20:03 +0000 (UTC), Antoine Pitrou <solipsis@pitrou.net> wrote:
(*) Remember, however, that Tarek and work on Distribute, and also on bringing pieces of setuptools/Distribute functionality into distutils.
But if that's the case then why not work on any third party tool..? like pip or setuptools? It seems are very longwinded process if the only way to work on python is to work on distutils but before doing that you have to first work on distribute and then wait for all the changes to work their way back up the chain.. Actually, I have finally worked out what I want. That is shell support in the python windows distribution so that you can right click an .egg and install it. I don't see how that can be achieved by following the workprocess that you describe above. David
(*) Remember, however, that Tarek and work on Distribute, and also on bringing pieces of setuptools/Distribute functionality into distutils.
But if that's the case then why not work on any third party tool..? like pip or setuptools?
It seems are very longwinded process if the only way to work on python is to work on distutils but before doing that you have to first work on distribute and then wait for all the changes to work their way back up the chain..
Actually, I have finally worked out what I want. That is shell support in the python windows distribution so that you can right click an .egg and install it.
I don't see how that can be achieved by following the workprocess that you describe above.
As has been said by many, you are entirely welcome to work on whatever tool you think is useful. Once you are done you are again welcome to distribute your tool or application to users and see how many users are happy with it. Once you are done with this step as well, you are again encouraged to come back to python-dev and say: "In the last X months my app/tool became very popular in the python community. There are Y developers working on the app/tool and there are Z happy users. I'd suggest including it in the python stdlib or I'd suggest coordinating the releases of my app/tool with that of python." At this point a useful conversation can start. Please note that a similarly useful conversation is impossible to take place before all the above steps have been completed. HTH, Daniel -- Psss, psss, put it down! - http://www.cafepress.com/putitdown
David Lyon writes:
On Wed, 21 Oct 2009 18:38:26 -0700, Brett Cannon <brett@python.org> wrote:
David, you are making a huge leap here thinking that we even want a package manager in the stdlib.
Well - who is 'we'? If it's python-dev people I can accept and respect that.
Yes. The stdlib is a product of python-dev.
If it's regular developers out there in developer land,
They are not participants in this decision. python-dev people *do* care about them. Nevertheless python-dev is manifestly uninterested in dealing with *this* issue on behalf of the "regular developers out there". (With good reasons IMHO, but you can find those reasons elsewhere.) To make progress here on python-dev, you need to get those regular developers involved in python-dev. I can think of two ways to do this that will help. (1) Turn them into committers via whatever aspect of the language they are interested in. This will take a while, and substantial contribution (ie, effort) on their part. Once that happens, they will be in a much stronger position to advocate the package manager and credibly promise to maintain it (or find a new, credible maintainer) indefinitely. (2) Put the package manager on PyPI and get a lot of people on the bandwagon. If it's a good product and recommended, the movers and shakers of python-dev will be very likely to try it and more likely to second your motion in the future.
On Wed, Oct 21, 2009 at 08:34:24PM -0400, David Lyon wrote:
I started out some time ago and wrote a Python Package Manager with wxpython.
David, your message appeared in the middle of another thread. Please don't use "Reply" button to start a new thread - send a new message. Oleg. -- Oleg Broytman http://phd.pp.ru/ phd@phd.pp.ru Programmers don't die, they just GOSUB without RETURN.
participants (11)
-
Antoine Pitrou -
Barry Warsaw -
Brett Cannon -
Daniel Fetchinson -
David Lyon -
Glenn Linderman -
Lisandro Dalcin -
Oleg Broytman -
Stephen J. Turnbull -
Vinay Sajip -
Zooko O'Whielacronx