Re: [Python-Dev] PyPI comments and ratings, *really*?
On Sat, Nov 14, 2009 at 4:34 PM, Arc Riley wrote: > >> +1 >> >> Having a "Repository-URL", "Repository-Browse-URL" and a >> "Bug-Tracker-URL" field in PyPI would be a lot more usefule then >> comments and ratings. >> > > +1 You mean in the Metadata ? We are currenty working on adding fields in them, for an upcoming 1.2 version (see PEP 345) I am crossposting to distutils-sig so we can discuss this point over there, because I think that would be a great triple of fields to add in 1.2 Tarek ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Too many Python accounts
Martin v. Löwis wrote: Even not having provider changes supported would still allow me to use my openid with PyPI which would be great. The only problem with changing provider that I can see is when the provider a user changes to would then be a duplicate - in which case I think just refusing to allow the login would be fine (rather than changing the provider for that account). In that case, it would be much easier to record your true openid (i.e. the one that your provider is able to validate). You can then enter the alias that you are used to, and PyPI would map that right away to the verifiable ID, and log you in with that. Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)? For this to work, you would have to upgrade your web page to OpenID 2, as this is the only protocol that PyPI supports. This I can do. Thanks Michael Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Too many Python accounts
> Would it be possible to detect a change of provider and then offer the > option to migrate the account to the new provider (so long as it does > not conflict with another account)? That would be possible - but again complicate the UI. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Too many Python accounts
Martin v. Löwis wrote: Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)? That would be possible - but again complicate the UI. Why? You should only need to present this option *after* the user has authenticated with the a different provider to the one associated with their account (or perhaps on detecting that the provider is different - but either way no UI changes until / unless the user actually has changed provider). That complicates the UI code perhaps, but shouldn't change the standard UI. I don't think it should be given as an option to the user before they have changed provider, given that one of the major use cases is to allow the user to switch provider if their current one becomes unavailable. A UI that only allows them to switch provider if they can first login via their current provider would lock them out if their provider goes down. Michael Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Too many Python accounts
Michael Foord wrote: > Martin v. Löwis wrote: >>> Would it be possible to detect a change of provider and then offer the >>> option to migrate the account to the new provider (so long as it does >>> not conflict with another account)? >>> >> >> That would be possible - but again complicate the UI. >> > > Why? You should only need to present this option *after* the user has > authenticated That's what I mean - it's another HTML form to present, in certain cases. It would be easier to change the underlying ID silently, and refuse login if that then would conflict with an existing account. Regards, Martin ___ 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/archive%40mail-archive.com
Re: [Python-Dev] buildtime vs runtime in Distutils
On Sun, Nov 15, 2009 at 02:31:45PM +0100, Georg Brandl wrote: > Antoine Pitrou schrieb: > > Tarek Ziadé gmail.com> writes: > >> > >> This cannot work on all platforms, when our Makefile is not shipped > >> with python but python-devel. (like Fedora) > > > > This practice is stupid anyway, because it means you have to install > > python-devel even to install pure Python packages with > > setuptools/distribute. > > Just ask Fedora, Mandriva and friends to change their packaging practice > > (Mandriva already has a bug open for that by the way). > > +1. They are the ones splitting what "make install" installs into several > packages, so they are the ones who have to fix the resulting dependency > problems. > I agree with this, however, my point on the bug was more akin to this: Tres Seaver wrote: > Parsing the Makefile at runtime seems like an insane choice anyway to > me: +1 for your new module having constants generated at ./configure > time. Makefiles and C header files are not intended as general purpose data formats. Using them as such has a variety of disadvantages: * If someone else wants to get at the data, they have to go through the API in distutils. Any data that's not exposed by the API is unavailable. * Since disturils doesn't implement a full parser for the make and C syntax it is possible to break distutils when making legitimate changes to those build files. These are the reasons I opened the bug to get that information into a real data file rather than parsing the Makefile and header files. I'll also mention two further things: The reason that python-devel was split off was to make it more useful for livecds, olpc, embedded systems, and other places where disk space is at a premimum. Being able to combine an operating system that is used by people beyond your immediate community is great for finding and fixing bugs before your users run into them. Being able to program in a high level language on these platforms has benefits that I'm sure everyone here can appreciate. I've brought the issue of Makefile and pyconfig.h being needed for distutils to the attention of every new Fedora python maintainer since the package split was made. The current maintainer, David Malcolm, agrees that distutils.sysconfig needs to be able to use this data and he has moved the Makefile and header files into the main python package. This doesn't change the problems with using a Makefile and C header files as a data format for python. -Toshio pgpwjwTL7cYrI.pgp Description: PGP signature ___ 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/archive%40mail-archive.com
Re: [Python-Dev] Too many Python accounts
Martin v. Löwis wrote: Michael Foord wrote: Martin v. Löwis wrote: Would it be possible to detect a change of provider and then offer the option to migrate the account to the new provider (so long as it does not conflict with another account)? That would be possible - but again complicate the UI. Why? You should only need to present this option *after* the user has authenticated That's what I mean - it's another HTML form to present, in certain cases. It would be easier to change the underlying ID silently, and refuse login if that then would conflict with an existing account. Sounds good to me. Michael Regards, Martin -- http://www.ironpythoninaction.com/ http://www.voidspace.org.uk/blog ___ 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/archive%40mail-archive.com
Re: [Python-Dev] buildtime vs runtime in Distutils
On Sun, Nov 15, 2009 at 11:27:29PM -0500, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > Tarek Ziadé wrote: > > On Sun, Nov 15, 2009 at 3:35 AM, Christian Heimes wrote: > > [..] > >> Do we really want to change distutils to solve a problem of a third > >> party packaging system when the problem was created by the very same > >> third party in the first place? In other words: Should you spend your > >> precious development time with fixing a problem that isn't our fault? > >> The decision to split the header files into a separate package, that > >> isn't installed by default, has already created tons of bad user > >> experience in the past. Do you want to endorse the split even further? > > > > I didn't know the split story went like this. I took it like the > > "natural" split everyone > > agreed on, and I saw this distutils <-> Makefile link like something to fix. > > > > So, it sounds like a bad idea now :) > > Parsing the Makefile at runtime seems like an insane choice anyway to > me: +1 for your new module having constants generated at ./configure time. +1 There have been bugs in the past about distutils.sysconfig.parse_makefile() not knowing the full make syntax and there will no doubt still be bugs like this. Substituting these variables at ./configure time into a .py.in file would be much safer. Regards Floris -- Debian GNU/Linux -- The Power of Freedom www.debian.org | www.gnu.org | www.kernel.org ___ 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/archive%40mail-archive.com
Re: [Python-Dev] PyPI comments and ratings, *really*?
2009/11/16 Tres Seaver : >> Which is bizarre, since Paul belongs to the group of people you say >> you care most about - i.e., those people browsing the index and >> looking for packages. The *consumers* of the comments, in other words. > > I agree with Martin that anonymous votes, like anonymous comments, are > process-harmful here. FWIW, having started this, I've no problem with this. As long as people are aware of the self-selecting nature of the sample (and Martin clearly is) that's fine. Paul. ___ 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/archive%40mail-archive.com
Re: [Python-Dev] buildtime vs runtime in Distutils
On Sun, Nov 15, 2009 at 03:35:00AM +0100, Christian Heimes wrote: > > Do we really want to change distutils to solve a problem of a third > party packaging system when the problem was created by the very same > third party in the first place? In other words: Should you spend your > precious development time with fixing a problem that isn't our fault? > The decision to split the header files into a separate package, that > isn't installed by default, has already created tons of bad user > experience in the past. Do you want to endorse the split even further? The problem being addressed is that distutils is using an artefact of the build system (a Makefile) as a data file. I think the issue of whether or not to "endorse the split" is a red herring. -- Andrew McNabb http://www.mcnabbs.org/andrew/ PGP Fingerprint: 8A17 B57C 6879 1863 DE55 8012 AB4D 6098 8826 6868 ___ 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/archive%40mail-archive.com
[Python-Dev] Static analysis of CPython using coccinelle/spatch
Has anyone else looked at using Coccinelle/spatch[1] on CPython source code? It's a GPL-licensed tool for matching semantic patterns in C source code. It's been used on the Linux kernel for detecting and fixing problems, and for autogenerating patches when refactoring (http://coccinelle.lip6.fr/impact_linux.php). Although it's implemented in OCaml, it is scriptable using Python. I've been experimenting with using it on CPython code, both on the core implementation, and on C extension modules. As a test, I've written a validator for the mini-language used by PyArg_ParseTuple and its variants. My code examines the types of the variables passed as varargs, and attempts to check that they are correct, according to the rules here http://docs.python.org/c-api/arg.html (and in Python/getargs.c) It can detect this old error (fixed in svn r34931): buggy.c:12:socket_htons:Mismatching type of argument 1 in ""i:htons"": expected "int *" but got "unsigned long *" Similarly, it finds the deliberate error in xxmodule.c: xxmodule.c:207:xx_roj:unknown format char in "O#:roj": '#' (Unfortunately, when run on the full source tree, I see numerous messages, and as far as I can tell, the others are false positives) You can see the code here: http://fedorapeople.org/gitweb?p=dmalcolm/public_git/check-cpython.git;a=tree and download using anonymous git in this manner: git clone git://fedorapeople.org/home/fedora/dmalcolm/public_git/check-cpython.git The .cocci file detects invocations of PyArg_ParseTuple and determines the types of the arguments. At each matching call site it invokes python code, passing the type information to validate.py's validate_types. (I suspect it's possible to use spatch to detect reference counting antipatterns; I've also attempted 2to3 refactoring of c code using semantic patches, but so far macros tend to get in the way). Alternatively, are there any other non-proprietary static analysis tools for CPython? Thoughts? Dave [1] http://coccinelle.lip6.fr/ ___ 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/archive%40mail-archive.com
Re: [Python-Dev] buildtime vs runtime in Distutils
On Sun, 2009-11-15 at 12:42 +, Antoine Pitrou wrote: > Tarek Ziadé gmail.com> writes: > > > > This cannot work on all platforms, when our Makefile is not shipped > > with python but python-devel. (like Fedora) > > This practice is stupid anyway, because it means you have to install > python-devel even to install pure Python packages with setuptools/distribute. > Just ask Fedora, Mandriva and friends to change their packaging practice > (Mandriva already has a bug open for that by the way). > > In Debian/Ubuntu, the Makefile is correctly part of the main Python package: > > $ dpkg -S /usr/lib/python2.5/config/Makefile > python2.5: /usr/lib/python2.5/config/Makefile For what it's worth, this is fixed in Fedora as of python-2.6.4-2.fc13 ; the bug tracking it was: https://bugzilla.redhat.com/show_bug.cgi?id=531901 ___ 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/archive%40mail-archive.com
[Python-Dev] 2.7 and 3.2 release schedules
After more thought, I think that separating the 2.7 and 3.2 releases is not as big of an issue as I once thought. Therefore, I'd like to adopt the schedule I posted a few weeks back for 2.7 only. This only means some other lucky victi... I mean volunteer can do 3.2. :) -- Regards, Benjamin ___ 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/archive%40mail-archive.com
