Re: [Python-Dev] PyPI comments and ratings, *really*?

[Martin v. Löwis]

> What I really like on PyPi is that my packages are tested automatically
> with Cheesecake and the order of packages when searching is determined
> by this rating.

That is an (apparently widespread) myth. The Cheesecake rating is not
considered in ranking search results; it's just the relevance of the
search term that is.

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] PyPI comments and ratings, *really*?

[Martin v. Löwis]

Paul Moore wrote:
> 2009/11/13 Tres Seaver :
>> I can see the information about the poll, and a link to view the
>> results, without logging in.
>>
>>  http://pypi.python.org/pypi
>>
>> (second paragraph there).  That paragraph tells you that you need to log
>> in to vote in the poll.
> 
> I don't want to create a PyPI account (more account details I'll
> rarely use to remember) just to vote. I can see why anonymous votes
> are bad, but the sample's going to be self-selecting - people like me
> who don't want to create an account will be excluded.

This is indeed intentional: people like you won't upload packages to
PyPI, nor will they take part in the rating system, as both require
a PyPI 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] PyPI governance

[Martin v. Löwis]

> Martin, are you interested in help?

Certainly, yes. For the specific feature in question, I'd like to wait
for the outcome of the poll. Otherwise, contributions are welcome.

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] Status of the Buildbot fleet and related bugs

[Martin v. Löwis]

> Yes, I think this just started happening. I'm guessing that the main
> site proxies the buildbot URL requests to the buildbot master process,
> and when it's down you get the 404s from the main server.
> 
> I figured someone might be working on the master, though perhaps it
> just burped on its own :-)

It was actually an Apache misconfiguration (the wrong virtual host would
pick up requests, missing the reverse proxy configuration). I have fixed
that now.

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] PyPI comments and ratings, *really*?

[Wolodja Wentland]

On Sat, Nov 14, 2009 at 09:43 +0100, "Martin v. Löwis" wrote:
> > What I really like on PyPi is that my packages are tested automatically
> > with Cheesecake and the order of packages when searching is determined
> > by this rating.

> That is an (apparently widespread) myth. The Cheesecake rating is not
> considered in ranking search results; it's just the relevance of the
> search term that is.

Thanks for clarifying this!

What about the other points?

Crossposted to catalog-sig to move the discussion there.
-- 
  .''`. Wolodja Wentland 
 : :'  :
 `. `'` 4096R/CAF14EFC 
   `-   081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC


signature.asc
Description: Digital 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] PyPI comments and ratings, *really*?

[Martin v. Löwis]

> 
>> That is an (apparently widespread) myth. The Cheesecake rating is not
>> considered in ranking search results; it's just the relevance of the
>> search term that is.
> 
> Thanks for clarifying this!
> 
> What about the other points?

They are really off-topic for python-dev; PyPI discussion should take
place on catalog-sig.

I personally had problems following your message, as it seemed to mix
too many aspects into one message.

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] PyPI front page

[P.J. Eby]

At 08:33 PM 11/12/2009 -0500, Ian Bicking wrote:
On Thu, Nov 12, 2009 at 7:52 PM, Antoine Pitrou 
<solip...@pitrou.net> wrote:

Ben Finney  benfinney.id.au> writes:
>
> There's a problem with the poll's placement: on the front page of the
> PyPI website.

Speaking of which, why is it that 
http://pypi.python.org/pypi and
http://pypi.python.org/pypi/ (note the 
ending slash) return different contents

(the latter being very voluminous)? I always mistake one for the other when
entering the URL directly.


easy_install replied on the behavior of /pypi/ (it uses the long 
list to do case-insensitive searches).  Someone changed it, 
easy_install broke, and a compromise was to keep /pypi/ the way it 
was (but not /pypi).


Probably this could be removed, as the /simple/ index is already 
case-insensitive, so easy_install shouldn't have to hit /pypi/ at all.


This was changed over a year ago; easy_install *does* use /simple by 
default.  I would guess enough people are upgraded by now that PyPI 
need no longer continue to support it.


___
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*?

[P.J. Eby]

At 09:45 AM 11/14/2009 +0100, Martin v. Löwis wrote:

Paul Moore wrote:
> 2009/11/13 Tres Seaver :
>> I can see the information about the poll, and a link to view the
>> results, without logging in.
>>
>>  http://pypi.python.org/pypi
>>
>> (second paragraph there).  That paragraph tells you that you need to log
>> in to vote in the poll.
>
> I don't want to create a PyPI account (more account details I'll
> rarely use to remember) just to vote. I can see why anonymous votes
> are bad, but the sample's going to be self-selecting - people like me
> who don't want to create an account will be excluded.

This is indeed intentional: people like you won't upload packages to
PyPI, nor will they take part in the rating system, as both require
a PyPI account.


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.


___
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*?

[Martin v. Löwis]

>> > I don't want to create a PyPI account (more account details I'll
>> > rarely use to remember) just to vote. I can see why anonymous votes
>> > are bad, but the sample's going to be self-selecting - people like me
>> > who don't want to create an account will be excluded.
>>
>> This is indeed intentional: people like you won't upload packages to
>> PyPI, nor will they take part in the rating system, as both require
>> a PyPI account.
> 
> 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.

Ok: "intentional" is not the right attribute. It's more that I don't
consider it too harmful.

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] PyPI comments and ratings, *really*?

[Steven D'Aprano]

On Sun, 15 Nov 2009 01:52:21 am P.J. Eby wrote:

> > > I don't want to create a PyPI account (more account details I'll
> > > rarely use to remember) just to vote. I can see why anonymous
> > > votes are bad, but the sample's going to be self-selecting -
> > > people like me who don't want to create an account will be
> > > excluded.
> >
> >This is indeed intentional: people like you won't upload packages to
> >PyPI, nor will they take part in the rating system, as both require
> >a PyPI account.
>
> 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.

Not bizarre at all, practical. Without authenticated votes, gaming the 
system goes from technically challenging to simple enough anyone can do 
it. Martin may have the best interests of "consumers" in mind, but he 
can't force them to act in their best interest. If they choose to not 
vote, that's their choice to make.

Think of it as voting registration. Even in countries like Australia 
with compulsory voting, you have to register first, to ensure that 
people make a single vote.

Since Paul doesn't have an account, he can't make comments, or rate 
packages, or cast a vote. This is by design, not out of a desire to 
defranchise people like Paul, but because the alternatives -- easy 
comment spam, people voting multiple times -- are worse than some 
proportion of users being unable to vote.




-- 
Steven D'Aprano
___
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*?

[Floris Bruynooghe]

On Fri, Nov 13, 2009 at 06:10:16PM -0600, Robert Kern wrote:
> If you want one idea that would make my use of PyPI much more
> pleasant and informative, it would be to add a "Repository-URL"
> entry to the recommended PyPI metadata so that I could always start
> looking at the code in one click.

+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.


Regards
Floris
___
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*?

[Arc Riley]

> +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
___
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*?

[Baptiste Carvello]

Robert Kern a écrit :

While I do have a couple of packages on PyPI, I use PyPI as a consumer 
of packages much more frequently, every day in fact. 


Another "consumer" opinion: when investigating a new package, I usually look for 
the following things, in that order:


1) the "big picture" description: is there a coherent design? does it fit my 
needs? On PyPI, the description field should provide that.


2) the changelog: is the project still alive? are bugs fixed, or just features 
added? is the code rewritten from scratch for each release? Well, every project 
on PyPI should have a public changelog, so a link to that fits my need.


3) documentation: I don't necessarily care for the number of lines, but more 
whether it is understandable and goes into sufficient detail to not leave me 
guessing. Again, a link to the docs fits my needs. A single number (number of 
documentation lines,...) does not.


4) a mailing list archive (or newsgroup, or web forum), where I'm looking for 
signs of a healthy community. I usually go for the -devel list, but a -user list 
will do as well if the committers keep an eye on it.


If a healthy community exists around a project, I will completely disregard 
comments, if present: time invested in the community speaks louder than the 
opinion of random bystanders. Only for small projects with no real community 
will I look at the comments (+ answers from the author) in order to make an 
opinion on the developpement process. I always disregard ratings.


So as a conclusion about comments, they can have their use for projects without 
a publicly archived mailing list, but can otherwise be *replaced* by a direct 
link to a list archive. This could be a reasonable default for PyPI: disable 
comments when a link to a list archive is provided.


While my experience may not be that of a typical user, I believe users will 
ultimately make use of all information they are provided. So it is important to 
provide the most relevant information, and not just what naive users ask for.


Cheers,
B.

___
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] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

[Terry Reedy]

Martin v. Löwis wrote:


This is indeed intentional: people like you won't upload packages to
PyPI, nor will they take part in the rating system, as both require
a PyPI account.


Why? I already have python tracker account and a python wiki account 
which is already 2 too many. The latter was a pain because the site lost 
my registration and as of a year ago, the registration process was 
broken. I would much prefer just one python site registration.


Terry Jan Reedy

___
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

[Ben Finney]

Terry Reedy  writes:

> Martin v. Löwis wrote:
>
> >>> This is indeed intentional: people like you won't upload packages
> >>> to PyPI, nor will they take part in the rating system, as both
> >>> require a PyPI account.
>
> Why? I already have python tracker account and a python wiki account
> which is already 2 too many. The latter was a pain because the site
> lost my registration and as of a year ago, the registration process
> was broken. I would much prefer just one python site registration.

And that registration should be using any OpenID, so that I don't need
any new identities to participate on the Python sites: I can re-use
existing identities.

I would make a bug report for that, but the Python bug tracker also
requires yet-another-identity. It's lunacy.

-- 
 \   “Value your freedom or you will lose it, teaches history. |
  `\ “Don't bother us with politics,” respond those who don't want |
_o__)   to learn.” —Richard Stallman, 2002 |
Ben Finney

___
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

[Stephen J. Turnbull]

Ben Finney writes:

 > I would make a bug report for that, but the Python bug tracker also
 > requires yet-another-identity. It's lunacy.

No, it's legacy.  The software predates the availability of OpenID.

If you'd like to integrate Open ID authentication into Roundup, I will
personally be happy to do the followup required to get the patch on
the radar of the Python site and Roundup software maintainers.
___
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] buildtime vs runtime in Distutils

[Tarek Ziadé]

Hello,

http://bugs.python.org/issue4359 reminds me that Distutils reads build
files like Makefile or pyconfig.h to get some environment
variables through the sysconfig module at *runtime*.

This cannot work on all platforms, when our Makefile is not shipped
with python but python-devel. (like Fedora)

Since I am already working on the refactoring of this
distutils/sysconfig module, so it lands in a stdlib module together
with some
elements from site.py (see a previous mail on the topic, and my
tarek_sysconfig branch - work in progress),

I was wondering if we couldn't make this module a template, and inject
at its beginning new values extracted from Makefile and pyconfig.h.

This could happen when "configure" is called,

Regards,
Tarek

-- 
Tarek Ziadé | http://ziade.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] Too many Python accounts (was Re: PyPI comments and ratings, *really*?)

[Martin v. Löwis]

> Why? I already have python tracker account and a python wiki account
> which is already 2 too many. The latter was a pain because the site lost
> my registration and as of a year ago, the registration process was
> broken. I would much prefer just one python site registration.

Then I recommend that you get a google account for your email address,
and register to PyPI using OpenID.

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]

> And that registration should be using any OpenID, so that I don't need
> any new identities to participate on the Python sites: I can re-use
> existing identities.

PyPI actually does support OpenID.

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

[Martin v. Löwis]

> http://bugs.python.org/issue4359 reminds me that Distutils reads build
> files like Makefile or pyconfig.h to get some environment
> variables through the sysconfig module at *runtime*.
> 
> This cannot work on all platforms, when our Makefile is not shipped
> with python but python-devel. (like Fedora)

I don't see a problem with that: you'll need the python-devel package
*anyway* when running distutils, for many packages.

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

[Arfrever Frehtes Taifersar Arahesis]

2009-11-15 02:21:41 Tarek Ziadé napisał(a):
> Hello,
> 
> http://bugs.python.org/issue4359 reminds me that Distutils reads build
> files like Makefile or pyconfig.h to get some environment
> variables through the sysconfig module at *runtime*.
> 
> This cannot work on all platforms, when our Makefile is not shipped
> with python but python-devel. (like Fedora)
> 
> Since I am already working on the refactoring of this
> distutils/sysconfig module, so it lands in a stdlib module together
> with some
> elements from site.py (see a previous mail on the topic, and my
> tarek_sysconfig branch - work in progress),
> 
> I was wondering if we couldn't make this module a template, and inject
> at its beginning new values extracted from Makefile and pyconfig.h.
> 
> This could happen when "configure" is called,

It seems to be a good idea. You should create a .py.in file and use
AC_SUBST and AC_CONFIG_FILES macros in configure.in.

-- 
Arfrever Frehtes Taifersar Arahesis


signature.asc
Description: This is a digitally signed message part.
___
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

[Ben Finney]

"Stephen J. Turnbull"  writes:

> Ben Finney writes:
>
>  > I would make a bug report for that, but the Python bug tracker also
>  > requires yet-another-identity. It's lunacy.
>
> No, it's legacy.  The software predates the availability of OpenID.

I don't agree that's a “no”; it's a “yes, and” :-)

> If you'd like to integrate Open ID authentication into Roundup, I will
> personally be happy to do the followup required to get the patch on
> the radar of the Python site and Roundup software maintainers.

I'll give the usual caveat of “this is but one of the many services I
would like to be able to authenticate in with OpenID”, but it's a caveat
rather than a rejection. I'll keep your kind offer in mind in case I get
the bandwidth to take that on.

-- 
 \  “Our products just aren't engineered for security.” —Brian |
  `\ Valentine, senior vice-president of Microsoft Windows |
_o__)development, 2002 |
Ben Finney

___
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

[Tarek Ziadé]

2009/11/15 "Martin v. Löwis" :
>> http://bugs.python.org/issue4359 reminds me that Distutils reads build
>> files like Makefile or pyconfig.h to get some environment
>> variables through the sysconfig module at *runtime*.
>>
>> This cannot work on all platforms, when our Makefile is not shipped
>> with python but python-devel. (like Fedora)
>
> I don't see a problem with that: you'll need the python-devel package
> *anyway* when running distutils, for many packages.

The problem is that the main python distribution ("python") is not
working as advertised since
it contains distutils, which requires "python-devel" to work.

This implies that "python" has a dependency on "python-devel", which
does not make sense
anymore for linux distros to have two distinct packages for Python.

Having some of the makefile vars stored in stdlib solve this problem.

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] buildtime vs runtime in Distutils

[Tarek Ziadé]

On Sun, Nov 15, 2009 at 2:41 AM, Arfrever Frehtes Taifersar Arahesis
 wrote:
[..]
>>
>> This could happen when "configure" is called,
>
> It seems to be a good idea. You should create a .py.in file and use
> AC_SUBST and AC_CONFIG_FILES macros in configure.in.

I need to investigate on these, thx

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] buildtime vs runtime in Distutils

[Martin v. Löwis]

> The problem is that the main python distribution ("python") is not
> working as advertised since
> it contains distutils, which requires "python-devel" to work.
> 
> This implies that "python" has a dependency on "python-devel", which
> does not make sense
> anymore for linux distros to have two distinct packages for Python.
> 
> Having some of the makefile vars stored in stdlib solve this problem.

I don't see how this can solve the problem. Distutils contains the
build_ext command, which definitely will require the devel package.

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

[Ben Finney]

"Martin v. Löwis"  writes:

> > And that registration should be using any OpenID, so that I don't
> > need any new identities to participate on the Python sites: I can
> > re-use existing identities.
>
> PyPI actually does support OpenID.

I commend the PyPI administrators for this step, but the implementation
is currently insufficient: it conflates a user's OpenID (their identity,
as a URL) with their OpenID provider (the service which the person has
chosen to do the authentication check and serve the data). That's what I
meant by “should be using any OpenID”.

One of the best features of the OpenID system is identity delegation:
that one's identity can be decoupled from the service behind the scenes
which provides that identity. This is important, because it means I am
not tied to a particular provider to maintain my identity; if they no
longer provide my identity in a way I like, I can switch to a different
provider while keeping the same identity.

Fred can use his own OpenID ‘fred.example.org’, initially set up behind
the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any
time he likes, Fred can *change* which provider is actually used for
authentication, without changing his OpenID. PyPI gets to find out which
provider Fred is using for the identity ‘fred.example.org’ each time it
performs discovery on that identity, not before.

So, PyPI should not be asking the user “what is your provider?” since
that's (a) a detail irrelevant to the user if they just know their
OpenID, (b) liable to change independent of the OpenID, and (c)
discoverable from the OpenID auth process anyway.

PyPI should instead ask the user for their OpenID (‘fred.example.org’),
without discussing providers. Then, attempt to authenticate that user,
at which point PyPI automatically gets to find out which provider is in
use (‘bigcorp.example.com’). If you *then* want to be picky and complain
that PyPI refuses identities provided by ‘bigcorp.example.com’, that's
the time to do it.

I hope that makes more sense.

-- 
 \ “Geeks like to think that they can ignore politics. You can |
  `\leave politics alone, but politics won't leave you alone.” |
_o__)—Richard Stallman, 2002-07-26 |
Ben Finney

___
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

[Tarek Ziadé]

2009/11/15 "Martin v. Löwis" :
>> The problem is that the main python distribution ("python") is not
>> working as advertised since
>> it contains distutils, which requires "python-devel" to work.
>>
>> This implies that "python" has a dependency on "python-devel", which
>> does not make sense
>> anymore for linux distros to have two distinct packages for Python.
>>
>> Having some of the makefile vars stored in stdlib solve this problem.
>
> I don't see how this can solve the problem. Distutils contains the
> build_ext command, which definitely will require the devel package.

Sure that's the edge case where files like Python.h is required for
compiling C extensions.
And compiler errors can make it pretty clear at this level, that the
devel package is required.
Not because of the need to read a Makefile, but to get the header
files to compile.

And it should be possible to compile extensions that don't require
python-devel at all,
when these extensions are not CPython extensions.

Last, commands like "install" also requires using sysconfig, (thus
reading Makefile) to get some values.
I can change this for "install" it's not hard,  but we would still
provide some public APIs that are reading Makefile from within the
stlib.

right now, importing "disutils.sysconfig" triggers this behavior.

That makes several use case of requiring python-devel just to read a
few values that could be injected
in the stdlib at build time.

Regards
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] buildtime vs runtime in Distutils

[Christian Heimes]

Tarek Ziadé wrote:
> Hello,
> 
> http://bugs.python.org/issue4359 reminds me that Distutils reads build
> files like Makefile or pyconfig.h to get some environment
> variables through the sysconfig module at *runtime*.
> 
> This cannot work on all platforms, when our Makefile is not shipped
> with python but python-devel. (like Fedora)

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?

-0 from me

Christian
___
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]

> Fred can use his own OpenID ‘fred.example.org’, initially set up behind
> the scenes to delegate to ‘bigcorp.example.com’ as the provider. Any
> time he likes, Fred can *change* which provider is actually used for
> authentication, without changing his OpenID. PyPI gets to find out which
> provider Fred is using for the identity ‘fred.example.org’ each time it
> performs discovery on that identity, not before.

Does that actually work? What actual OpenID provider allows me to claim
'fred.example.org' as my OpenID? Sure, one can use authentication
delegation, by means of the openid.delegate link. However, that still
doesn't make the claimed identifier fred.example.com, but
bigcorp.example.com/fred.

So the only thing users gain with delegation is that they don't need
to remember the tedious URL that their provider assigns them. When they
switch providers, their claimed ID will still change, and they'll have
to reregister in all services they use.

Please correct me if I'm wrong.

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

[Terry Reedy]

Christian Heimes wrote:

Tarek Ziadé wrote:

Hello,

http://bugs.python.org/issue4359 reminds me that Distutils reads build
files like Makefile or pyconfig.h to get some environment
variables through the sysconfig module at *runtime*.

This cannot work on all platforms, when our Makefile is not shipped
with python but python-devel. (like Fedora)


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?

-0 from me


If the third party disables distutils by removing some of the things it 
(sometimes) needs, then it seems to me that they should also remove 
disutils into the separate package. If *that* creates a problem, that 
should be *their* problem.



___
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] Using itertools in modules that are part of the build chain (Re: [Python-checkins] r76264 - python/branches/py3k/Lib/tokenize.py)

[Nick Coghlan]

benjamin.peterson wrote:
> Modified: python/branches/py3k/Lib/tokenize.py
> ==
> --- python/branches/py3k/Lib/tokenize.py  (original)
> +++ python/branches/py3k/Lib/tokenize.py  Sat Nov 14 17:27:26 2009
> @@ -377,17 +377,12 @@
>  The first token sequence will always be an ENCODING token
>  which tells you which encoding was used to decode the bytes stream.
>  """
> +# This import is here to avoid problems when the itertools module is not
> +# built yet and tokenize is imported.
> +from itertools import chain

This is probably a bad idea - calling tokenize.tokenize() from a thread
started as a side effect of importing a module will now deadlock on the
import lock if the module import waits for that thread to finish.

We tell people not to do that (starting and then waiting on threads as
part of module import) for exactly this reason, but it is also the
reason we avoid embedding import statements inside functions in the
standard library (not to mention encouraging third party developers to
also avoid embedding import statements inside functions).

This does constrain where we can use itertools - if we want carte
blanche to use it anywhere in the standard library, even those parts
that are imported as part of the build chain, we'll need to bite the
bullet and make it a builtin module rather than a separately built
extension module.

Cheers,
Nick.

P.S. The problem is easy to demonstrate on the current Py3k branch:

1. Put this in a module file in your py3k directory (e.g. "deadlock.py"):
---
import threading
import tokenize
f = open(__file__, 'rU')
def _deadlocks():
  tokenize.tokenize(f.readline)
t = threading.Thread(target=_deadlocks)
t.start()
t.join()
---

2. Then run: ./python -c "import deadlock"

It will, as advertised, deadlock and you'll need to use Ctrl-Brk or kill
-9 to get rid of it. (Note that preventing this kind of thing is one of
the major reasons why direct execution and even the -m switch *don't*
hang onto the import lock while running the __main__ module)

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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 (was Re: PyPI comments and ratings, *really*?)

[Terry Reedy]

Martin v. Löwis wrote:

Why? I already have python tracker account and a python wiki account
which is already 2 too many. The latter was a pain because the site lost
my registration and as of a year ago, the registration process was
broken. I would much prefer just one python site registration.


Then I recommend that you get a google account for your email address,
and register to PyPI using OpenID.


OK, that worked after I hit the button a second time. Good enough.

___
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

[Ben Finney]

"Martin v. Löwis"  writes:

> > Fred can use his own OpenID ‘fred.example.org’, initially set up
> > behind the scenes to delegate to ‘bigcorp.example.com’ as the
> > provider. Any time he likes, Fred can *change* which provider is
> > actually used for authentication, without changing his OpenID. PyPI
> > gets to find out which provider Fred is using for the identity
> > ‘fred.example.org’ each time it performs discovery on that identity,
> > not before.
>
> Does that actually work? What actual OpenID provider allows me to
> claim 'fred.example.org' as my OpenID?

It's inherent in the protocol, and any standards-conformant provider
supports it. If Fred controls ‘fred.example.org’ (i.e. can cause that
URL to serve a document of his choosing), then Fred gets to delegate to
any OpenID provider, and can change it at any time while keeping the
same identity URL.

If Albert, on the other hand, doesn't want to set up a URL under his
control but instead just use an identity managed by someone else, that's
a perfectly valid option: he can use ‘bigcorp.example.com/albert’ as his
OpenID, and BigCorp will take care of being the endpoint as well. Albert
is not getting any benefit from identity delegation (he's going to have
a transition difficulty at some later date when he decides BigCorp isn't
serving his identity needs any more), but neither is he required to know
about delegation or other protocol details.

> Sure, one can use authentication delegation, by means of the
> openid.delegate link. However, that still doesn't make the claimed
> identifier fred.example.com, but bigcorp.example.com/fred.

That's not right (this is what I mean by unnecessarily conflating “who
provides the identity this time” with “what is the identity”). The
‘bigcorp.example.com/fred’ URL is *not* Fred's identity in our example,
it is only the “endpoint URL”: where Fred has configured his delegation
to go. Having control over ‘fred.example.org’, Fred configures
delegation, and then can happily forget the endpoint URL in his daily
activities. When asked for his OpenID, Fred uses ‘fred.example.org’.

Albert, on the other hand, has punted on the whole issue of delegation;
he uses ‘bigcorp.example.com/albert’ as his OpenID, because BigCorp
causes that URL to be both an OpenID and an endpoint. That's still fine
as far as the authentication process is concerned.

But the relying party (the party requesting an OpenID from the user; in
this case the relying party is PyPI) should not ask the user what their
provider is. The user is asked only for their OpenID: Fred will provide
‘fred.example.org’, Albert will provide ‘bigcorp.example.com/albert’.
PyPI discovers automatically, each time they use those identities, where
the provider is this time by using the OpenID discovery step on the
identity they provide.

Fred is very happy for this, since he can keep using ‘fred.example.org’
even if he later changes which provider he's delegating to. Albert is
very happy for this, because he doesn't have to know anything about
“provider” or “delegation” or “endpoint”, he just needs to remember his
OpenID. PyPI's user interface becomes simpler, because it only needs to
ask the user “what is your OpenID?” and the rest is taken care of by the
OpenID protocol implementation.

> Please correct me if I'm wrong.

I hope that helps. The documents at http://openid.net/developers/>
may be useful if you need more specifics.

-- 
 \  “Computer perspective on Moore's Law: Human effort becomes |
  `\   twice as expensive roughly every two years.” —anonymous |
_o__)  |
Ben Finney

___
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] [Python-checkins] Using itertools in modules that are part of the build chain (Re: r76264 - python/branches/py3k/Lib/tokenize.py)

[Benjamin Peterson]

2009/11/14 Nick Coghlan :
> This does constrain where we can use itertools - if we want carte
> blanche to use it anywhere in the standard library, even those parts
> that are imported as part of the build chain, we'll need to bite the
> bullet and make it a builtin module rather than a separately built
> extension module.

I have another unpleasant but slightly less hacky solution. We put
detect_encoding in linecache where it is actually used.


-- 
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

[Python-Dev] Modules that run other scripts

[Nick Coghlan]

I'm in the process of adding a "run_path" function to the runpy module
that allows Python code to execute scripts using the same rules as the
CPython command line (i.e. accepting both source and compiled Python
files in addition to zipfiles, directories and other valid sys.path
entries containing a __main__.py file).

After that I was considering looking at the standard library to see
which modules can be used to execute other scripts (e.g. pdb, profile)
and determine what would be involved in updating them to support the
same flexibility as the main command line (possibly including adding
their own "-m" option to run modules by name rather than file path
location).

For that second part:
1. Is it even worth doing at this stage? I'm not sure to what degree the
new command line flexibility has even been adopted by third party
application packagers, so I have no idea how large the pool of potential
users might be. Should I instead wait until we start seeing complaints
that these tools can't be used with script references that the main
command line will handle quite happily?

2. Aside from runpy itself, pdb and profile are the only examples that
spring to mind when I try to think of standard library modules that
execute other Python scripts. Are there any others that I'm missing?
(Even if we decide not to do anything at this stage, collating such a
list may still be handy for future reference)

Regards,
Nick.

P.S. pdb in particular may be messy to update, since the interaction
between the way it provides exception post-mortem debugging support and
the way the runpy module tries to avoid mutating the application's own
__main__ module will likely require careful handling.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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] Modules that run other scripts

[Robert Kern]

Nick Coghlan wrote:


For that second part:
1. Is it even worth doing at this stage? I'm not sure to what degree the
new command line flexibility has even been adopted by third party
application packagers, so I have no idea how large the pool of potential
users might be. Should I instead wait until we start seeing complaints
that these tools can't be used with script references that the main
command line will handle quite happily?


There is a small, but important class of "scripts that run scripts", which are 
mostly all development tools (e.g. coverage, my line_profiler, etc.). Doing this 
correctly in all of the corner cases is reasonably tricky, so I think this is a 
perfect case for having the functionality implemented once in the standard library.


For what its worth, I think Ned Batchelder did the most thorough job of 
implementing this in the latest version of coverage:


  http://bitbucket.org/ned/coveragepy/src/tip/coverage/execfile.py

--
Robert Kern

"I have come to believe that the whole world is an enigma, a harmless enigma
 that is made terrible by our own mad attempt to interpret it as though it had
 an underlying truth."
  -- Umberto Eco

___
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] Modules that run other scripts

[Nick Coghlan]

Robert Kern wrote:
> Nick Coghlan wrote:
> 
>> For that second part:
>> 1. Is it even worth doing at this stage? I'm not sure to what degree the
>> new command line flexibility has even been adopted by third party
>> application packagers, so I have no idea how large the pool of potential
>> users might be. Should I instead wait until we start seeing complaints
>> that these tools can't be used with script references that the main
>> command line will handle quite happily?
> 
> There is a small, but important class of "scripts that run scripts",
> which are mostly all development tools (e.g. coverage, my line_profiler,
> etc.). Doing this correctly in all of the corner cases is reasonably
> tricky, so I think this is a perfect case for having the functionality
> implemented once in the standard library.

Yep, that part I'm convinced of the need for - hence runpy.run_path.

It's whether the immediate demand is there to justify tinkering with the
existing tools in the standard library that I'm not sure about
(particularly when there is a risk of altering behaviour in some corner
cases).

> For what its worth, I think Ned Batchelder did the most thorough job of
> implementing this in the latest version of coverage:
> 
>   http://bitbucket.org/ned/coveragepy/src/tip/coverage/execfile.py

That's actually fairly similar to what run_path will do in the simple
script case (zipfile and directory execution is a fair bit messier in
practice, but based on a similar concept in principle).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
---
___
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